Re: CinePaint SCons Packager

Kai-Uwe Behrmann <[email protected]> Fri, 29 Feb 2008 21:05:05 +0100 (CET)
Newsgroups gmane.comp.video.cinepaint.devel
Message-ID <[email protected]>
Am 29.02.08, 11:07 -0800 schrieb H. S. Teoh:
> On Fri, Feb 29, 2008 at 08:13:21PM +0100, Kai-Uwe Behrmann wrote:
> > Am 29.02.08, 09:18 -0800 schrieb H. S. Teoh:
> > > On Fri, Feb 29, 2008 at 06:21:30PM +0100, Kai-Uwe Behrmann wrote:
> [...]
> > > > configure --enable-gtk2 
> > > 
> > > I just tried that, and I still get the same error. Maybe it's an
> > > autoconf version conflict? It seems a bit strange that it should get
> > > a syntax error if it's just a missing flag.
> > 
> > Hmm, another possibility is that the GTK1 macros are missed. Newer
> > systems dont have them. I still maintained Gtk1 versions. For instance
> > to support the gtk-osx builds. The Gtk2 on osX version did not work.
> 
> Hmm. Is there a way to make it skip the GTK1 macros when GTK1 is not
> installed? Or is there no way around installing GTK1 just so configure
> will work? (The Debian FTP masters will not like this if we try to
> upload to the main Debian archive...)

I assumed you use the CVS an thus call the autogen.sh script from CVS to 
build the autotools files (aclocal, autoconfig, automake). With the 
configure script in the tar ball I do not remember to have seen problems.
 
> Anyway, it seems that I'm seeing two problems, which are related:
> 
> 1) Running autoconf doesn't expand the GTK1 macros, so the resulting
> configure script is broken (that's where the syntax error comes from).

For developers it is adviceable to have Gtk1 installed. A alternative 
would be to drop Gtk1 completely. Then we can not continue with gtk-osx, 
which is not what we want.

> 2) Running the CVS version of configure does work, except that it
> insists on checking for gtk1 regardless of any settings (also, it
> doesn't seem to understand --enable-gtk2?). So it looks like I must
> install GTK1 just to make it happy?

Yes. GTK does currently not provide robust native platform support. 
Thus, I have used pices from different places in the past.
 
> [...]
> > > There's a subdirectory called 'libgimp' in the source...? (Am I
> > > looking at the right source tree??)
> > 
> > This name should not be used for libraries of this project. The
> > libgimp directory contains only headers. There should no object code
> > compile.
> [...]
> 
> Ah, you're right. I was wondering what I should do with them. (Nothing?)
> Are they even being used by the program anywhere? If not, I won't bother
> with the SConscript for this subdir.

These headers are used for internal and external plug-in builds.
 
> On another note, I've managed to get app/cinepaint to be fully compiled
> and linked under SCons. :-) There's still some mess I need to cleanup in

Great. So you have a running cinepaint executable without plug-ins?

> the SCons scripts, though---I hacked in some macro settings (like
> VERSION) just to make the thing compile, since I couldn't get configure
> to work correctly. I'll be working on getting configure to work properly
> next, then I can verify whether SCons is really doing what the makefiles
> are currently doing.

This seems a good route to me.
 
> --T

kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/