ID:1254765
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
It takes a long time to compile changes for a big game (Like Space Station 13, for one), even if the changes are really insignificant. It makes it a pain in the ass to code. Now I really don't know anything about the way BYOND's compiler works, so I guess I might just be suggesting something rather absurd, impossible or already in there, so apologies for that. A idea I had for a efficient system (if it is even possible and something unlike it is currently in use) would be this: As it seems, the dream maker stores a list of all files. Why not associate a MD5-hash or other sort of short 'description' for each file that could uniquely identify it's contents? Every time you compile, if a file either has no md5 hash (a newly added file) or a file has a different stored md5 hash from it's current one, it is compiled. If the md5 hash matches, it does not compile. Or, perhaps associate a changed bool with each file. Each time you modify the code in a editor (while, the issue is here that it could be possible you undone the changes at some point, and it still re-compiles), it is marked as changed. All changed files are re-compiled and the changed variable is re-set. Once a new file is added, it is automatically set to changed.

Hopefully this is not impossible, already added or stupid. If it is, well, it was worth a try I guess.
Well, the main issue that comes to mind is that object definitions and even procedure implementations can span multiple files, and it's at that granularity you need to compile into order to write the DMB, not at the file level, sadly.

Considering one file as changed for example could impact many object types, which in turn live in many different files. Similarly, rename a procedure in one file and that impacts code in others etc. Piecing that together in order to update the DMB isn't a quickie task to implement, hence I guess they just start over again with the DMB as that's easier.