Joshua Isom ha scritto:
Using perl 5's configure probes also somewhat limits us to how the
vendor distributed perl. It should also be considered that we can't
rely on perl5 being available, especially since we intend to replace
it eventually, so rewriting all the perl to support cross compiling
would likely not be the best thing.
I don't second that. I agree that relaying on Perl5's configure is not
the way to go, but I don't see any problem in using Perl5 as _the tool_
to build. while it's true that Parrot aims at replacing it, Perl5 is
going to be there for years to come. and what alternatives are there?
Perl5's own configuration/build system is based on bash and make, and
they are far more less available than Perl5 itself. IMO, using Perl to
configure is a much more powerful, maintainable, work-everywhere
solution than some autoconf-based stuff.
If we create a new configure system, we can essentially have two
configuration methods in the trunk, and have tests for the new one to
be sure it's working and portable before trying to get everyone to
start using it.
well, I didn't intend to build a whole new configure system from
scratch. I'm afraid this would be far more expensive than the current
amount of Free Time I have to spend on the project.
I've noticed a lot that mentions miniparrot being used for building
parrot, but at the same time, we don't have anything to work with to
know just how limited miniparrot should be. Perhaps a step to work
for before rebuilding the configure subsystem(which theoretically
should be in pir to get rid of perl5 dependence), is to get an actual
miniparrot working? Currently miniparrot just seems to be a
macroparrot with a miniconfig. If we can't realistically get a
miniparrot, maybe it should be considered if building a miniparrot for
configuration is a good idea. Instead of rewriting everything now in
perl5 to support cross compiling, maybe we should dive in and try to
see if we can get it rewritten in pir. After all, we're getting more
pir programmers than perl5 programmers it seems.
woot! I am _not_ going to become a pir programmer, sorry :-)
seriously, I'm not really sure that targeting "pir programmers" is a
desiderable thing. I mean, in the long term, how many people are going
to really learn pir and use it as a programming language? Parrot
maintainers, sure, and HLL compiler authors, but how many of them there
will be, as opposed to Perl(5..6) programmers?
cheers,
Aldo
