Repository navigation
Chipmunk CLI is attempting to compile or import all source files within directory #41
Description
Activity
This is an awkward case for Chipmunk to handle - it was designed to be compiled and then run, not run directly from source. The CLI attempts to allow running from source by compiling any sources it finds and then running from the compiled binaries. The issue is that Chipmunk source files have no direct correlation to the modules they define - any file can have one or more modules, and there is never a relationship between the file name and the modules it defines. This flexibility is powerful for source organization and for embedded usage, but it has the drawback that Chipmunk doesn't know which file defines a module until it has compiled all of them. Once compiled, modules go into binary (.chpb) files that correspond 1-1 with the modules they contain.
The CLI defines the source directories flag to attempt to bridge the gap between manual compilation of all sources and running from binary - it scans all source directories that the user defines, searching for sources, compiling them, and making available any modules the main program needs in memory. I don't see a great way around this, except possibly for supporting a CLI-only convention of one-module-per-file to allow the CLI to load only dependent modules.
One possibility that could offer an improvement in this area would be support for importing a specified source file. EG: things like
import SomeFile.chporfrom SomeFile.chp import SomeThing. By allowing the scripter to import specific files, that could allow modules to span across multiple files without having to compile everything in the directory, with the caveat that the scripter is now responsible for making sure that all of the required files are included.Another possible improvement is that if compilation fails for a specific source file, the compiler will issue an error, but skip that file and continue compiling other files, on the condition that the failed file does not include any detected modules that are being used/imported by other source files.
One possibility that could offer an improvement in this area would be support for importing a specified source file.
I'm reluctant to do this, as I consider decoupling source files and modules to be a primary feature of the module system, especially for embedded use where "files" may not exist as such.
Another possible improvement is that if compilation fails for a specific source file, the compiler will issue an error, but skip that file and continue compiling other files, on the condition that the failed file does not include any detected modules that are being used/imported by other source files.
I think something along these lines holds the most promise - it can report a warning but continue on. Another option is to support a different flag that specifies individual source files instead of directories.
After taking some time to think this over, I believe the best approach for now is to issue a warning for modules that couldn't be compiled and continue on - if a module is needed by a script, the run will fail later when the VM tries to load the module that failed compilation.
Attempting to run the chipmunk cli on a single script, it threw a compiler error for an unrelated script within the same directory. It seems that the CLI is attempting to either import or compile all scripts within the same directory, rather than what is being explicitly imported by the script I'm trying to run (which, in this case, is just stuff from chipmunk.system and chipmunk.math)