[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] building only from .c files

From: Brandon J. Van Every
Subject: [Chicken-users] building only from .c files
Date: Mon, 04 Sep 2006 17:19:48 -0700
User-agent: Thunderbird (Windows/20060719)

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

Brandon Van Every

reply via email to

[Prev in Thread] Current Thread [Next in Thread]