You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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".
The text was updated successfully, but these errors were encountered:
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".
The text was updated successfully, but these errors were encountered: