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.
~jerry
