[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] unified bootstrap
From: |
Brandon J. Van Every |
Subject: |
Re: [Chicken-users] unified bootstrap |
Date: |
Tue, 05 Sep 2006 00:18:03 -0700 |
User-agent: |
Thunderbird 1.5.0.5 (Windows/20060719) |
felix winkelmann wrote:
Ow - harsh words. Ok... let me think... What I need:
- fully workable build (cmake/autotools) on Linux and OS X, both from
repo and tarball
(doesn't work yet) - I can try to assist here
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.
Who can test OS X?
I still need to figure out if eggs are working on Windows CMake builds.
At last count they weren't.
Otherwise, in principle, this functionality is Done.
- tarball creation via cmake - including unsafe library files
(precompiled) and
csi/chicken-profile/chicken-setup/csc in precompiled form, since I
want to
work on making chicken more useful for cross-development; it also speeds
up the build
Please see my longer post about the conflict of interest between
Autoconf cross-compilation vs. CMake use-same-build-everywhere.
"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.
I would note that CMake is inherently faster than Autoconf for
apples-to-apples tasks. Autoconf is a shell script driven dog.
- it should *always* be possible to do
% ls
main.scm chicken.h library.c runtime.c
% cat main.scm
(print "hello, world!")
% csc -tx main.scm -uses library
% gcc runtime.c library.c main.c -o main -lm # or the Win32-equivalent
This means, the base system without any bells and whistles is able
to be wrapped together with minimal external requirements and
command-line
magic (seems to work fine, but has to be kept in mind when thinking
about
generated headers or build-generated #define's)
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?
- 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.
I don't know of anything particular - it is also rather difficult to
anticipate
what a complete cmake-based build has to fulfill, since much is just
taken
for granted currently.
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.
Cheers,
Brandon Van Every
- [Chicken-users] unified bootstrap, Brandon J. Van Every, 2006/09/03
- Re: [Chicken-users] unified bootstrap, felix winkelmann, 2006/09/04
- Re: [Chicken-users] unified bootstrap, Brandon J. Van Every, 2006/09/04
- Re: [Chicken-users] unified bootstrap, felix winkelmann, 2006/09/04
- Re: [Chicken-users] unified bootstrap, Brandon J. Van Every, 2006/09/04
- Re: [Chicken-users] unified bootstrap, Brandon J. Van Every, 2006/09/04
- Re: [Chicken-users] unified bootstrap, felix winkelmann, 2006/09/04
- Re: [Chicken-users] unified bootstrap,
Brandon J. Van Every <=
- Re: [Chicken-users] unified bootstrap, felix winkelmann, 2006/09/05
- [Chicken-users] building only from .c files, Brandon J. Van Every, 2006/09/04
- Re: [Chicken-users] building only from .c files (who needs to cross-compile), Matthew Welland, 2006/09/05
- Re: [Chicken-users] building only from .c files (who needs to cross-compile), Brandon J. Van Every, 2006/09/05
- Re: [Chicken-users] building only from .c files (who needs to cross-compile), Matthew Welland, 2006/09/05
- Re: [Chicken-users] building only from .c files (who needs to cross-compile), Brandon J. Van Every, 2006/09/06
- Re: [Chicken-users] building only from .c files, felix winkelmann, 2006/09/05
- Re: [Chicken-users] building only from .c files, john, 2006/09/05
- Re: [Chicken-users] building only from .c files, Shawn Rutledge, 2006/09/06
- Re: [Chicken-users] building only from .c files, Kon Lovett, 2006/09/06