On Thu, Aug 25, 2005 at 15:42:28 +0200, Ingo Blechschmidt wrote: > This section will contain all information needed: > * User-defined operators > * Other symbols exported by "is export" > * Exported macros
Okay, this raises a distinction:
Compile time exports
Runtime exports
Modules can affect both the compilation of code that links against
them by doing compile time exports like macros, infix subs, and so
forth, and change the runtime by exporting functions and what not.
When code is being compiled all the submodules are compiled, and the
compile time exports are read from the linkable unit by the
compiler, which determines which of these to use.
This is used to affect compilation.
The linkable units are cached.
Any amount of time passes, and then the compiled code is run,
triggerring linkage, which triggers compilation of modules.
Since this compilation found the cached files, they are linked, and
everyone is happy.
There is one problem:
If I compile foo.pl, which uses SomeModule, and SomeModule exports
stuff at compile time, and foo.pl's object code is saved, what
happens when SomeModule is upgraded?
We can no longer link against it because potentially foo.pl's
compilation depends on a certain state.
The solution to this is to give the user some options:
try to link the runtime symbols anyway, the user expects it to
work
try to recompile foo.pl if it's source code is available
when compiling foo.pl, prelink SomeModule's runtime symbols into
it, to ensure that no other version of SomeModule can affect
foo.pl's emitted code. This can be a recursive or non recursive
process.
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me kicks %s on the nose: neeyah!!!!!!!!!!!!!!!!!
pgpimQEqniC8l.pgp
Description: PGP signature
