Re: Configure.pl and the history of the world
I began a little piece of this ages ago- attempting to translate the parts that identify the platform ($^O, essentially) from metaconfig to something we could put into Configure.pl. Even that relatively simple chore wasn't too easy. I should still have the work-in-progress code for that around here somewhere. --Josh At 19:47 on 03/16/2004 EST, Dan Sugalski [EMAIL PROTECTED] wrote: Hey folks. Now that we're integrating in with perl 5, a few things are becoming really obvious. First, we really need to work on the embedding interface. Memory handling, signals, and I/O are the biggies there. Working on that, though not fast enough for Arthur. Second, we're running over the same problems in system configuration that perl (and python, and ruby, for that matter) have already run across. Moreover, we're making the same decisions, only... differently. This is silly both because we're re-inventing the wheel and we're making the wheel with metric nuts instead of english. We could go dig through perl's configure every time we add a new environment probe, but that'll get really old really quick. Instead, what I'd like is for someone (Oh, Brent... :) to go through perl's configure and dig out the tests in it, as well as the defaults that it has and just get all the config variables in once and for all. While some of what's in there we don't have to deal with (joys of C89 as a minimum requirement) there's a lot of hard-won platform knowledge in there and ignoring it's foolish. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Configure.pl and the history of the world
At 10:22 on 03/18/2004 EST, Andrew Dougherty [EMAIL PROTECTED] wrote: 5. You probably don't need to support Eunice anymore. I think i'm not the only one who would be deeply upset if I ceased to be congratulated for not running Eunice though. --Josh
Re: Configure.pl and the history of the world
Josh Wilmes wrote: At 10:22 on 03/18/2004 EST, Andrew Dougherty [EMAIL PROTECTED] wrote: 5. You probably don't need to support Eunice anymore. I think i'm not the only one who would be deeply upset if I ceased to be congratulated for not running Eunice though. Ah, but since we'll have One Configure To Rule Them All, we can replace it with something more modern: Congratulations, you aren't running Windows. (I expect the OS probe step to be noisy, because we don't know what the OS is yet, so we'll probably be spewing out error messages left and right as we stumble about without knowing if we can even do Unix-style I/O redirection.) -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Configure.pl and the history of the world
On Tue, 16 Mar 2004, Larry Wall wrote: On Tue, Mar 16, 2004 at 06:00:51PM -0800, Brent Dax Royal-Gordon wrote: : Dan Sugalski wrote: : Instead, : what I'd like is for someone (Oh, Brent... :) to go through perl's : configure : : Gulp. I'm sure Andy can give you *reams* of advice on Perl 5's configurator, especially on how it all ought to have been done differently in the first place. :-) Sure, but Run away -- now! is probably not the sort of advice you had in mind :-). The perl5-build at perl.org mailing list is a good place to ask specific Configure-related questions -- all of the perl5/Configure maintainers participate, and it's archived too. There's also the much-neglected perl6-build mailing list. I won't have time for a couple of weeks to write anything up in detail (though you should feel free to nudge me again in a couple of weeks when I forget to do so), but a few quick thoughts off of the top of my head: There are some good features of metaconfig/Configure that I think perl6 and parrot would do well to emulate: 1. It tests for features, not for platforms. End users will try to build parrot and perl6 on platforms the developers don't have access to. Often, those platforms will be very similar to other known ones, and, if the configuration system tests for features, they might be able to get pretty far. Platforms also change names. Of course some things (such as the name of the compiler to use on AIX to successfully compile threaded programs) really are platform-specific, so don't be too rigid. 2. It separates out individual tests (or groups of closely-related tests) into easily-maintained units. These units contain all the relevant information needed for that test: Documentation of the relevant variables, the prerequisites for the test, and the actual test itself. The task of assembling these units together and making the appropriate files in the distribution is automated by a tool (known as metaconfig). 3. It is generally well-documented and well-commented. By design, every variable set by Configure must have a Glossary entry. By convention, many of those entries are actually correct and useful. Most of the units that are doing something odd or complex also have fairly extensive comments about what's going on and why. (Many of those comments don't make it to the final Configure product, but are in the original metaconfig units.) I can look back at something I did nearly 10 years ago and have a chance of understanding why it was necessary. 4. It is flexible. It's possible to override nearly everything in Configure, by command-line options, by hints files, by Policy files, by override files (config.over) or by interactively answering questions. 5. It has lots of clever optimizations. (For example, the nm-scan and header-file checks are particularly efficient, but can be overridden or backed up by other tests.) 6. It's written in maximally portable and efficient v7 Bourne Shell, and studiously avoids all modern constructs, such as functions, that might make it easier to understand. Instead, it relies on multiple layers of shell quoting and string evaluations, and deliberately uses control-flow structures designed for maximum efficiency on 1980s-era systems. Of course it does carry considerable baggage that could well be jettisoned. A few off the top of my head: 1. It is Unix-centric. 2. It's description of the build process does not distinguish clearly among three separate functions: Compiler (used to turn C source code into object files.) Linker (used to link object files + libraries together to make an executable) Shared-library Builder: (used to combine object files into a shared library). 3. It doesn't handle circular dependencies well. For example, consider various levels of 64-bit support. In order to determine whether or not the system supports 64-bit operations of various sorts, it would be useful to compile and run various test programs. However, in order to compile and run test programs in 64-bit mode, you might need to change the compiler, compiler options, and/or libraries. Once you do that, you might need to go back and re-calculate various other things (such as the size or type of variable used for off_t). Perl5's Configure does this via a complicated set of call-back units. 4. It spits out a monolithic script, rather than a series of function calls. 5. You probably don't need to support Eunice anymore. There are also some things that autoconf structurally does better. I haven't looked at it in ages, but two that spring to mind immediately are: 1. Autoconf does a better job building up and using an intermediate 'config.h' file and partial library list. It knows how to go look for and add an additional library, if needed. (Though again, adding in a new library could potentially invalidate everything that came before, so be wary.) 2. Autoconf offers more extensive
Re: Configure.pl and the history of the world
On Wed 17 Mar 2004 02:31, Larry Wall [EMAIL PROTECTED] wrote: On Tue, Mar 16, 2004 at 07:47:25PM -0500, Dan Sugalski wrote: : Second, we're running over the same problems in system configuration : that perl (and python, and ruby, for that matter) have already run : across. Moreover, we're making the same decisions, only... : differently. This is silly both because we're re-inventing the wheel : and we're making the wheel with metric nuts instead of english. : : We could go dig through perl's configure every time we add a new : environment probe, but that'll get really old really quick. Instead, : what I'd like is for someone (Oh, Brent... :) to go through perl's : configure and dig out the tests in it, as well as the defaults that : it has and just get all the config variables in once and for all. : While some of what's in there we don't have to deal with (joys of C89 : as a minimum requirement) there's a lot of hard-won platform : knowledge in there and ignoring it's foolish. Er, yes, but...you might actually do better by looking at all the metaconfig units that go into generating Configure. Then you'd at least know what all the dependencies are. Better even, the metaconfig units are loaded with comments that do not make it to the final Configure script. Oh, and metaconfig will gladly do the work of weeding out the tests you're not interested in. But the metaconfig units still hold the code and comment, so you don't have to #ifdef/comment-out those unwanted parts and clutter the code Not using metaconfig (or something like it) would be the biggest mistake. It's actually next to impossible to maintain something like a Configure script directly. Who would maintain it? I've got no problem (yet) with maintaining it for perl5, and I'm even working on backward compatibility for 5.005._xx, so Configure and hints are usable for the complete actual range, and thus save huge amounts of backporting time The problem is that there are only a few knowledgable/interested in doing this, ehh, less interesting part of the project (I still like it) Larry -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.0, 5.9.x, and 806 on HP-UX 10.20 11.00, 11i, AIX 4.3, SuSE 8.2, and Win2k. http://www.cmve.net/~merijn/ http://archives.develooper.com/[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Configure.pl and the history of the world
Hey folks. Now that we're integrating in with perl 5, a few things are becoming really obvious. First, we really need to work on the embedding interface. Memory handling, signals, and I/O are the biggies there. Working on that, though not fast enough for Arthur. Second, we're running over the same problems in system configuration that perl (and python, and ruby, for that matter) have already run across. Moreover, we're making the same decisions, only... differently. This is silly both because we're re-inventing the wheel and we're making the wheel with metric nuts instead of english. We could go dig through perl's configure every time we add a new environment probe, but that'll get really old really quick. Instead, what I'd like is for someone (Oh, Brent... :) to go through perl's configure and dig out the tests in it, as well as the defaults that it has and just get all the config variables in once and for all. While some of what's in there we don't have to deal with (joys of C89 as a minimum requirement) there's a lot of hard-won platform knowledge in there and ignoring it's foolish. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Configure.pl and the history of the world
On Tue, Mar 16, 2004 at 07:47:25PM -0500, Dan Sugalski wrote: : Second, we're running over the same problems in system configuration : that perl (and python, and ruby, for that matter) have already run : across. Moreover, we're making the same decisions, only... : differently. This is silly both because we're re-inventing the wheel : and we're making the wheel with metric nuts instead of english. : : We could go dig through perl's configure every time we add a new : environment probe, but that'll get really old really quick. Instead, : what I'd like is for someone (Oh, Brent... :) to go through perl's : configure and dig out the tests in it, as well as the defaults that : it has and just get all the config variables in once and for all. : While some of what's in there we don't have to deal with (joys of C89 : as a minimum requirement) there's a lot of hard-won platform : knowledge in there and ignoring it's foolish. Er, yes, but...you might actually do better by looking at all the metaconfig units that go into generating Configure. Then you'd at least know what all the dependencies are. Oh, and metaconfig will gladly do the work of weeding out the tests you're not interested in. Not using metaconfig (or something like it) would be the biggest mistake. It's actually next to impossible to maintain something like a Configure script directly. Larry
Re: Configure.pl and the history of the world
Dan Sugalski wrote: Instead, what I'd like is for someone (Oh, Brent... :) to go through perl's configure Gulp. -- Brent Dax Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker Oceania has always been at war with Eastasia.
Re: Configure.pl and the history of the world
On Tue, Mar 16, 2004 at 06:00:51PM -0800, Brent Dax Royal-Gordon wrote: : Dan Sugalski wrote: : Instead, : what I'd like is for someone (Oh, Brent... :) to go through perl's : configure : : Gulp. I'm sure Andy can give you *reams* of advice on Perl 5's configurator, especially on how it all ought to have been done differently in the first place. :-) Larry
Re: Configure.pl and the history of the world
Larry Wall wrote in perl.perl6.internals : Not using metaconfig (or something like it) would be the biggest mistake. It's actually next to impossible to maintain something like a Configure script directly. Actually as parrot already uses IIUC variables set up by Configure, I think one could drop the or something like it. The biggest drawback of Configure is that it's UNIX-centric. But it's yet impressively portable and backwards-compatible (ask any Richard Clamp). [Some time ago Raphael Manfredi, bored by the autocrap tools (as he names it) expressed the intent to work on metaconfig again, but then he disappeared again.]