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

[Matthew Welland]

On Tuesday 05 September 2006 01:08, Brandon J. Van Every wrote:
> 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.

I didn't follow the build system discussion. What are the requirements for a 
build server? I'm imagining a system that extracts the head from darcs or svn 
and builds chicken, installs all the eggs, runs tests and then sends out a 
report via email or the web. If that is what is wanted I can provide for a 
vserver based Linux (debian or Ubuntu) system that does all that. 
Theoretically I could test under any OS that runs under vserver (or, twist my 
arm, Xen) and I could do AMD64, AMD Athlon and Pentium D dual core 
Architectures. Windows and other architectures are beyond me, although I 
would do ARM if cross compilation worked...

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

Ok. I don't fully understand but I take your word for it. It sounds like 
legacy pain.
 
> 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.

Ok. I can see the trade off. I agree on the Opengl. BTW: My son wants to use 
Chicken + opengl to develop a game. We'd love to see better Opengl support. 
I'd hate to see you distracted from that for low ROI stuff.

[snip]

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

It sounds like this is what I need to learn. Next time I get a chance to 
tackle this I will study and test this approach.
 
> 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. 

A Makefile template would be really helpful. Something that works by default 
on Linux would be an excellent starting point.

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

I'll do what I can :-)

Matt
--