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
