ENIGMA Forums
Contributing to ENIGMA => Developing ENIGMA => Topic started by: Josh @ Dreamland on February 24, 2014, 08:36:47 pm
-
I never make changelogs; this is a personal mistake I'll attempt to work on. I am using this thread to document notes for developers and changes to the new compiler framework. I will place these changes in the Wiki after the fact. Excuse the Wiki list notation in the meantime; there's no sense in my formatting it with SMF's syntax if it's just going to be * in the end.
Notes:
* Files in the CompilerSource/JDI folder are meant to be read-only. This is a verbatim copy of the JDI repository (https://github.com/JoshDreamland/JustDefineIt); please make any changes there. We might end up renaming this to JDI-read-only to comply with the precedent set by other projects.
Changes:
* EnigmaStruct is no longer the main argument to compiler functions; it has been wrapped in a new class, compile_context.
** This class also contains the global object parsed_object *EGMglobal; the other parameter to most compile routines.
** This class also contains FILE *gameModule, the other parameter passed to most resource writing routines.
* There is now a separate resource_writer class to handle—you guessed it—writing resources. This is not only so we can support multiple languages, but also so we can support multiple resource export schemes (eg, internal, external). This is generated by the compile() method of the corresponding language adapter.
* Compile functions are now all snake_case, not some_SnakeCamel_Bastardization
Changing:
* The way JDI interfaces lexers and contexts needs changed—these are independent concepts.
-
This is great news! I can't thank you enough Josh! I'm very excited for this update.
-
You could use a git submodule to more forcefully show the read-only nature of the JDI directory, as well as not including the history of JDI in ENIGMA's repository, and allowing you to specify a precise commit in the upstream JDI repo that ENIGMA depends on, which can also be versioned.
-
Last I investigated Git submodules, they sucked. I'll give them another look, because we could desperately use that functionality. The ability to have users check out one repository URL to receive code from both is a must.
-
The pain point of submodules is that after cloning [or updating] you have to run this:
git submodule update [--init]You at least don't need to specify the second repo url.
An alternative that avoids this problem at the expense of some different complications is git subtree.
-
Bleh. As long as it gets *all* the submodules with that one call, that's fine. There's just no room for expansion otherwise.
Here's my secondary concern: When I go to GitHub and press "Download zip," what do I find in the submodule/subtree folders?
-
Sadly, it does not include the subfolder contents. However, people who want to develop ENIGMA will need Git anyway, and it should be pretty simple to create a "make dist" target that includes all the source that you could upload to GitHub as a release (when you get around to tagging releases).
-
I was hoping to use GitHub to generate a basic zip file for release building. I want to eventually automate package generation on this server or another. I can, of course, have git check out all that stuff locally, then zip it manually, but then I have to delete the .git directories. Please tell me there's only one of those.
-
There is just one .git directory; submodules have a .git file with "gitdir: ../.git/modules/<name>" or whatever in them. There's also .gitignore, .gitmodules, etc. that you may want to ignore as well (and that a GitHub zip would still have).