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 -- _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
