Open GWRon opened 5 years ago
There won't be any additional texts being added to generated filenames. If anything, there may be a new file generated to keep track of them.... or something.
I thought about some kind of ".meta" file too. It could contain all the params used to compile (maybe even a hash of them in the first line...so only one short line has to get compared). Once we needed to check such a . metafile it could contain even more data (eg used compiler version). This way even a "quick" compile could recompile stuff if eg compiler version changed and potential bugs would else lurk around.
Of course .meta files mean additional file accesses and so a performance penalty. Dunno how much it would be.
When doing quick compilations unchanged files won't be recompiled.
Now each source file could contain/use conditionals. The basic conditionals (
?Linux
,?debug
....) are part of the filenames BMK creates from the sources (these .i, .a. ,... files) so if one of these basic conditional changes the lookup for a pregenerated file uses them and a change leads to a different filename and so a required compilation.The problem is then, that a custom conditional is not part of the filename (for now?) and this leads to "quick" compiles not picking up any change to these conditionals.
If this is a rarely used option then we could just append the custom conditionals to the filename. Done. Problem here? What to do once it is enhanced to allow expressions (
?WINDOWS_VERSION > 500
) like described there: bmx-ng/bcc#464 ?A "not the best but better than nothing" solution would be to just add "dynamicconditionals" (or similar) to the filenames if at least one was added via bmk->
bcc -ud
. All these files require a recompilation regardless of "quick" or not. This will of course lead to a cascade of recompilations if it happens in one of the framework/core files of a project.To avoid that,
bcc
could check conditional expressions: if it finds something comparing (= > <) or "joining" (?customConditionalA or customConditionalB
) then it is a dynamic expression and should append "dynamicconditionals" to the filename, if the whole file does not contain a comparison (so simple "true/false") then it could just append the conditional to the filename.Means having a conditional "freeaudio" and a "fmod" conditional the resulting files could be myfile.linux.release.x86.freeaudio.a myfile.linux.release.x86.fmod.a or dynamic myfile.linux.release.x86.dynamicconditionals.a
bmk
would need to add file checks too and I am not sure about the way to detect outdated dynamicconditional-files (eg you remove the dynamic conditional from the source - it does not delete the generated precompilates). Would at least require an additional run ("found a dynamicconditionals precompilate - need to check if this is still required or already unused").So ... I am not sure if this is even possible with "quick" and "dynamic conditionals".