Dan Nicholson wrote: > On Dec 10, 2007 7:12 AM, Brian Paul <[EMAIL PROTECTED]> wrote: >> Dan Nicholson wrote: >>> This patch set adds initial autoconf support for Mesa. Previous >>> discussion was that full autotools was not desired. This approach is >>> less invasive by working in conjunction with the current Mesa configs >>> system. The configure script simply populates the file configs/autoconf, >>> allowing the user to build with `make autoconf', just like any of the >>> other targets. >> [...] >> >> My initial reaction was God no, not autoconf, but I'll try to stay >> open-minded. It sounds like you've come up with a minimal/simplified >> application of autoconf that shouldn't be too invasive or ugly. Give me >> some time to grab your repo and look things over. > > I recall how you felt about this last time we had this discussion :) > It's only autoconf, though, and not the bizarre backdoor traps of > automake. That said, it's your project, and if you really don't want > this, then I wouldn't apply the patches. I just think that the current > system needs to be beefed up in some way. There are currently 40 > config files for Linux for all the various options and architectures. > On top of that, if you need to build Mesa in a custom way (like > changing the install prefix), then you're grovelling through the > configs and patching them. It should be easier. > >> One of the biggest problems I had with automake/autoconf/etc in the past >> was poor support on non-gnu platforms. If the current config-based >> system can co-exist with the new autoconf approach, that problem should >> be avoided. I realize not a lot of people are still running Mesa on >> AIX, Solaris, etc. but it really sucks when the code is amenable to your >> platform but the build system prevents you from actually using it. >> >> The config-based build system certainly isn't perfect, but it's simple >> and has allowed people to get Mesa up and running on new systems (like >> bluegene) with little effort. > > I'm not knocking the configs system entirely. It certainly has its > moments with it's simplicity. Taking the bluegene example and looking > at configs/bluegene-osmesa, using the configure script would work out > of the box for them. > > export CC=/bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-gcc > export CXX=/bgl/BlueLight/ppcfloor/blrts-gnu/bin/powerpc-bgl-blrts-gnu-g++ > export CFLAGS="-O3 -ansi -pedantic" > export CXXFLAGS="-O3 -ansi -pedantic" > > ./configure --with-driver=osmesa --enable-static > > No new files, no hardcoding paths, takes the user's options, etc.
Yes, but the above is basically a magical incantation that nobody would have a clue about if it weren't explicitly documented. That's the kind of situation in which a "pre-packed" config saves a lot of effort. I agree that autoconf would be nicer for managing the various combos of debug vs. opt, static vs. dynamic, install paths, etc. Anyway, I'll try to review your changes in the next day or so... -Brian ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
