François Perrad wrote:
Allison, Reini,
Before applying to existing languages, could you review my work on
tools/dev/mk_languages_shell.pl (r36888-36892) ?
Is it compliant with what we want (pdd30_install) ?
$ perl tools/dev/mk_languages_shell.pl Xyz
$ make -C languages/xyz
$ make -C languages/xyz test
$ make -C languages/xyz install
One general comment is that most languages (maybe all languages soon)
will be building from an installed Parrot, not from inside a languages/
directory in the Parrot build tree. So, either we need two scripts for
making a language shell (one for languages in the build tree and one for
those outside), or we need to assume that most newbie language
developers will be outside the build tree, and make that the default
case. That would imply removing all references to $(BUILD_DIR) from the
shell makefiles.
Also, it's good to show the default way of building a grammar, an
actions file, and builtins. We shouldn't dictate that every language has
MAINTAINER and STATUS files, or a doc directory using Pod format. I
wouldn't even generate information for dynamic pmcs and ops by default
(though we could have options for mk_languages_shell.pl that add stubs
for dynamic pmcs and ops if requested).
I've some remarks :
1) the logic that creates path with version, is duplicate :
- install_files.pl lines 145-147
- install_dev_files lines 91-93
- mk_languages_shell.pl lines 191-193
The right place seems to be in config/init/install.pm
This logic is in config/init/install.pm, and install_files.pl and
install_dev_files.pl need to be updated to use it (I'll do that now).
So, instead of manually constructing the version directory, just append
"@versiondir@" (which will be empty for an install that isn't using
versioned directories). You can see an example in my Rakudo patch:
http://rt.perl.org/rt3//Public/Bug/Display.html?id=63360
2) pbc_to_exe --install adds a prefix installable_, but for languages
we need parrot- as prefix.
The prefix installable_ is fine for parrot, pbc_dump, all that comes
from C, but not from pbc.
I don't understand the problem here.
3) for languages with PMC or Ops, I wait for dynpmc.pl & dynoplibs.pl
deprecation.
Yes, those scripts are going away, to be replaced with makefiles So,
it's better to have mk_languages_shell.pl create sample makefiles (when
the appropriate options are turned on).
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
