Hi, 2 options with compiled modules. 1) Dynamic linking (with *csc -s -J mod.scm*), so in other(main) file* (import mod) * or *(import (mod))* in C6.
2) Static linkage of the program with modules in object files. In such way we prepare object files with *csc -c -static -J -o mod.o -unit mod mod.scm* ... and main exec (args exactly in this order!) with *csc -static mod.o -uses mod ... main.scm* вт, 17 февр. 2026 г. в 13:22, Alexey Egorov via Chicken-users < [email protected]>: > > It does, because if it re-exports an existing identifier from another > > module, it resolves to a different name than if it was defined by the > > module itself. Also, if you use some macro from another module, it > > may expand to a definition which you can then export. If the macro > > isn't resolved, it can't know what identifiers will be exported and > > where they were defined! > > Ah! I see now, thank you. > > > You could also split out common stuff into its own module, compile that > > first and import it in the modules that rely on it. > > Yes, I'll probably will do exactly this. > Thank you! > > On Tue, Feb 17, 2026 at 1:12 PM Peter Bex <[email protected]> wrote: > > > > On Tue, Feb 17, 2026 at 12:49:46PM +0300, Alexey Egorov via > Chicken-users wrote: > > > I currently have 8 files, each of them declares itself unit, and then > > > I compile all of them with -c and -e flags (except for main.scm), then > > > link them all. Works fine. Order of compilation doesn't matter. > > > > Unit declaration should not be necessary once you start defining > > modules (it is implicit). > > > > > With modules, order of compilation starts to matter. E.g. if I want to > > > compile my macros.scm, which imports utils.scm, I cannot do it, if I > > > haven't generated utils.import.scm yet. > > > > > > So, I discovered -J option of the csc and tried to employ it to > > > generate all imports beforehand, > > > > That's the correct way to get this to work. You need to compile a > > module which is used by another module first so that the exported > > identifiers are known and emitted to an import file. > > > > > but even with -A (-analyze-only, stop > > > compilation after first analysis pass) I can't get to generate module > > > import file if it has unresolved dependencies. > > > > > > Am I missing something? Intuitively, it seems that -J doesn't need to > > > resolve all imports to be able to generate import file. It only > > > consists of symbols, after all. > > > > It does, because if it re-exports an existing identifier from another > > module, it resolves to a different name than if it was defined by the > > module itself. Also, if you use some macro from another module, it > > may expand to a definition which you can then export. If the macro > > isn't resolved, it can't know what identifiers will be exported and > > where they were defined! > > > > > So, is it currently possible to have modules in their own units > > > compiled in arbitrary order? If not, can the -J option be able to > > > generate import files without actually resolving all dependencies? > > > > As explained above, this makes no sense. If you have cyclic > > dependencies, that's also a problem because the system can't know which > > toplevel to evaluate first. > > > > As a workaround, what you could do if you have too much of a tangled > > mess of definitions, you can just define some identifiers in one module > > and set! them to their final value in another module. > > You could also split out common stuff into its own module, compile that > > first and import it in the modules that rely on it. > > > > Cheers, > > Peter > >
