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. _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
