No-C, no programming project: Some configure investigation
Dan Sugalski
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
Aaron Sherman
> 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
Aaron Sherman
> 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} : '',
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
> 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.
Robert Schwebel
> 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
Robert Schwebel
> 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?
Jens Rieks
> Would autoconf/automake be an option for the C part of parrot?
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).
jens
Robert Schwebel
> 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.
Aaron Sherman
> 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....
Andrew Dougherty
> 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.
--
Andy Dougherty doug...@lafayette.edu
Robert Schwebel
> 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.
Nicholas Clark
> 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?
Nicholas Clark
Aaron Sherman
> 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.
Andrew Rodland
Those win32 systems with a shell, C compiler, and the other various UNIX
trappings that autoconf requires, yes ;)
Andrew