[Top][All Lists]

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

Re: [Chicken-users] building only from .c files (who needs to cross-comp

From: Brandon J. Van Every
Subject: Re: [Chicken-users] building only from .c files (who needs to cross-compile)
Date: Tue, 05 Sep 2006 01:08:33 -0700
User-agent: Thunderbird (Windows/20060719)

Matthew Welland wrote:

Why is it important for your build system to be exercised everywhere? 

It isn't important for CMake to be exercised everywhere.  It's important for CMake to be exercised *extensively*.  Right now, without a nightly build, that means being exercised by lotsa Chicken users.  If we implement a nightly build, then the build server can ensure most of the exercise.  But reality is, "gee who wants to do a build server?" was raised a month ago.  I said I ain't gonna do it, I have too much responsibility as is, and I need to get on with OpenGL support and my game development.  Nobody has lifted a finger on this issue since then.  So in practice, as long as nobody's volunteering to put together a build server, the CMake build needs to be extensively tested by users in the field.

If you 
can provide a windows installer based solution won't 99.999% of interested 
Windows chicken users be happy?

It won't work.  The legacy MSVC build has the capability of functioning as a drop-in binary, using CHICKEN_HOME to orient itself in the operating system environment.  None of the other builds do.  Not the Autoconf build, not the CMake build.  I implemented the CMake build to exactly mirror the behavior of the Autoconf builds.  Felix completed the merger of pathname variables that I started.  All paths are coming from chicken-defaults.h, and as long as that has to be compiled into Chicken, there can't be modern MSVC binaries.  People will have to use a compiler and do a build.

I'm all for eliminating this limitation of Chicken and establishing needed environmental inputs at runtime.  But, that's a non-trivial project that I don't have time for right now, and I doubt Felix does either.  Certainly, I see Felix putting his energy into lots of more important and more interesting things.  I know I care about first class OpenGL support, or even wrapping G3D if it's any good, a lot more than I care about distributing Windows binaries.

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

Cell phones, UMPC's, PDA's, embedded systems, heck - maybe even 
microcontrollers, are all valid targets to use chicken as a development 
mechanism. Choices you make in your build system will impact the ease of 
doing cross compilation and the likelyhood of chicken being used in these 
applications. I think there have been some successes IIRC but I know I have 
failed to get chicken + eggs working via cross-compilation. I have surveyed 
the scheme options for doing what I want (end user apps and robot controller 
on the Ipaq) and I think that if I could get it to work chicken would be a 
really neat solution.

I will talk to the CMake guys about the importance of cross-compilation for the embedded market.  But I will note, this is a future looking requirement.  It's not something that people are presently doing a lot of with Chicken.  I mean, I could argue that Chicken needs all sorts of things to support 3D game development, because I think Chicken could really take off there.  But it's not reality today, nobody's doing that work, not even me yet.  So I don't want perceived future-looking requirements to hold up the present-day realities of build system support.  I do think it points out that CMake needs to address the strategic issue of cross-compilation though.

I think the simplest solution would be a mechanism that dumped all the 
required C files etc. so I could cross compile without having to run chicken 
on the target system.

Darcs can now generate a distribution that does this.  You must use CMake to generate such a distro.  All generated .c files are dumped into /boot/cfiles.  Autoconf, being a one-stage build, uses all of 'em if they're present.  CMake, being a two-stage build, doesn't.  It only uses what's necessary to build a chicken, then builds everything else with that chicken.  But all the .c files are present in the distro, regardless.

Maybe something like this:

stage1: creates bootstrap csc etc, autoconf files and CMake files
    stage2, option 1: builds using CMake
    stage2, option 2: builds using Autoconf.

stage1 is not really reasonable.  You're talking about writing a 3rd build system, by hand, and maintaining it by hand.  We're really trying to contract the number of build systems, not expand them.  stage2 is just the user choosing to use either CMake or Autoconf; I see no reason to wrap it in some kind of "option" script.

It seems more reasonable to just make a CMake target that packages up all the .c files you might need for embedded work in one convenient place.  Then you provide your own Makefile or embedded build system or whatever.  Hm, a templated butt-simple Makefile might not be that hard to provide in practice.  For this to happen, various CMake variables would need to be centralized and refactored, but that's not too difficult.  Such a Makefile would be strictly a sample.  We don't have embedded systems lying around to test, nor do we even know exactly what kind of Makefile you need. 

I guess you guys will have to decide if supporting us nuts who think we need 
to do cross compilation are worth the pain to support :-)

Well no, in one sense, you're not.  You're only worth supporting if you support yourselves!  I mean, I can't even begin to pretend that I'll look into Openembedded, see what it can do, do any legwork for that, etc.  I can take patches and incorporate things, but it really behooves people to build things into Chicken that they want.  It's open source after all.  That's what's supposed to happen, people are supposed to add what they need and help carry the load.  I wanted MinGW to work reliably, so I added that.  CMake is sort of a side product of my primary goal, to get a Lisp or Scheme that's well-supported for Windows game development.

So yes, in the other sense, you're totally worth supporting.  If you support yourselves.  That's what open source is about.

Brandon Van Every

reply via email to

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