Re: [Chicken-users] unified bootstrap

[felix winkelmann]

On 9/5/06, Brandon J. Van Every <address@hidden> wrote:
> Linux appears to have a bug in CMake, not the build itself.  I will
> wager that a workaround is pretty trivial, just shoving more
> dependencies in somewhere.  But the bug, whatever it is, does need to be
> reported.

I've done so.

> Who can test OS X?

I will do that.

> I still need to figure out if eggs are working on Windows CMake builds.
> At last count they weren't.

I will also test this. At least with a manually downloaded and untarred
egg chicken-setup should work.

> Otherwise, in principle, this functionality is Done.

Very good.

> "Speeding up the build" is not a weighty factor compared to other issues
> like stability, uniformity, and extensive testing of always-used code
> paths.  The CMake bootstrap is always going to be slower than the
> Autoconf build, because it is a two-stage bootstrap, and in that manner
> achieves more than the Autoconf build does.  With CMake, I don't have to
> worry what kind of old compiler is used; with Autoconf, you do.  I do
> not think it at all wise to short-circuite the two-stage bootstrap, even
> as an option, just so people can build things faster.  Making people
> test the canonical build, by building it, is far more important.
>
> I also have to ask what kind of slowness is observed and what build
> speedups are important.  I'm developing on an 866 MHz Pentium III with
> 512 MB RAM running Windows 2000.  A full build certainly gives me time
> to multitask, but it's a matter of tens of minutes, not hours.  I
> haven't wall clock timed it; I'll make a formal note of it in the
> future.  I will wager that on more recent hardware, build times are much
> quicker, but I could be mistaken as the speed of IO doesn't have to
> track increases in CPU power.

Buildspeed is not critical - it was merely another point.

> I would note that CMake is inherently faster than Autoconf for
> apples-to-apples tasks.  Autoconf is a shell script driven dog.

I fully agree.

> Then I think this should be integrated as a formal build target, and
> regularly stress tested.  Frankly I have always wondered why Chicken
> needs so much libchicken gobbledygoo to get rolling.  If it really
> doesn't, how about a "chicken-small" target or some such?  Or more
> poetically, a "chick" target?

The gobbledygoo is due to dynamic/static linking issues on different
platforms, most notably the "__declspec" sickness that has to take
place on Windows.

> > - At some stage PCRE has to be built into chicken - but, to remove some
> >  pressure, I decided to do it later (after the next release); I
> > expect to be able
> >  to integrate this myself, though (I have to be, anyway)
> >
>
> Doesn't strike me as a big build issue at any rate.

Me neither.

> Well, if that's the culture, then the only way is to kick it out the
> door and see what floats back.  Billion dollar software empires have
> been built on this model, i.e. Microsoft, so we shouldn't be squeamish
> about it.  All we can do is anticipate and test the things we can think
> of.  Can't polish to perfection forever before releasing.  We don't have
> that kind of manpower, and it wouldn't necessarily be wise even if we did.

We'll do that. In the moment building via autotools and cmake works
(modulo the little linux problem) under Linux. Creating the distribution
through cmake works fine, too. I'm doing more tests (win32/msvc and OS X)
and hopefully, a new release can be rolled out soon.


cheers,
felix

--
http://galinha.ucpel.tche.br:8081/blog/blog.ssp