This adds no new functionality or overhead to the compiler, yet. This is the preliminary work that has:
added code to the compiler in several spots to flag when something is used without being properly required/imported/whatever (disabled by default)
that was used to generate project wide file dependencies (some circulars were manually fixed)
then that graph underwent a transitive reduction and the result was written to all jak1 source files.
The next step will be making this actually produce and use a dependency graph. Some of the reasons why I'm working on this:
eliminates more game.gp boilerplate. This includes the .gd files to some extent (*-ag files and tpage files will still need to be handled) this is the point of the new bundles form. This should make it even easier to add a new file into the source tree.
a build order that is actually informed from something real and compiler warnings that tell you when you are using something that won't be available at build time.
narrows the search space for doing LSP actions -- like searching for references. Since it would be way too much work to store in the compiler every location where every symbol/function/etc is used, I have to do ad-hoc searches. By having a dependency graph i can significantly reduce that search space.
opens the doors for common shared code with a legitimate pattern. Right now jak 2 shares code from the jak 1 folder. This is basically a hack -- but by having an explicit require syntax, it would be possible to reference arbitrary file paths, such as a common folder.
Some stats:
Jak 1 has about 2500 edges between files, including transitives
With transitives reduced at the source code level, each file seems to have a modest amount of explicit requirements.
Known issues:
Tracking the location for where defmacros and virtual state definitions were defined (and therefore the file) is still problematic. Because those forms are in a macro environment, the reader does not track them. I'm wondering if a workaround could be to search the reader's text_db by not just the goos::Object but by the text position. But for the purposes of finishing this work, I just statically analyzed and searched the code with throwaway python code.
Relates to #1353
This adds no new functionality or overhead to the compiler, yet. This is the preliminary work that has:
jak1source files.The next step will be making this actually produce and use a dependency graph. Some of the reasons why I'm working on this:
game.gpboilerplate. This includes the.gdfiles to some extent (*-agfiles andtpagefiles will still need to be handled) this is the point of the newbundlesform. This should make it even easier to add a new file into the source tree.commonfolder.Some stats:
Known issues:
defmacros and virtual state definitions were defined (and therefore the file) is still problematic. Because those forms are in a macro environment, the reader does not track them. I'm wondering if a workaround could be to search the reader's text_db by not just thegoos::Objectbut by the text position. But for the purposes of finishing this work, I just statically analyzed and searched the code with throwaway python code.