Automatic dependencies

Paul Wolneykien wolneykien at altlinux.org
Mon Sep 20 22:27:32 UTC 2010


  Hi, Parrot developers.

  Trying to provide a good Parrot packages for Sisyphus repository
(http://sisyphus.ru/en/) I faced a problem of module dependency tracking.

* Background *

  When a package is built for Sisyphus its files are scanned and a set
of static relationships are calculated for each program or library file.
For each file type the corresponding scan tool is used. So I need to
provide such a tool for the Parrot *.pir/*.pasm/*.pbc modules.

* The module scan tool *

  As far as I understand the system of Parrot, a source code module of
any program in any language is finally translated into a bytecode module
(i.e. *.pbc) that is then run by the Parrot interpreter (VM). Each
bytecode module generally has three types of possible dependencies:

  a) an other bytecode module (via load_bytecode instruction);

  b) a language/dialect support module (via load_language instruction);

  c) a platform native library (via loadlib instruction).

And each bytecode module provides a set of procedures some of which can
be exported. Whereas a support for a programming language or dialect is
provided by a set of special Parrot modules (I didn't dig that field
deep yet).
  Due to bytecode (or PASM) modules have no predefined particular
structure, a dependency scan tool based on a code analysis is not a good
choice. To get the reliable information on a bytecode module
dependencies I use the following technique: the observable module is
loaded using the load_bytecode instruction and the VM trace output is
then analyzed.
  The development files of the tool you can find in
http://git.altlinux.org/people/manowar/packages/rpm-build-parrot.git GIT
repository.

* Details. Assumptions *

  That dependency tracking tool is written with the assumption that a
code that is run on a module load consists of initialization and module
loading procedures only. No interactive input, no infinite loops. That
probably is true for the most of the practical modules. But what about
code that is run on module execution, i.e. the "main" procedure?
  There is no technical means not to load some required modules during
the program execution, that's what is called "dynamic module loading".
Because the name of such dynamically loaded module can be unknown before
time, there is no need to track it as a stable dependency: only static
dependencies need to be tracked. So the scan tool counts only the
modules that are loaded on a module initialization (:init :load) and
report them as a static dependencies.

* The problem *

   Extracting a representative set of dependencies using the described
method is only possible when a high-level language compiler that
produces a code of the module translates the set of static module
requirements (i.e. the "import" section entries or "use Module::Name"
expressions) into the corresponding load instructions and places the in
the module initialization section (:init :load), not the "main" module code.

* The proposition. Questions *

  From my point of view, that policy seems logical and natural. Is it
the same for you?

  Anyway I don't like policies. Instead of that I propose to make some
modifications to the PCT in such a way that any properly defined
compiler would produce a code with all static module loading procedures
placed into the module initialization section. What do you think of that?
  Or maybe PCT already contains that kind of code?


  With best regards,

-- 
Paul Wolneykien,
  ALT Linux, Ltd.


More information about the parrot-dev mailing list