Right now configure.pl pulls a bunch of configuration information straight out of the current perl configuration. We need to stop that, and this is as good a time as any.
If someone could go through and make a list of what info configure.pl pulls from perl, I'll start writing (or snagging :) the probing code to do it ourselves, so we can be perl-free, at least from a configuration standpoint. -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
On Mon, 2004-09-06 at 12:42, Dan Sugalski wrote: > Right now configure.pl pulls a bunch of configuration information > straight out of the current perl configuration. We need to stop that, > and this is as good a time as any.
> If someone could go through and make a list of what info configure.pl > pulls from perl, I'll start writing (or snagging :) the probing code > to do it ourselves, so we can be perl-free, at least from a > configuration standpoint.
I think right now that info is all in config/init/data.pl, and it's actually fairly well documented. Here's all of the variables that rely on the %Config data from Perl's Config.pm:
optimize => $optimize ? $Config{optimize} : '', # Compiler -- used to turn .c files into object files. # (Usually cc or cl, or something like that.) cc => $Config{cc}, ccflags => $Config{ccflags}, ccwarn => exists($Config{ccwarn}) ? $Config{ccwarn} : '', # Flags used to indicate this object file is to be compiled # with position-independent code suitable for dynamic loading. cc_shared => $Config{cccdlflags}, # e.g. -fpic for GNU cc. # Linker, used to link object files (plus libraries) into # an executable. It is usually $cc on Unix-ish systems. # VMS and Win32 might use "Link". # Perl5's Configure doesn't distinguish linking from loading, so # make a reasonable guess at defaults. link => $Config{cc}, linkflags => $Config{ldflags}, # ld: Tool used to build dynamically loadable libraries. Often # $cc on Unix-ish systems, but apparently sometimes it's ld. ld => $Config{ld}, ldflags => $Config{ldflags}, libs => $Config{libs}, exe => $Config{_exe}, # executable files extension ld_shared => $Config{lddlflags}, ar => $Config{ar}, ranlib => $Config{ranlib}, make => $Config{make}, make_set_make => $Config{make_set_make},
-- Aaron Sherman <a...@ajs.com> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
On Mon, 2004-09-06 at 18:29, Aaron Sherman wrote: > On Mon, 2004-09-06 at 12:42, Dan Sugalski wrote: > > If someone could go through and make a list of what info configure.pl > > pulls from perl, I'll start writing (or snagging :) the probing code > > to do it ourselves, so we can be perl-free, at least from a > > configuration standpoint. > optimize => $optimize ? $Config{optimize} : '', > # Compiler -- used to turn .c files into object files. > # (Usually cc or cl, or something like that.) > cc => $Config{cc}, > ccflags => $Config{ccflags}, > ccwarn => exists($Config{ccwarn}) ? $Config{ccwarn} : '', > # Flags used to indicate this object file is to be compiled > # with position-independent code suitable for dynamic loading. > cc_shared => $Config{cccdlflags}, # e.g. -fpic for GNU cc. > # Linker, used to link object files (plus libraries) into > # an executable. It is usually $cc on Unix-ish systems. > # VMS and Win32 might use "Link". > # Perl5's Configure doesn't distinguish linking from loading, so > # make a reasonable guess at defaults. > link => $Config{cc}, > linkflags => $Config{ldflags}, > # ld: Tool used to build dynamically loadable libraries. Often > # $cc on Unix-ish systems, but apparently sometimes it's ld. > ld => $Config{ld}, > ldflags => $Config{ldflags}, > libs => $Config{libs}, > exe => $Config{_exe}, # executable files extension > ld_shared => $Config{lddlflags}, > ar => $Config{ar}, > ranlib => $Config{ranlib}, > make => $Config{make}, > make_set_make => $Config{make_set_make},
Add to that:
archname (used in several config/auto/*.pl files) sig_name (used in config/auto/*.pl files, but also t/ and lib/) ./config/auto/pack.pl:39: if (($] >= 5.006) && ($size == $longsize) && ($size == $Config{longsize}) ) { ./config/auto/pack.pl:45: elsif ($size == 8 || $Config{use64bitint} eq 'define') { parrotbug/ uses a bunch of Config fields too
And then there's everything that uses an i_* field from Configure::Data, but I only SEE i_malloc getting called there.
And finally, I don't know what uses config_lib.pasm, but it seems to write out a copy of Perl's Config with some extra stuff added in to runtime/parrot/include/config.fpmc, so anything that references that structure too... anyone know what references that?
-- Aaron Sherman <a...@ajs.com> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
On Mon, 2004-09-06 at 18:29, Aaron Sherman wrote: > I think right now that info is all in config/init/data.pl, and it's
Scratch that. I was grepping through the tree for "Config{" which turns out to not catch the way %Config is used in most of the tree... I'll have a look and get you the details.
-- Aaron Sherman <a...@ajs.com> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
On Mon, Sep 06, 2004 at 12:42:16PM -0400, Dan Sugalski wrote: > Right now configure.pl pulls a bunch of configuration information > straight out of the current perl configuration. We need to stop that, > and this is as good a time as any.
> If someone could go through and make a list of what info configure.pl > pulls from perl, I'll start writing (or snagging :) the probing code > to do it ourselves, so we can be perl-free, at least from a > configuration standpoint.
If I can help testing cross compilation stuff please tell me. Unfortunately I don't know enough of the Perl/Parrot internals to be really useful for coding, but anyway. Being able to use Perl on embedded systems would be pretty cool - it was never really possible with perl 5.
Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
On Tue, Sep 07, 2004 at 07:26:22AM +0200, Robert Schwebel wrote: > If I can help testing cross compilation stuff please tell me. > Unfortunately I don't know enough of the Perl/Parrot internals to be > really useful for coding, but anyway.
Would autoconf/automake be an option for the C part of parrot?
Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
On Tuesday 07 September 2004 07:52, Robert Schwebel wrote:
> Would autoconf/automake be an option for the C part of parrot?
No, its only available on a few systems.
Some months ago, I tried to cross compile Parrot to ARM (Zaurus), and to compile Parrot directly on the Zaurus, with no success (mostly due to lack of time).
On Tue, Sep 07, 2004 at 02:00:14PM +0200, Jens Rieks wrote: > On Tuesday 07 September 2004 07:52, Robert Schwebel wrote: > > Would autoconf/automake be an option for the C part of parrot? > No, its only available on a few systems.
How do you mean that? You surely don't want to run the compiler directly on the target system, won't you? Besides that, autoconf runs on every platform which has a working shell, so if you have a bash on your PXA and if you run the compiler stuff on your target it should work anyway.
Autoconf has the advantage that it has solved all the problems which will surely come up with a makefile system sooner or later, and it is established technology for nearly all possible platforms if it is done right.
At the moment we have the situation that cross compilation doesn't work at all.
Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
On Tue, 2004-09-07 at 08:00, Jens Rieks wrote: > On Tuesday 07 September 2004 07:52, Robert Schwebel wrote: > > Would autoconf/automake be an option for the C part of parrot? > No, its only available on a few systems.
Ok, this is probably a moot conversation because Metaconfig (http://www.linux-mag.com/2002-12/compile_03.html) was written by Larry Wall for rn, and the Perl community has some serious social inertia when it comes to switching to any other configuration tool.
That said, autoconf is only available on a few systems. A few being defined as everything I've ever heard of.
Seriously, I've never come across any system that lacked autoconf support AND which a high level language like those that would target Parrot, ran on. If you're referring to the number of systems that have autoconf itself actually INSTALLED by default, that's just as moot as the fact that almost no systems have Metaconfig installed. You never run Metaconfig or autoconf as an end-user/installer, you run the resulting [Cc]onfigure script.
autoconf (+automake, &etc.) is an excellent tool, and while Metaconfig is somewhat more limited, it too is an excellent tool, especially for handling high level languages. Neither tool is "wrong" for the job, but I expect that people who install Parrot will not be shocked by the classic "-des -Dprefix=/usr" type of invocation....
On Tue, 7 Sep 2004, Aaron Sherman wrote: > On Tue, 2004-09-07 at 08:00, Jens Rieks wrote: > > On Tuesday 07 September 2004 07:52, Robert Schwebel wrote: > > > Would autoconf/automake be an option for the C part of parrot? > > No, its only available on a few systems.
> Ok, this is probably a moot conversation because Metaconfig > (http://www.linux-mag.com/2002-12/compile_03.html) was written by Larry > Wall for rn, and the Perl community has some serious social inertia when > it comes to switching to any other configuration tool.
Well initially, it was mostly technical (and licensing) issues that drove the decision. (See the section "=head2 Autoconf" in perl5's Porting/pumpkin.pod for details.) I'd agree there's plenty of social inertia now as well.
> That said, autoconf is only available on a few systems. A few being > defined as everything I've ever heard of.
Both autoconf and metaconfig assume a unix-like environment. Ambitious plans for parrot's configure include non-unix environments too, such as VMS and all the ports where perl5 uses a manually-generated config.* template.
On Tue, Sep 07, 2004 at 10:52:01AM -0400, Aaron Sherman wrote: > Ok, this is probably a moot conversation because Metaconfig > (http://www.linux-mag.com/2002-12/compile_03.html) was written by Larry > Wall for rn, and the Perl community has some serious social inertia when > it comes to switching to any other configuration tool.
Well, I have personally no problem with metaconfig, it is indeed much more perlish than autoconf, and that's probably not the worst thing when it comes to a Perl runtime engine.
The question is (and that's something I don't know much about) if metaconfig is able to handle cross builds correctly. Not being able to crosscompile Perl for embedded systems was in way too much projects a showstopper for using Perl for me, so doing something against this would something I would probably spend some time into if it makes sense at all. At the time when perl 5 started metaconfig was surely a good thing, but I doubt it can do what autotools is able to manage today. But that's probably a political decision.
Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hornemannstraße 12, 31137 Hildesheim, Germany Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
On Tue, Sep 07, 2004 at 10:52:01AM -0400, Aaron Sherman wrote: > Seriously, I've never come across any system that lacked autoconf > support AND which a high level language like those that would target > Parrot, ran on. If you're referring to the number of systems that have
On Tue, 2004-09-07 at 11:59, Andrew Dougherty wrote: > Both autoconf and metaconfig assume a unix-like environment. Ambitious > plans for parrot's configure include non-unix environments too, such as > VMS and all the ports where perl5 uses a manually-generated config.* > template.
autoconf assumes m4 and shell and some other primitive tools, all of which have GNU ports to just about everything I've had to touch. VMS is the bastard child of autoconf right now, but back when VMS was a platform that folks used, it certainly was supported (as late as 1999 it worked great). I don't think it's the UNIXishness of the platform as much as the popularity of the platform that guides autoconf support (e.g. any platform for which patches are contributed). The guy who tried to update the autoconf 1.x version this year kind of kicked the autoconf guys in the shins verbally and got nowhere as a result. He then forked it and has since apparently dropped support.
That said, if you have a manually generated template as you do for Perl 5, you can do the same for autoconf, no?
I'm not advocating autoconf here, just exploring the lay of the land.
Personally, I think Parrot should do whatever makes it easiest for maintainers.
On Tuesday 07 September 2004 03:47 pm, Nicholas Clark wrote:
> On Tue, Sep 07, 2004 at 10:52:01AM -0400, Aaron Sherman wrote: > > Seriously, I've never come across any system that lacked autoconf > > support AND which a high level language like those that would target > > Parrot, ran on. If you're referring to the number of systems that have
> autoconf supports Win32?
Those win32 systems with a shell, C compiler, and the other various UNIX trappings that autoconf requires, yes ;)
