Re: [code] [scinterm][PATCHES] fix compilation on 64-bit

From: Robin Haberkorn <robin.haberkorn.att.googlemail.com>
Date: Wed, 20 Mar 2013 14:47:57 +0100

Hi Mitchell!

On Mon, 18 Mar 2013 10:47:37 -0400 (Eastern Daylight Time)
Mitchell <m.att.foicica.com> wrote:

> ...
> > Another patch in the SciTECO repository could also be of interest
> > for you:
> > https://github.com/rhaberkorn/sciteco/blob/master/patches/scintilla-teco-control-codes.patch
>
> I am reluctant to apply this just because I don't know enough about
> the internals of Scintilla on whether DrawTextNoClip() can be called
> elsewhere where rc.left > rc.right; I'm not sure how to test this.
>
I understand that. I only came up with this after playing around a bit
in the debugger, but wasn't able to verify that this condition holds
always and only for control characters. It would be a workaround in any
case (but less of a workaround than the current check!).

Please have a look at this patch - I had to add it to the repository...
https://github.com/rhaberkorn/sciteco/blob/master/patches/035-scinterm-curses-header.patch
It fixes scinterm compilation with non-ncurses curses implementations.
Scinterm works fine with PDCurses/XCurses!

The reasons I have these patches in my repository is that all of them
are more or less optional, non-critical and I'm reluctant to fork
Scintilla and Scinterm and keep these forks up to date with the
upstream Hg repositories. For obvious reasons I also do not want to
keep Scintilla in the SciTECO repository.

This leads me to another interesting question: The question of
distributing and packaging Scintilla/Scinterm-based applications.
Thanks to Scintilla's dubious design decision of building a
non-installable incompatibly-named static library - of which no prebuilt
packages appear to exist - it is necessary for users to build their own
Scintilla/Scinterm (and in my case apply the patches included with
SciTECO) - all of it in the correct directory layout. I found that
nowadays most even technically experienced people are unable to do so!
This also complicates the debianization of such applications since you
do not have a single upstream tar-ball and cannot package
Scintilla/Scinterm separately.

So I came up with the following solution:
 * do not keep Scintilla/Scinterm in the application-repository
 * when making a source distribution, do not include Scintilla/Scinterm
 * The SciTECO build system can handle different Scintilla/Scinterm
   paths/installations
 * For most users' convenience, I also build a source bundle based on
   SciTECO, Scintilla and Scinterm release source archives.
   This source bundle also has all necessary patches already applied.
 * This source bundle is built in such a way it can be used
   easily as an upstream tar ball for Debian packages.

This appears to be the same strategy that is followed by Scite and
Textadept. Are there any reasonable alternatives?

Have a look at SciTECO's debian package (work in progress).
You might be able to package Textadept in a similar way:
https://github.com/rhaberkorn/sciteco/tree/master/debian
https://github.com/rhaberkorn/sciteco/blob/master/distribute

> Cheers,
> Mitchell

cheers,
Robin

btw: Just for your information. While testing SciTECO with different
compilers, I found that Scinterm also compiles and works fine on:
gcc 4.4, 4.5, 4.6, 4.7;
LLVM/Clang 2.9, LLVM/Dragonegg 2.9 (gcc 4.5);
MinGW32;
MinGW64 cross compilers on Linux both i686 and x86_64
But you probably already know that.

-- 
You are subscribed to code.att.foicica.com.
To change subscription settings, send an e-mail to code+help.att.foicica.com.
To unsubscribe, send an e-mail to code+unsubscribe.att.foicica.com.
Received on Wed 20 Mar 2013 - 09:47:57 EDT

This archive was generated by hypermail 2.2.0 : Thu 21 Mar 2013 - 06:52:17 EDT