|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 188.8.131.52 (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: http://public.kitware.com/Dart/HTML/Index.shtml
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. http://g3d-cpp.sourceforge.net/ 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
|[Prev in Thread]||Current Thread||[Next in Thread]|