All of these alternative build systems are a PITA on one system or another. If it requires jam, cmake or anything that requires installing prerequisites 9 times out of 10 I won't even try that software unless there is a binary install available somewhere or a pre-assembled Makefile.
I thought that from an end user perspective all that is needed with autoconf is sh. The requirement is on the developer to run autoconf before making the tar. I thought autoconf itself is not needed on the platform where the build is being done, correct?? For fossil you could keep the files generated by autoconf (not the ./configure step but the initialization step) checked in. Then it is just ./configure && make install on most systems. For anything weird (e.g. windows) provide a Makefile.win32 or similar. Alexanders suggestion of premake4 is the only one that piqued my interest. Distribute the source along with fossil and use autoconf to build it and then premake4 to build fossil ... just kidding ... although for some twisted reason that wacky idea actually appeals to me. On Tue, Jun 14, 2011 at 10:18 PM, Martin Gagnon <eme...@gmail.com> wrote: > Le 2011-06-14 à 22:19, Graeme Gill <grae...@argyllcms.com> a écrit : > > > Stephan Beal wrote: > >> Another suggestion nobody has made yet: jam. It can be distributed in > >> static-binary form directly with the source tree (i've seen this done in > a > >> couple projects, and i know it can build on some rather obscure > systems). i > >> can't personally speak for jam's usability - read about it but never > used it > >> myself. > > > > I use Jam in my cross-system project, but I don't like the default > > Jambase, and completely re-wrote it to suite my ideas of how a build > > system should work. I rather like Jam itself since it's quite flexible > > and works well on the systems I use if for, with very few system specific > > cases in the Jamfiles, but (not surprisingly) people who want to build > > my software complain about not using a "standard" system like AutoTools, > > even though such systems aren't suitable for MSWin/VC++ type > environments. > > The bottom line is that it does make everyone equal - they all have to > > install/compile Jam first! (Jam is available on some Linux systems as a > > standard package.) > > > > [ My experience with CMake hasn't endeared it to me. AutoTools is > > pretty awful, and always seems to be breaking. QMake seems cleaner > > than most systems. I'm sticking with Jam for my code, as it's clean > > and I can now maintain it easily.] > > > > Graeme Gill. > > > > All that thread start when someone post about haiku that need different > libs flags in order to link properly. If a OS like Haiku don't have this > jam, all that is pretty pointless. > > And for myself which use QNX, I really don't want to think about how I'll > make work jam on it. It was actually already compiling on QNX with the > standard Makefile anyway. > > As others pointed it out before, I really think that to automaticaly > generate this Makefile, if we really have to go that way, we should need > something already on all system; like /bin/sh. So is the case of the > configure script produced by this autowhatever, but one maintainers need the > too have autowhatever installed to maintain the resulting configure script, > which is not as bad as requiring extra tool on every system that build > fossil. Is it an acceptable trade off knowing how much everybody "love" this > autowhatever? > > -- > Martin > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
