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

From: Mitchell <m.att.foicica.com>
Date: Thu, 21 Mar 2013 10:13:36 -0400 (Eastern Daylight Time)

Hi Robin!

On Wed, 20 Mar 2013, Robin Haberkorn wrote:

> 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!).

After double-checking this, I realized that the call is to
"DrawTextClipped", not "DrawTextNoClip". As a result, I am fairly
confident that your check will work so your patch can be applied. I will
do so.

> 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!

Excellent! I will add a CURSES flag to the makefile so make CURSES=1 will
compile with curses.h and use ncurses.h otherwise. Thanks for testing this
:)

> 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?

I distribute Scintilla with Textadept to ensure compatibility. If a user
has Scintilla 1.xx installed and tries to compile Textadept against it,
mayhem would ensue.

>
> 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

Thanks, I will take a look.

> 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.

I had no idea :) Thanks for letting me know the good news!

Cheers,
Mitchell

-- 
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 Thu 21 Mar 2013 - 10:13:36 EDT

This archive was generated by hypermail 2.2.0 : Fri 22 Mar 2013 - 06:32:26 EDT