On Fri, 2007-06-22 at 12:03 +0100, Simon Marlow wrote: > > Ok, you clearly have looked at a lot more build systems than I have. So you > think there's a shift from autoconf-style "figure out the configuration by > running tests" to having a database of configuration settings for various > platforms? I'm surprised - I thought conventional wisdom was that you should > write your build system to be as independent as possible from the name of the > build platform, so that the system is less sensitive to changes in its > environment, and easier to port. I can see how wiring-in the parameters can > make the system more concrete, transparent and predictable, and perhaps that > makes it easier to manage. It's hard to predict whether this would improve > our > situation without actually doing it, though - it all comes down to the > details.
This misses the point. The 'suck it and see' idea fails totally for cross-compilation. It's a special case. The right way to do things is to separate the steps: (a) make a configuration (b) select a configuration logically. This is particularly important for developers who are using the same code base to build for multiple 'platforms' on the same machine. With the above design you can have your cake and eat it too .. :) Thats the easy part.. the HARD part is: every 'system' comes with optional 'add-on' facilities. These add-ons may need configuration data. Often, you want to add the 'add-on' after the system is built. So integrating the configuration data is an issue. Felix build system allows add-on packages to have their own configuration model. It happens to be executed on the fly, and typically does your usual suck it and see testing (eg .. where are the SDL headers? Hmm ..) This design is wrong of course ;( -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
