Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
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
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
James Keenan via RT schrieb: I'm trying to see if we can move this ticket toward resolution. I think that it has remained unresolved for so long because the original post originally called for two steps: (a) removal from Configure.pl of configuration steps which probed for features only used in specific language implementations; (b) development of a way to conduct such language-specific probes in the language directory trees after 'perl Configure.pl' and 'make' have been run. There were two specific steps cited for removal per (a): auto::python and auto::m4. By June of this year I had removed both of those from Parrot configuration. So that leaves us with (b). particle wrote: languages/dotnet/ has its own configure.pl, and m4, plumhead, etc. should follow that model. Barney responded: One thing that held me back from using something like 'dotnet/Configure.pl' was that 'dotnet/Configure.pl' currently needs to be explicitly called after the main 'Configure.pl' has run. This is bad for universal languages testing. And that's where discussion left off three months ago. I am recommending the following: (1) Mark this ticket resolved. (2) Conduct discussion on list or IRC as to the best architecture/model for language-specific probes. (3) Once we've come to such resolution on (2), open a new RT to implement what we've decided. particle, Barney: Any objections? Sounds good. An example for a language specific config probe could be put mk_language_shell.pl. Regards, Bernhard Thank you very much. kid51
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
Reini Urban via RT schrieb: 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. The libs and scripts could be written in Perl 6 and compiled to bytecode. In this way the languages would need no full Perl 6, just some *.pbc files. Regards, Bernhard
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
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. The libs and scripts could be written in Perl 6 and compiled to bytecode. In this way the languages would need no full Perl 6, just some *.pbc files. That can open a can of worms. The .pbc generated from perl6 will need installed perl6 .pbc files for perl6 objects, builtins, who knows what more. Worse, it can use eval'ed strings that needs the compiler. It will not be nice to talk about language neutrality while requiring perl6 to install a completely unrelated language. -- Salu2
[perl #43857] [TODO] Refactor config probes that are used only by language implementation
On Fri Sep 12 02:18:57 2008, bernhard wrote: James Keenan via RT schrieb: I'm trying to see if we can move this ticket toward resolution. And that's where discussion left off three months ago. I am recommending the following: (1) Mark this ticket resolved. (2) Conduct discussion on list or IRC as to the best architecture/model for language-specific probes. (3) Once we've come to such resolution on (2), open a new RT to implement what we've decided. particle, Barney: Any objections? Sounds good. Per feedback from particle and Barney, I am resolving this ticket. Per above recommendations: Reini, Notfound, et.al.: Can you please do a new post to the list to discuss new issues or implementation ideas? We should not have further posts to this RT. Thank you very much. kid51
[perl #43857] [TODO] Refactor config probes that are used only by language implementation
Resolved.
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
On Fri, Sep 12, 2008 at 03:47:27PM +0200, NotFound wrote: 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. The libs and scripts could be written in Perl 6 and compiled to bytecode. In this way the languages would need no full Perl 6, just some *.pbc files. That can open a can of worms. The .pbc generated from perl6 will need installed perl6 .pbc files for perl6 objects, builtins, who knows what more. Worse, it can use eval'ed strings that needs the compiler. It will not be nice to talk about language neutrality while requiring perl6 to install a completely unrelated language. Agreed. This is exactly the niche that NQP is meant to fill. If we need to add some features to NQP to make this possible, then that can be done. Pm
[perl #43857] [TODO] Refactor config probes that are used only by language implementation
I'm trying to see if we can move this ticket toward resolution. I think that it has remained unresolved for so long because the original post originally called for two steps: (a) removal from Configure.pl of configuration steps which probed for features only used in specific language implementations; (b) development of a way to conduct such language-specific probes in the language directory trees after 'perl Configure.pl' and 'make' have been run. There were two specific steps cited for removal per (a): auto::python and auto::m4. By June of this year I had removed both of those from Parrot configuration. So that leaves us with (b). particle wrote: languages/dotnet/ has its own configure.pl, and m4, plumhead, etc. should follow that model. Barney responded: One thing that held me back from using something like 'dotnet/Configure.pl' was that 'dotnet/Configure.pl' currently needs to be explicitly called after the main 'Configure.pl' has run. This is bad for universal languages testing. And that's where discussion left off three months ago. I am recommending the following: (1) Mark this ticket resolved. (2) Conduct discussion on list or IRC as to the best architecture/model for language-specific probes. (3) Once we've come to such resolution on (2), open a new RT to implement what we've decided. particle, Barney: Any objections? Thank you very much. kid51
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
On Thu, Sep 11, 2008 at 4:47 PM, James Keenan via RT [EMAIL PROTECTED] wrote: I'm trying to see if we can move this ticket toward resolution. I think that it has remained unresolved for so long because the original post originally called for two steps: (a) removal from Configure.pl of configuration steps which probed for features only used in specific language implementations; (b) development of a way to conduct such language-specific probes in the language directory trees after 'perl Configure.pl' and 'make' have been run. There were two specific steps cited for removal per (a): auto::python and auto::m4. By June of this year I had removed both of those from Parrot configuration. So that leaves us with (b). particle wrote: languages/dotnet/ has its own configure.pl, and m4, plumhead, etc. should follow that model. Barney responded: One thing that held me back from using something like 'dotnet/Configure.pl' was that 'dotnet/Configure.pl' currently needs to be explicitly called after the main 'Configure.pl' has run. This is bad for universal languages testing. And that's where discussion left off three months ago. I am recommending the following: (1) Mark this ticket resolved. (2) Conduct discussion on list or IRC as to the best architecture/model for language-specific probes. (3) Once we've come to such resolution on (2), open a new RT to implement what we've decided. particle, Barney: Any objections? 's fine with me. ~jerry
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
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. Regards, Bernhard
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
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
[perl #43857] [TODO] Refactor config probes that are used only by language implementation
On Sun Jun 22 03:39:37 2008, bernhard wrote: 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. Done. Patch applied in r28656 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. So the ticket remains open.
[perl #43857] [TODO] Refactor config probes that are used only by language implementation
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. In order to improve the seperation of concerns, these probes should be moved to a separate directory. The Python part of this ticket was completed in r53600. kid51
[perl #43857] [TODO] Refactor config probes that are used only by language implementation
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #43857] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43857 There are several config probes that are only used for language implementations. Examples are config/auto/m4.pm and config/auto/python.pm. In order to improve the seperation of concerns, these probes should be moved to a separate directory. 'languages' specific configuration should become a seperate step. This helps in making the language implementations self-contained. Anybody with Perl 5 knowlege can work on that.
