Re: Modules, units and compilation order
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 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 > >
Re: Modules, units and compilation order
> 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 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
Re: Modules, units and compilation order
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
