Re: [Chicken-users] unified bootstrap

[Brandon J. Van Every]

felix winkelmann wrote:
> On 9/4/06, Brandon J. Van Every <address@hidden> wrote:
> > The CMake build can now generate a tarball that can be built both with
> > CMake and Autoconf, sans Chicken.  This is a major milestone!  Having
> > unified the distribution, it is the beginning of the official movement
> > away from Autoconf and towards CMake.  The CMake distro method is to be
> > the canonical way that Chicken is packaged up.
> >
> > And now I hope it holds up to the scrutiny of others...
>
> Very good, Brandon! A few comments:
>
> - Dependency on automake 1.9.6 isn't so good. I removed the check
>  for 1.9.6 and everything seems to work so far (using automake 1.8.3).

Why not good?  You prefer bugs in old build systems?  We don't have to 
follow the bleeding edge, but 1.8.x is rather old.  We should be using 
whatever is most recent and readily packaged.  That should be 1.9.x if 
not 1.9.6.  Realize, automake is only for people creating distros, i.e. 
you, me.  It has no effect on the end user, other than possibly 
producing a more reliable ./configure script.

> - csi.c should be distributed as well.

Have you ever had a case of csi building but chicken not building?  If 
that has happened, ok, I see your point.  If it has never happened, then 
I don't see the point, as csi.c is readily built once chicken is built.  
There isn't any silex in the build anymore, that's what csi used to be 
needed for.  We could even distribute chicken-profile.c, 
chicken-setup.c, etc. if you're really worried about it.  I mean, what's 
special about csi.c compared to the others?

> - autoconf support still will have to be maintained for the time being
>  until CMake is more widely distributed and more mature[*].

Well yeah; otherwise we would have just nuked Autoconf and not bothered 
with a unified build.  My contempt for Autoconf doesn't stand in the way 
of my recently acquired expertise with it, nor my engineering 
conservativism.  But make no mistake: Autoconf is a productivity killer 
that I personally will do little to maintain in the future.  Open source 
really becomes a nightmare when one allows others to expand support 
requirements beyond what is reasonable or sane for volunteers to do.  I 
mean, I can't believe I actually wrote this unified bootstrap garbage, 
frankly.  It's quite magical, but it's also quite sick that I did it....

And I'm even more annoyed that in Seattle, nobody's jumping at the 
chance to pay me for being so good at this stuff.  Rah rah MicroSloth.  
C# SDET Redmond build monkeys, whee!!!  If anyone mentions SQL, I'll 
shoot 'em.

> - exec'ing autogen.sh fails on UNIX boxes, I changed the command
>  to exec sh instead (passing autogen.sh as argument).

Ok dok.

> I have checked in some changes, perhaps you can check whether
> I broke something regarding the cmake stuff.
>
> Excellent work, BTW. This is great.

I hold my breath on its greatness.  Not that I don't have great 
expectations, just that I never expect to have covered everything.

> [*] CMake does funny things on linux, as I already reported to you
> (I have to invoke "make" twice. I'm using the CVS version of CMake
> and will try once more with the latest changes).

It works on 3 different Windows platforms, so this sounds like a 
Linux-specific bug.  If there's anyone else with a Linux box out there, 
they can try to reproduce your problem, to confirm that it isn't 
specific to your build environment.  If the problem is reproducible, 
then generally I have written a trivial CMake program to demonstrate it 
as a reproducer on the CMake list.

I need you to do the legwork on this one.  I have to hunt for a job in 
order to survive.  I do mean survive.  My work on Chicken has put the 
roof over my head in jeopardy.  I've made a big push to get this out the 
door over the past 2 weeks, when I should have been covering my ass.  
From here on out, it's strictly minor cleanup for me.

The last item is seeing if the CMake Windows builds handle eggs 
properly.  I'll report on the status of this in the next few days. 


Cheers,
Brandon Van Every