pdd30_install.pod (was Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod)
Reini Urban wrote: I have one more draft. chromatic told me write up such a thing, but it's not finished yet. It could go to the cygwin070patches branch which is really a parrot_install branch, but also to HEAD. This needs some technical review because but I'm still a beginner in what is possible and what not. Thanks, applied to trunk in r30616. I gave it a quick read-through, but haven't edited it yet. (Have added it to my Hiveminder todo list.) All input from other parroteers welcome. Allison
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Reini Urban wrote: +=head1 DESCRIPTION + +Parrot installation mechanisms are more powerful than perl5's. +MANIFEST contains also the end location, tools/dev/install_files.pl is driven +by this definition. To me it's not clear what the end location is - care to elaborate? Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
2008/8/28 Moritz Lenz [EMAIL PROTECTED]: +=head1 DESCRIPTION + +Parrot installation mechanisms are more powerful than perl5's. +MANIFEST contains also the end location, tools/dev/install_files.pl is driven +by this definition. To me it's not clear what the end location is - care to elaborate? The end location by make install is a string concatation of * the $(DESTDIR) as defined per Makefile argument, * plus the respective Configure defined directoy (prefix,bin_dir, lib_dir, include_dir, mandir, doc_dir, ...) where the directores are defined by default to follow the FHS convention and optional Configure.pl arguments, and the files as defined in one of the three MANIFEST files in the format filename \t [package]lib,doc,include,bin - files from the [library] package go to prefix/lib_dir and either dynext, library or include, * plus the filename as defined by the three MANIFEST files. There's additional logic in the tools/dev/install_files.pl script. prefix defaults to /usr/local and packages define them as /usr lib_dir defaults to prefix + /lib and libraries go to parrot/dynext for shared libs (flat) parrot/library for pbc files (structured according to the namespace) parrot/include for pir and pasm files (flat) bin_dir to prefix + /bin doc_dir to prefix + /share/doc/parrot mandir to prefix + /man, but it should be prefix + /share/man according to the FHS include_dir to prefix + /include/parrot pkgconfig_dir to prefix + /lib/pkgconfig What is missing is the end location of language pbc's and installable exe's. The convention by fedora and cygwin for parrot-language installables is $(DESTDIR)@bin_dir@/parrot-$(LANG)@exe@ Open problem: For language pbc's a new dir like script_dir or lib_dir/parrot/bin would be required. They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other pbc's are. The language group and op shared libs go to $(DESTDIR)@lib_dir@/parrot/dynext for sure. e.g. tclsh.pbc, APL.pbc, ... -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Reini Urban wrote: 2008/8/28 Moritz Lenz [EMAIL PROTECTED]: +=head1 DESCRIPTION + +Parrot installation mechanisms are more powerful than perl5's. +MANIFEST contains also the end location, tools/dev/install_files.pl is driven +by this definition. To me it's not clear what the end location is - care to elaborate? The end location by make install is a string concatation of [...] so it's basically the individual, final destination path for that file? Thanks for the explanation. My point is (and I admit that I wasn't very clear about it) that IMHO the term end location is ambigous (unless it's some kind of technical term with which I'm not familiar), and thus should be changed in the pdd. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
2008/8/28 Moritz Lenz [EMAIL PROTECTED]: Reini Urban wrote: 2008/8/28 Moritz Lenz [EMAIL PROTECTED]: +=head1 DESCRIPTION + +Parrot installation mechanisms are more powerful than perl5's. +MANIFEST contains also the end location, tools/dev/install_files.pl is driven +by this definition. To me it's not clear what the end location is - care to elaborate? The end location by make install is a string concatation of [...] so it's basically the individual, final destination path for that file? final destination path is of course much better. Someone might be tempted to look for the PC game or the movie. Thanks for the explanation. My point is (and I admit that I wasn't very clear about it) that IMHO the term end location is ambigous (unless it's some kind of technical term with which I'm not familiar), and thus should be changed in the pdd. My draft is very rough, and needs some more days. I've also put into the parrot wiki, so that you can easily can change things. I'll pick it up then. http://www.perlfoundation.org/parrot/index.cgi?parrot_installation -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote:
Open problem:
For language pbc's a new dir like script_dir or lib_dir/parrot/bin
would be required.
They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
pbc's are.
The language group and op shared libs go to $(DESTDIR)@lib_dir@/parrot/dynext
for sure.
e.g. tclsh.pbc, APL.pbc, ...
I'd be a bit surprised if the .pbc files went into dynext/ -- that doesn't
seem to match what currently exists there (which is all .so files on
my system).
At the moment I'm planning for language pbcs to go into
.../parrot/library/ so they can be easily accessed via
load_bytecode. I've found that in a dynamic environment like
Parrot there's very little difference between a language and
a library [1]. :-)
Also, I wonder if any of this relates to RT #47992 ('parrot foo'
automatically finds and invokes foo.pbc)?
Pm
[1] CPAN is my programming language of choice; the rest is just syntax.
--Audrey Tang
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
2008/8/28 Patrick R. Michaud [EMAIL PROTECTED]:
On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote:
Open problem:
For language pbc's a new dir like script_dir or lib_dir/parrot/bin
would be required.
They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
pbc's are.
The language group and op shared libs go to $(DESTDIR)@lib_dir@/parrot/dynext
for sure.
e.g. tclsh.pbc, APL.pbc, ...
I'd be a bit surprised if the .pbc files went into dynext/ -- that doesn't
seem to match what currently exists there (which is all .so files on
my system).
Sure.
My comment about the tclsh.pbc, APL.pbc, ... was referring to the
language pbc's, not to the group and op shared libs.
At the moment I'm planning for language pbcs to go into
.../parrot/library/ so they can be easily accessed via
load_bytecode. I've found that in a dynamic environment like
Parrot there's very little difference between a language and
a library [1]. :-)
That's probably the best, but we can also think of not installing that at all,
and only install executables. But then the new pddxx_language_interop.pod
at http://nopaste.snit.ch/13890 will have problems. exe cannot loaded
from other languages, only pbc's.
So each language will need its root namespace reserved for it's lang.pbc.
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Also, I wonder if any of this relates to RT #47992 ('parrot foo'
automatically finds and invokes foo.pbc)?
If foo.pbc is in parrot/library/foo.pbc then it will be found.
The pbc library searchpath is only . and @lib_dir@/parrot/library.
Also PARROT_RUNTIME can be defined in ENV to override
the runtime prefix and therefore the library search path..
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] wrote:
2008/8/28 Patrick R. Michaud [EMAIL PROTECTED]:
On Thu, Aug 28, 2008 at 02:10:27PM +0200, Reini Urban wrote:
Open problem:
For language pbc's a new dir like script_dir or lib_dir/parrot/bin
would be required.
They could also pollute $(DESTDIR)@lib_dir@/parrot/library where the other
pbc's are.
The language group and op shared libs go to
$(DESTDIR)@lib_dir@/parrot/dynext
for sure.
e.g. tclsh.pbc, APL.pbc, ...
I'd be a bit surprised if the .pbc files went into dynext/ -- that doesn't
seem to match what currently exists there (which is all .so files on
my system).
Sure.
My comment about the tclsh.pbc, APL.pbc, ... was referring to the
language pbc's, not to the group and op shared libs.
At the moment I'm planning for language pbcs to go into
.../parrot/library/ so they can be easily accessed via
load_bytecode. I've found that in a dynamic environment like
Parrot there's very little difference between a language and
a library [1]. :-)
That's probably the best, but we can also think of not installing that at all,
and only install executables. But then the new pddxx_language_interop.pod
at http://nopaste.snit.ch/13890 will have problems. exe cannot loaded
from other languages, only pbc's.
Right. We have to (eventually) install the pbcs, no matter if we also
install the exes for convenience.
So each language will need its root namespace reserved for it's lang.pbc.
While it would help, there's no guarantee that namespace in PBC
matches path on filesystem.
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
Also, I wonder if any of this relates to RT #47992 ('parrot foo'
automatically finds and invokes foo.pbc)?
If foo.pbc is in parrot/library/foo.pbc then it will be found.
The pbc library searchpath is only . and @lib_dir@/parrot/library.
Also PARROT_RUNTIME can be defined in ENV to override
the runtime prefix and therefore the library search path..
I had always thought that the compiler/compreg opcode would eventually
be extended to load the library we needed for language interop; If
not, I'm not sure there's much point in keeping the ability to
register compilers, is there? If someone wants to use the tcl
compiler, they need to know to load the bytecode first anyway.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Will Coke Coleda
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] wrote:
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
True, there's no perl -MExtUtils::Command -e ln_s
But we have LN_S = @lns@
Also, I wonder if any of this relates to RT #47992 ('parrot foo'
automatically finds and invokes foo.pbc)?
If foo.pbc is in parrot/library/foo.pbc then it will be found.
The pbc library searchpath is only . and @lib_dir@/parrot/library.
Also PARROT_RUNTIME can be defined in ENV to override
the runtime prefix and therefore the library search path..
I had always thought that the compiler/compreg opcode would eventually
be extended to load the library we needed for language interop; If
not, I'm not sure there's much point in keeping the ability to
register compilers, is there? If someone wants to use the tcl
compiler, they need to know to load the bytecode first anyway.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
On Thu, 28 Aug 2008, Reini Urban wrote:
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] wrote:
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
True, there's no perl -MExtUtils::Command -e ln_s
But we have LN_S = @lns@
But that's not necessarily a symbolic link. It was originally intended
only for use with files, not directories. If symlinks aren't available on
Unix, it falls back to a plain 'ln'. On Win32 versions of perl, lns is
usually defined as 'copy'.
So the short answer is that, at the moment, without additional
Configure.pl work, you can't assume $Config{lns} can be used to make
symbolic links for directories.
--
Andy Dougherty [EMAIL PROTECTED]
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Andy Dougherty schrieb:
On Thu, 28 Aug 2008, Reini Urban wrote:
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] wrote:
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
True, there's no perl -MExtUtils::Command -e ln_s
But we have LN_S = @lns@
But that's not necessarily a symbolic link. It was originally intended
only for use with files, not directories. If symlinks aren't available on
Unix, it falls back to a plain 'ln'. On Win32 versions of perl, lns is
usually defined as 'copy'.
So the short answer is that, at the moment, without additional
Configure.pl work, you can't assume $Config{lns} can be used to make
symbolic links for directories.
I only wanted to link the language pbc files from
languages/lang/lang.pbc to runtime/parrot/library/lang.pbc
And only if someone needs it for hll interop testing.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Will Coleda wrote: At the moment I'm planning for language pbcs to go into .../parrot/library/ so they can be easily accessed via load_bytecode. I've found that in a dynamic environment like Parrot there's very little difference between a language and a library [1]. :-) That's probably the best, but we can also think of not installing that at all, and only install executables. But then the new pddxx_language_interop.pod at http://nopaste.snit.ch/13890 will have problems. exe cannot loaded from other languages, only pbc's. Right. We have to (eventually) install the pbcs, no matter if we also install the exes for convenience. Yes. And the exes (or aliases to the parrot exe) should go in the same bin directory as parrot. So each language will need its root namespace reserved for it's lang.pbc. While it would help, there's no guarantee that namespace in PBC matches path on filesystem. The fundamental principle is that language implementations are like CPAN modules. You can install them as a separate package, and they add functionality. Just like a CPAN module, there's a default search path where the module name matches the filesystem path, possibly with some prefix path, and with the HLL namespace treated as part of the full name of the module (/usr/lib/parrot/lang/python/my/module.pbc or whatever). There also need be ways to change the default path when compiling Parrot, and to change the searched paths at runtime. We could thing of symlinking it to runtime/parrot/library at make languages, so language_interop can be tested. Are symlinks usable wherever we might install? No. And not necessary as long as search paths are configurable, which they have to be anyway. I had always thought that the compiler/compreg opcode would eventually be extended to load the library we needed for language interop; If not, I'm not sure there's much point in keeping the ability to register compilers, is there? If someone wants to use the tcl compiler, they need to know to load the bytecode first anyway. That's backwards. Loading the language module is what registers the compiler. The user never needs to access the compiler object for a particular language directly unless they're compiling code from a string. Allison
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
On Thu, Aug 28, 2008 at 11:10:47PM +0200, Allison Randal wrote: That's backwards. Loading the language module is what registers the compiler. The user never needs to access the compiler object for a particular language directly unless they're compiling code from a string. ...or if they want to parse a namespace string according to another HLL's rules, obtain a namespace from another HLL, or load a library associated with a different HLL. (See pdd21 - namespaces.) Pm
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Patrick R. Michaud wrote: On Thu, Aug 28, 2008 at 11:10:47PM +0200, Allison Randal wrote: That's backwards. Loading the language module is what registers the compiler. The user never needs to access the compiler object for a particular language directly unless they're compiling code from a string. ..or if they want to parse a namespace string according to another HLL's rules, obtain a namespace from another HLL, or load a library associated with a different HLL. (See pdd21 - namespaces.) I've always assumed that those behaviors would be hidden behind methods on the namespace PMC, which would delegate them to the appropriate compiler PMC. Allison
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
2008/8/25 Allison Randal [EMAIL PROTECTED]: (Another way to fix the PDD issues is to eliminate the draft directory and just mark PDDs that are still considered in DRAFT with some decorative POD; that has my vote) I'm almost done with the PDDs in the draft directory. It's very helpful to be able to look at that directory and know exactly how many PDDs are still suffering from severe bit-rot. So, yes, agreed on eliminating the docs/pdds/draft/ directory, but not until we launch the final few PDDs out of it in a comprehensible form. Uh, it will be gone... I have one more draft. chromatic told me write up such a thing, but it's not finished yet. It could go to the cygwin070patches branch which is really a parrot_install branch, but also to HEAD. This needs some technical review because but I'm still a beginner in what is possible and what not. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ Index: parrot-svn/docs/pdds/draft/pdd30_install.pod === --- /dev/null +++ parrot-svn/docs/pdds/draft/pdd30_install.pod @@ -0,0 +1,213 @@ +# Copyright (C) 2008, The Perl Foundation. +# $Id: pdd30_install.pod 30255 2008-08-23 12:15:46Z rurban $ + +=head1 NAME + +docs/pdds/draft/pdd30_install.pod - Parrot Installation + +=head1 ABSTRACT + +This PDD defines Parrot's installation details. The goal is to provide binary +packages, a working Cmake install for parrot, the installables, FHS compliant +search paths for the installables and solving the problem of not accessing +installed source-only files and the optimization of config bootstrapping +if a frozen config_hash is already linked. + +=head1 VERSION + +$Revision: 30459 $ + +=head1 SYNOPSIS + + make install + make test-installable -C language/lang + make installable -C language/lang + make install -C language/lang DESTDIR=inst + +=head1 DESCRIPTION + +Parrot installation mechanisms are more powerful than perl5's. +MANIFEST contains also the end location, tools/dev/install_files.pl is driven +by this definition. +The three runtime paths for include, library for load_bytecode and dynext +for loadlib should end up in the $prefix/lib/parrot paths. +See #56996-fhs-runtime.patch + +Contrary to perl5, parrot and its language implementions on top of parrot may +be installed as self-hosting single-file executables, with the help of merged +pbc's and pbc2exe --install. + +Bootstrapping the config hash should not read a config file when the hash is +already contained in the pmc or executable. See #57418 [TODO] optimize +_config to omit .include library/config.pir on installables. + +The same problem is for every .include, .loadlib and .load_bytecode statement +in installed files where the target is not installed. This could be solved with +a module system or with pbc_merge removing not needed .load_bytecode statements. + +Test executables are binary different to installable executables because of +this embedded config hash. Test executables contain config hash with +the prefix to the build_dir, installables to the given prefix from Configure.pl. + +There are's also a long-standing conflict in building parrot with an already +installed shared libparrot.so. See #39742-installed-conflict.patch which adds +the blib/lib path to PATH resp. LD_RUN_PATH. + +=head1 DEFINITIONS + +An Binstallable is a pbc or exe which must not access the build_dir +paths. The build_dir is not available in a binary package. This is solved by +generating and linking a special Finstall_config.fpmc. Custom python modules +have a similar packaging problem, which they haven't solved yet. + +Bbuild_dir is the full path where parrot was built. It is defined in the +config hash. When building from source build_dir is also the PARROT_RUNTIME prefix. + +BDESTDIR is the end location of the parrot tree in front of the prefix +(/usr or /usr/local). This allows packaging by installing into a seperate +install tree and do a tar cf there. + +The Bconfig hash is the return value of the global function C_config(), +generated in Fconfig_lib.pasm, and either defined in Flibrary/config.pir, or +as frozen pmc embedded in the test executable (Fconfig.fpmc), the installable +executable (Finstall_config.fpmc) or empty for miniparrot (Fnull_config.fpmc). + +=head1 IMPLEMENTATION + +=head2 make install + +The parrot build system is optimized for building and testing in the +build_dir, but not for building with an already installed parrot due to simple +build system bugs, and not optimized to build and test installables, which should +not access the libraries in the build_dir, but in the DESTDIR. + +The goal is to make install work for parrot, the utils, and all the languages. +For parrot and its utils the install actions are defined in the main Makefile, +for the languages the install actions should be defined in its Makefiles and +is implemented in #56554-make-install-lang.patch. + +Cmake install currently does not work with an already installed shared
pdd19_pir.pod: See Cdocs/imcc/macros.pod
pdd19_pir.pod references the not-existing docs/imcc/macros.pod. It would be nice if this documents shows up somewhere, as I found nothing more about macros, besides the section in pdd19_pir.pod -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
docs/imcc/macros.pod was integrated into pdd19 some time ago. That's all information available on macros, currently kjs On Mon, Aug 25, 2008 at 10:08 AM, Reini Urban [EMAIL PROTECTED] wrote: pdd19_pir.pod references the not-existing docs/imcc/macros.pod. It would be nice if this documents shows up somewhere, as I found nothing more about macros, besides the section in pdd19_pir.pod -- Reini Urban http://phpwiki.org/ http://murbreak.at/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
On Mon, Aug 25, 2008 at 11:25 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: docs/imcc/macros.pod was integrated into pdd19 some time ago. That's all information available on macros, currently kjs On Mon, Aug 25, 2008 at 10:08 AM, Reini Urban [EMAIL PROTECTED] wrote: pdd19_pir.pod references the not-existing docs/imcc/macros.pod. It would be nice if this documents shows up somewhere, as I found nothing more about macros, besides the section in pdd19_pir.pod -- Reini Urban http://phpwiki.org/ http://murbreak.at/ Removed reference to obsolete doc in r30540. -- Will Coke Coleda
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Reini Urban wrote: pdd19_pir.pod references the not-existing docs/imcc/macros.pod. It would be nice if this documents shows up somewhere, as I found nothing more about macros, besides the section in pdd19_pir.pod Actually I stumbled over quite a lot of dangling references in the docs. Including, but not limited to, references to PDDS that still live in draft/, but are references to be in docs/pdds/ directly. What should we do with all these? You can automatically check if the file exists, but youll get some false negatives. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
On Mon, Aug 25, 2008 at 1:52 PM, Moritz Lenz [EMAIL PROTECTED] wrote: Reini Urban wrote: pdd19_pir.pod references the not-existing docs/imcc/macros.pod. It would be nice if this documents shows up somewhere, as I found nothing more about macros, besides the section in pdd19_pir.pod Actually I stumbled over quite a lot of dangling references in the docs. Including, but not limited to, references to PDDS that still live in draft/, but are references to be in docs/pdds/ directly. What should we do with all these? You can automatically check if the file exists, but youll get some false negatives. Cheers, Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ Links to files should be valid: If the file isn't where we are pointing, the link should be updated (or removed, if necessary). (Another way to fix the PDD issues is to eliminate the draft directory and just mark PDDs that are still considered in DRAFT with some decorative POD; that has my vote) -- Will Coke Coleda
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
Will Coleda wrote: Moritz Lenz wrote: Reini Urban wrote: Actually I stumbled over quite a lot of dangling references in the docs. Including, but not limited to, references to PDDS that still live in draft/, but are references to be in docs/pdds/ directly. What should we do with all these? You can automatically check if the file exists, but youll get some false negatives. Links to files should be valid: If the file isn't where we are pointing, the link should be updated (or removed, if necessary). An automatic test is a very good idea. Don't run it as part of 'make test' yet, but it'll give us a good baseline for going through and fixing the broken links. We should change the links for any PDDs in draft/ to say they're in draft/. Then the test will tell me all the files that need to be updated after I move the PDD out of draft. (Another way to fix the PDD issues is to eliminate the draft directory and just mark PDDs that are still considered in DRAFT with some decorative POD; that has my vote) I'm almost done with the PDDs in the draft directory. It's very helpful to be able to look at that directory and know exactly how many PDDs are still suffering from severe bit-rot. So, yes, agreed on eliminating the docs/pdds/draft/ directory, but not until we launch the final few PDDs out of it in a comprehensible form. Allison
