[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: Wed, 06 Sep 2006 00:45:53 -0700
User-agent: Thunderbird (Windows/20060719)

Matthew Welland wrote:

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

Your laundry list of requirements sounds about right, although of course the devil is in the details.  Kitware offered to do some kind of hosting with the Dart Dashboard.  That's this thing:
The advantage of Dart is it would integrate rather well with the CMake build, it's designed to do so.

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.

Yes, legacy pain.  Chicken paths are hardwired at build time, and refactoring that will take significant work.

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.

Heh!  Well, I'm evaluating G3D as to whether it's worth Chickenizing.  They're transitioning to a CMake build, they're OpenGL based, and they're a mature project.  What I really want to know is, can I implement a scene graph in straight Scheme and not be bothered with C++ nonsense.  Most 3D engines have the problem that they want you to do everything their way, and their way is the C++ way.  But G3D purports to be quite a bit less than a 3D engine, which for my purposes would be an advantage.

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.

Not much to learn!  Follow the directions in INSTALL-CMake.txt, then type "make dist."  This will give you a distro that's bootable without Chicken, with all needed .c files in /boot/cfiles.

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

If you can provide such a Makefile, that would give me a much better idea what to template.

Brandon Van Every

reply via email to

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