Configure changes
Brent "Dax" Royal-Gordon
interfering as it has the last couple days, I'd like to get something
out on the list for Piers to link to. ;^)
I've made some fairly significant changes to Configure in the last week
or so. Starting from the top:
1. If you auto-generate a chunk of Makefile and want to shove it into
Configure::Data, use a TEMP_ prefix on the key. That way, it'll
be stripped out before finding its way to Parrot::Config and
library/config.imc.
2. Configure steps should not output anything under normal
circumstances--not even if it's in parentheses or square brackets.
The '--verbose' switch is suggested for a small amount of output.
(The old use of '--verbose'--to print out every single write to
Configure::Data--is now available by using '--verbose=2'.)
3. Miniparrot's settings are now all in one place, rather than being
scattered across a dozen steps. That doesn't mean that
miniparrot's actually building, as mentioned in a thread earlier
this week.
4. I've already combined a few steps in config/gen; config/auto will
see more extensive combinations. When I'm done, the Configure
output will look something like this:
Checking MANIFEST..........................................done,
Setting up Configure's data structures.....................done.
Tweaking settings for miniparrot...........................done.
Loading platform and local hints files.....................done.
Enabling optimization......................................done.
Determining nongenerated header files......................done.
Determining what C compiler and linker to use..............done.
Determining what types Parrot should use...................done.
Determining what opcode files should be compiled in........done.
Setting up experimental systems............................done.
Determining what pmc files should be compiled in...........done.
Probing for C headers......................................done.
Probing your types.........................................done.
Determining architecture, OS and JIT capability............done.
Determining what allocator to use..........................done.
Probing your C compiler....................................done.
Probing your standard C library............................done.
Configuring ICU if requested...............................done.
Generating C headers.......................................done.
Generating runtime/parrot/include..........................done.
Generating core pmc list...................................done.
Generating build files.....................................done.
Moving platform files into place...........................done.
Recording configuration data for later retrieval...........done.
A lot of specialized steps (such as "Determining if your C library
supports memalign" and "Verifying that the compiler supports function
pointer casts") will be combined into a few more general steps in this
scheme.
It'd be nice to rename some of the steps once I'm finished with them, to
reflect their new functions. IIRC that's a hassle, though, so I'm not
by any means going to insist on it.
Comments welcome on any part of this whole scheme.
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Leopold Toetsch
> Comments welcome on any part of this whole scheme.
I really like the cleanup. But the whole scheme needs more steps: That's
mainly probing for much more items, e.g. threads, signals, socket
stuff, which isn't quite simple. You first have to determine necessary
headers before you can try to probe for functions (s. inet_aton vs
inet_pton).
I think that the F<hints/> should contain more information. When you know
its a POSIXish system or Win32 you can make some assumptions and
continue from there.
leo