Open GWRon opened 5 years ago
woollybah
commented
5 years ago This seems to add a whole lot of needless complexity.
For typical users who are only working with a released version of BlitzMax, this is not an issue.
If you update bmk or bcc, perhaps you should just consider rebuilding your stuff.
GWRon
commented
5 years ago Then maybe... there is bmk cleanmods - but it ignores .i and .a files, so it most often just removes the .bmx-folder.
While I could use it, it does not enforce the recompilation of the module - is there a reason for bmk cleanmods to keep these files (third party modules only providing the precompilates but no source?) ?
Dunno if that works - but couldn't it remove also .i and .a files if the "corresponding" .bmx files are present (or does that work for .c files too and does not necessarily require a .bmx file)?
Executing bmk cleanmods will save you from recompiling all modules ahead of being required. Just clean the modules and once you need them they get auto-compiled by BMK then.
GWRon
commented
5 years ago Once bmk cleanmods works as expected (for me - so removing all the precompilation stuff if possible) we should consider adding a simple menu entry to MaxIDE - next to "Build Modules" and "Rebuild All Modules".
When stuff like BMK changes the way it calls the compilers (like the newly added "-no-pie" parameter - with the "new behaviour" as default, this requires all modules to be rebuild properly to not run into odd linker errors.
I thought we might discuss about a way to (semi-)automate the process of cleaning up and rebuilding modules.
Dunno how to approach this - but maybe BMK could store a file of its revision/"api version" when compiling modules. So if there is some groundbreaking stuff changed in BMK this number increases. When compiling then BMK checks if the modules were "outdated" and if so, removes any .bmx/.h, .bmx/.c,..., .i, .i2, .a. ...etc precompilates from the modules to enforce a proper recompilation.
Especially with "quick [scan]" stuff will else get missed here and there.
Another option would be to use another sub directory within ".bmx" - like ".bmx/19" with 19 being the "ABI/API". a special "bmk cleanmodules" command could be added to remove any module precompilates lower than "19". This number could also be configured via "make.bmk" (and consortes) so people could use custom prefixes if they wanted. Precompiled .a files then could get this number in their filename too (linkedlist.debug.x86.v19.a)
I thought about allowing individual version stamps - this would only be useful if you could set multiple BMKs to get used or to define options "per version stamp".
So config.bmk would allow for individual "version stamps" which override what "bmk -apiversion" (or however we call it) returns.
We could use this version stamps for:
Precompilates could stay without "versionstamp" if only one file at a time is to allow (or backwards compatibility is desired). Or you ignore disk space occupation and have both files: the versionstamp-containing filenames + one without which equals to the last build "version stamp" (feels dirty).
Next BMK needs a "cleanupmodules" command which just removes every .bmx/-stuff lower than the current versionstamp, it also removes the precompilates. Why? Else your disk space will fill up more and more with no longer used "cached precompilates". Exception is said individual "profiles" / versionstamp-individual-options for BMK.
For now this seems to be a bit overkill to add this - but if you think about some "update"-feature (updating modules, bcc, bmk, maybe even maxide per "maxide menu click") such features come handy without enforcing a complete (and long!) module recompile on each "update".