2008/6/22 jerry gay <[EMAIL PROTECTED]>: > On Sun, Jun 22, 2008 at 3:38 AM, Bernhard Schmalhofer > <[EMAIL PROTECTED]> wrote: >> James Keenan via RT schrieb: >>> >>> On Fri Jul 13 09:58:33 2007, bernhard wrote: >>> >>>> >>>> There are several config probes that are only used for language >>>> implementations. >>>> Examples are config/auto/m4.pm and config/auto/python.pm. >>>> >>>> >>> >>> Please find attached two files. The first greps the repository for >>> mentions of 'm4'. The second is a patch which eliminates >>> config/auto/m4.pm and the associated test file and updates the MANIFEST. >>> >>> Configure.pl, make and make test all perform without error after this >>> config step is eliminated. When I switch into languages/m4, then call >>> 'make' and 'make test', I get the same test failures in >>> t/regex/002_tokens.t either way. So my belief is that removing this >>> step causes no harm to the m4 language implementation itself. >>> >>> I will apply this patch to trunk in about 2 days if there is no objection. >>> >>> Thank you very much. >>> >>> kid51 >>> >>> >> >> AFAIK 'languages/m4/config/makefiles/root.in' is the only place where the >> config entry 'has_gnu_m4' is used. >> It is meant as a doublecheck of the 'm4' tests. If 'GNU m4' is available >> then the m4 tests should be run with 'GNU m4' as well. >> This should make sure that the Parrot implementation behaves the same way as >> the reference implementation. >> >> So 'has_gnu_m4' is not essential to the implementation of 'Parrot m4'. In >> r28633 I removed the use of 'has_gnu_m4' and the config step auto::m4.pm can >> now be removed. >> >> But the real scope of ticket RT#43857 is something different. Language >> implementations may need config probes that >> are only relevant for that particular language. Therefore there should be >> some kind of infrastructure set up, >> so that those probes can be placed within the language dir. Taking >> 'Plumhead' as an example, >> I would have liked to set up probes checking for 'phc', 'antlr' and >> 'xsltproc'. I didn't do so because I didn't want to clutter the Parrot >> config. >> > languages/dotnet/ has its own configure.pl, and m4, plumhead, etc. > should follow that model. if there are things that can be done to make > the process of developing a language-specific configure engine easier, > i'd love to hear them.
I outlined a Parrot/Install core library for library/languages support in the latest pdd30_install draft. For me a language is nothing more than a parrot library. The languages soon need their own Configure/Makefile support, when core throws them out. It could be driven with a perl5 lib/Parrot/Install.pm library for now, and later with runtime/parrot/library/Parrot/Install.pir or a perl6 library, which should do something along the lines of ExtUtils::MakeMaker. Frontend: parrot Makefile.pir loads Parrot/Install and defines the Makefile methods and properties, with the possibility to start a seperate configure step to check for external bins, libs and headers. RunConfigure() WriteMakefile() Defining the hash entries for the subs in PIR syntax is awful. So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax. For p6 we must ensure that every parrot package has a perl6 also then. Not good. So pl, pir or the simple nqp. -- Reini
