[Chicken-users] building only from .c files

[Brandon J. Van Every]

Brandon J. Van Every wrote:
> Brandon J. Van Every wrote:
> > felix winkelmann wrote:
> >
> > > csi.c, chicken-profile.c, chicken-setup.c and csc.c will have to be
> > > included in the distribution, since it simplifies cross-compilation.
> > > Please be so kind to change the make/build files accordingly.
> > This is actually a substantial change to the build.
>
> These changes are easy on the Autoconf side, because it is a one-stage 
> bootstrap.

And now they're done, in Darcs.

> These changes are not as easy as I thought on the CMake side, because 
> it is a two-stage bootstrap.  It's doable, but it looks like a major 
> file shuffling and a half-day's work, not the fairly easy 1/2 hour 
> exercise I originally thought.

In fact, the "1/2 hour exercise" of just making the Autoconf changes has 
taken the afternoon, with the build testing that had to be done.  
Granted, I was able to waste time on comp.lang.lisp while waiting for 
builds to finish.  Anyways, making CMake use all the .c files, instead 
of just compiling Chicken and then generating whatever is missing, is a 
substantial amount of work.  I have policy questions about whether this 
is even a good idea.

Two perceived reasons for building only from .c files:

- someone may need to cross-compile
- someone may be unable to get a bootstrapped chicken to compile .scm to .c

I have serious reservations about the latter reason.  Part of the point 
of getting people to build from sources, is to test the build.  If we 
aren't actually exercising the .scm to .c part of the build, then that's 
a way for build problems to develop.  We want users to see build 
problems and report them to us, so that we can fix them.  Granted, if we 
start distributing binaries for multiple platforms, then we won't get 
the benefit of in-field build testing.  It would be down to just Felix's 
build environment and my build environment, either of which could 
develop probelms, flake, or go belly up.  I think if we start 
distributing binaries, and aren't getting any in-field build testing, 
then we need to implement a regular nightly build.

As for cross-compilation.  First, I'll define it, to avoid heat and 
angst over nothing.  "Cross-compilation" means "building an .exe on one 
platform that is meant to run on another platform."  Distributing .c 
files is not cross-compilation (at least from a C compiler's 
perspective).  Firing up the MinGW-Windows target on Linux, that's 
cross-compilation.  Various open source projects do this sort of thing; 
for instance, I believe http://www.freeciv.org is built this way.  
(Warning: Elite Timewaster Alert!)

So, who has the real need to do cross-compilation?

Felix, I hope it's not you, and that you're saying you just want to 
cross-compile for official Windows distributions.  CMake 2.4.3 can't do 
cross-compilation, although it may be implemented in the distant 
future.  That means you'd be building official Chickens using Autoconf.  
That's very much against my agenda, which is, having CMake builds 
regularly exercised and tested in-field.  It also strikes me as a really 
bad idea, putting so much faith in cross-compilation, as opposed to 
building, testing, and solving problems on proper Windows boxes.  It's 
just a whole new can of worms that I personally won't be dealing with.  
The Autoconf support is really weak / broken for MinGW, both in Chicken 
and in MSYS.  It doesn't even exist for MSVC; that's why I spent 9 
months implementing a CMake build. 

So, let's say cross-compilation isn't for official Windows builds.  
Maybe it's Unix-Unix cross-compilation or something.  Who needs to do 
it?  What are the requirements? 

And is this going to require Autoconf forever?  I'm not in favor of 
that.  CMake may not be able to cross-compile, but it is 1 build and it 
does work everywhere, unlike Autoconf.  That outweighs the convenience 
of building everything from only 1 box.  I don't want to maintain 2 
builds, especially if cross-compilation drives more and more feature 
requirements that disrupt the CMake build.

A final thorn: which build to install?  It doesn't matter with Autoconf, 
as it's only a one-stage build.  CMake is two-stage; its first stage is 
done in the /boot directory.  Let's say I built /boot entirely from .c 
files, and even throw in currently missing bits like /boot/csi, 
/boot/csc, /boot/chicken-profile, and /boot/chicken-setup.  Should I let 
the user install this?  No, I shouldn't.  I want them to do a two-stage 
bootstrap and install the final products.  I don't want to take bug 
reports on one-stage Chickens that got installed from /boot.  They're 
supposed to get the best code as the final output; that's all I want to 
maintain.

Bottom line: I think CMake should only use .c files to build 
chicken-boot.  Further products need to be derived from chicken-boot, 
i.e. csi, csc, chicken-profile, chicken-setup.


Cheers,
Brandon Van Every