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/