On Fri, 2009-02-13 at 09:57 -0800, Donnie Berkholz wrote: > On 08:58 Fri 13 Feb , Brian Paul wrote: > > Maciej Cencora wrote: > > > What's the deal with all those build systems? Can't we agree on one and > > > drop > > > the rest? > > > > We'll probably get there one day. > > > > I'm still pretty attached to the old static config file system. I've > > never been much of a fan of autoconf (for reasons I've listed in the past). > > > > Jose's been maintaining scons but I haven't used it too much myself yet. > > Scons seems simpler/nicer than autoconf and works on more platforms > > (Windows in particular) so that'd probably be my choice if there were a > > gun to my head... > > This whole post is about why scons shouldn't become the only build > system, so if you don't care about that, you can stop reading now. > > > Scons has a lot of problems from a packager's point of view. For one, it > ignores environment variables so PATH, CFLAGS, LDFLAGS, CC, and so on > are ignored. It's most convenient for packagers to simply run a script > and set up the environment, rather than having to edit or patch files, > which is unreliable and can be tricky. KDE decided not to go with SCons > because of lack of upstream support, difficulty of configuration, > problems with OS X, etc: > > "The KDE individuals who tried to bring SCons into a shape that made > it fit for building such a huge project felt they didn't have any > support from the upstream SCons developers. There were major problems > building KDE on non-Linux platforms with SCons (e.g. on OS X); in > general they felt it did not yet have a mature configuration system. > The only option down that road was to create major SCons fixes and > patches on their own. Since these changes would not likely be > included in the upstream sources, it would require permanent > maintenance of the fixes in a separate repository. In effect, this > would have amounted to a fork of SCons. KDE developers would have had > to maintain the new build system entirely on their own." > -- http://lwn.net/Articles/188693/ > > My understanding is that MinGW runs nicely on Windows systems and will > deal with autotools just fine. Is the requirement to build using the > Microsoft compilers rather than to build and run on Windows? If so, that > seems pretty odd and has little relationship to what the goals should > be.
Gallium3D currently builds on Linux userland (gcc), Windows user-space (MSVC, MinGW, and MinGW cross-compilers) and Windows kernel-space (MSVC only unfortunately). Mesa3D/Gallium3D scons build system supports all those combinations, *today*. Jose ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
