intermediate binary trash
While changing a package name, for instance, the compiler is run several times and produces a number of files. These files, however, are intermediate garbage since the package name changed after all.
More severely, the old garbage files may lead to successful module imports.Submitted by Sebastian Erdweg on 13 April 2011 at 11:51
I see two implementation options here:
- We could support an explicit clean operation which would delete all compilation results.
- We could track which source file was used to create a compilation result, and delete the compilation result when that source file is changed.
IIUC, Eclipse for Java implements solution (1).
Our situation is different from Java, though: In Java, parsing and building are different, and only building produces files which can become outdated. In SugarJ, parsing and building are the same (or aren’t they?), and we therefore produce compilation results much more often.
Implemented (2) from second post.
For each input file “abc/xyz.sugj” a file “bin/abc/xyz.gen” is generated, which lists the file names of all generated files. On recompilation, the listed files are deleted.
Log in to post comments