Re: CinePaint SCons Packager

On Fri, Feb 29, 2008 at 11:31:33AM -0800, Robin Rowe wrote:
[...]
> > -----snip-----
> > 
> > checking for alloca... yes
> > 
> > PKG_CONFIG_PATH =
> > 
> > checking fd_set and sys/select... yes
> > checking for yywrap in -lfl... yes
> > checking for pthread_create in -lpthread... yes
> > checking pthread.h usability... yes
> > checking pthread.h presence... yes
> > checking for pthread.h... yes
> > checking for pkg-config... /usr/bin/pkg-config
> > ./configure: line 23300: syntax error near unexpected token `1.2.8,,'
> > ./configure: line 23300: `	AM_PATH_GTK(1.2.8,,'
> 
> Mystery to me. Checking now, I do not see that error with ./configure.
> What version of libgtk1-dev do you have installed?
> 
> This looks like a new bug and unique to your system. Please
> investigate.

Heh, I found that the problem is that I didn't have libgtk1-dev
installed.  :-) I saw a message on the mailing list to the effect that
cinepaint now builds with gtk2, so I thought I could get away without
installing libgtk1-dev.  Maybe the gtk2 support stuff isn't in CVS yet?

Anyway, the reason the syntax error happened is because autoconf (on my
system) seems to produce a mangled configure script when libgtk1-dev
isn't installed. After installing libgtk1-dev, configure works properly.


> > 1) Are we looking for full-scale autotools replacement? Or just
> > automake? The automake part is relatively easy; replacing autoconf
> > may take a while to sort out since we'll have to replicate its
> > functionality in SCons. (Good news: things like pkg-config are
> > already natively supported by SCons.)
> 
> I don't know enough about scons to have an opinion regarding approach.
> 
> The plan is to provide several alternative build systems:
> autotools/automake/libtool, cmake, scons, cons, and maybe pmk. Much as
> I dislike the autotools tool chain personally, we'll probably have it
> forever.

OK. My current recommendation would be to use scons for build only, and
leave the configuration stuff to autoconf (at least for now).  SCons
does have rudimentary autoconf-like functionality, but, from what I've
seen in the source tree so far, cinepaint relies on a LOT of autoconf
functionality which would take some time to implement and test in SCons.
Once the build system is working, maybe we can consider replacing
autoconf.

As for supporting all those different build systems, how would we keep
all of their relevant scripts/config files up-to-date? If someone wants
to add a new file, say, they would have to not only edit the Makefile,
but also the SCons scripts, and the files for each of the other build
systems. While I don't mind maintaining the SCons scripts to keep up
with changes in the Makefiles, it seems to me that in the long run, a
lot of time/effort would be spent keeping everything in sync.

Or are we just evaluating the alternatives right now?


>   > 2) Currently there is a lot of reliance on autoconf to generate
>   > stuff in version.h and config.h. Are we looking to replace these
>   > as well?
> 
> What do you recommend?

I think for now, we'll let autoconf generate these files, and SCons can
just treat them as source files.


> > 3) What's the convention for checking stuff into CVS? I guess it
> > must at least be compilable, and maybe somewhat well-tested as well?
> > (Also, I don't have commit access yet.)
> 
> Policy is CVS should always compile. Unfortunately, that policy is
> hard to enforce when I'm busy with other things. I'm currently working
> on the Mac build from tarball, not watching CVS.

OK. I haven't touched anything in the code (or the autotools related
stuff); the SCons scripts are all separate files. But I'll try to only
commit once the scripts are actually working properly.


> Send me your SF name to be granted CVS access. Keep scons separate. Do
> not step on anything Kai-Uwe is doing with autotools. He's our
> autotools maintainer.
[...]

I'll have to setup a new SF account first. (I have a very old, unused SF
account, but I forgot the password---I don't even know if the account
exists anymore; they might've deleted it for inactivity.)


--T

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