> 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
