Finding Imported Modules

[gray]

From the Astrobe docs:

The editor, compiler, linker and builder first search the current folder when trying to locate imported source code, symbol and object files. They then search each of the folders listed in the current configuration’s Library Pathnames textbox.

Consider this test set-up:

Code: Select all

+ C:\Test
  + lib
    + Main.mod
    + M0.mod
    + M1.mod
  + prog
    + M1.mod
    + P.mod

Code:

Code: Select all

MODULE P;
  IMPORT Main, M0;
END P.

MODULE Main;
END Main.

MODULE M0;
  IMPORT M1;
END M0.

MODULE M1;
  (* same in 'lib' and 'prog' *)
END M1.

Library search path:

Code: Select all

C:\Test\lib

Buidling with all directories "clean" of any symbol and object files:

Code: Select all

Astrobe for RP2350 Builder v10.0.1
Builder Phase 1: Checking P.mod and imported modules...

Checking Module Main
  Imports:
  Folder: C:\Test\lib
  Status: Missing Main.arm file
Checking Module M1
  Imports:
  Folder: C:\Test\prog
  Status: Missing M1.arm file
Checking Module M0
  Imports:
    M1
  Folder: C:\Test\lib
  Status: Missing M0.arm file
Checking Module P
  Imports:
    Main
    M0
  Folder: C:\Test\prog
  Status: Missing P.arm file
------------------

Builder Phase 2: Compiling missing / outdated modules...

  compiling C:\Test\lib\Main.mod
new symbol file;  code generated = 8 bytes, data = 0 bytes, entries = 0, lines = 2, msecs = 11
------------------
  compiling C:\Test\prog\M1.mod
new symbol file;  code generated = 8 bytes, data = 0 bytes, entries = 0, lines = 2, msecs = 1
------------------
  compiling C:\Test\lib\M0.mod

  Line  Col
     2   13 Error: import not available
------------------
2 modules compiled, lines = 6, msecs = 13

That is, a compiled M1.mod in the same directory as M0.mod is not found, unsurprisingly, as M1.mod in 'prog' was compiled, not the one in 'lib', and the search path does not lead to 'prog'.

Running with this search path, again with clean directories:

Code: Select all

C:\Test\prog
C:\Test\lib

results in sucessful compilation and linking (only linker output shown):

Code: Select all

Astrobe for RP2350 Linker v10.0.1
module Main  6E69614DH
filename C:\Test\lib\Main.arm
module P  00000000H
filename C:\Test\prog\P.arm
  importing M0  0300304DH     0     0
module M0  0300304DH
filename C:\Test\lib\M0.arm
  importing M1  0300314DH     0     0
module M1  0300314DH
filename C:\Test\prog\M1.arm
  linking Main                 8 bytes
  linking M1                   8 bytes
  linking M0                   8 bytes
  linking P                    8 bytes

Unless I miss something here, this does not conform the documentation: in both cases, M1.mod in 'lib' should have been picked, since the imported module in the same directory as the importer should take precedence.

Now, I would prefer if the observed behaviour were the intended one, as it allows to easily replace library modules with custom ones. Please clarify, thanks.

[cfbsoftware]

The 'current folder' is the folder which contains the source code of the target of the operation . When linking and building the target is the module which imports Main. When compiling a module, the 'current folder' is the folder which contains the source code of the module being compiled.

The system is designed so that all of the files created when you compile a module (*.smb, *.arm etc.) are located in the same folder as the source code of that module. Similarly, all of the files that are created when you link a main module (*.bin, *.uf2 etc.) are located in the same folder as the source code of that module. However, the system allows you to reference files in other folders in a hierarchical fashion.

A constraint of the system is that it is an error if you attempt to link a module which references two or more different versions of a module with the same name. Hence, it is unwise to design a system which has two modules with the same name in the same hierarchy as in your example. For example, the following code results in the error: 'Module M1 - wrong version':

-----------------------------------------
Test Folder:
MODULE P;
IMPORT Main, M0, M1;
VAR
p: INTEGER;
BEGIN
p := M1.prog
END P.
-----------------------------------------
Lib Folder:
MODULE Main;
END Main.

MODULE M0;
IMPORT M1;
END M0.

MODULE M1;
VAR
lib*: INTEGER;
(* Lib Version *)
END M1.
----------------------------------------
Prog Folder:
MODULE M1;
VAR prog*: INTEGER;
(* Prog version *)
END M1.[/code]
-----------------------------------------

[gray]

For example, the following code results in the error: 'Module M1 - wrong version':

Well, that depends. Compiling and linking your example code works fine, if I

1) start with clean directories;
2) compile and link from the "top", ie. P.mod.
3) repeatedly recompile and link from P.mod, ie. without clean directories, as during development.

No wrong version issues. M0.mod compiles with reference to M1.mod in 'prog', and the compilation results are in the same directory as the source. M1.mod in 'lib' does not get compiled.

It's only when I compile M1.mod in 'lib', and then compile M0.mod "locally", ie. with 'lib' as "current folder", I will run into the wrong version issue when attempting to build again from P.mod, since M0.mod is now compiled "against" M1.mod in 'lib', due to the "current folder" rule.

The problem I want to solve is to replace specific library modules, such as provided by Astrobe or Oberon RTK, with program/project-specific custom ones. Since in this case I never need to compile not replaced modules in the libray locally, this would work as is, but it's brittle, in particular if the library is used by different programs. I'll think of something. :) Probably based on program-local sub-sets of the library (actually used, sans the custom ones), supported by a tool for update and maintenance. Segregating library modules into "can be customised" directories in the library structure is not an option in general.