Disable ".bmx" folder creation?
BlitzMax Forums/BlitzMax Programming/Disable ".bmx" folder creation?
| ||
| Hi! I was just wondering if it is possible to disable the creation of the tmp folder when compiling a project. Or at least autodelete it after termination of the program. There's a lot of waste in a dir if you just go and compile the samples eg. Best would be if the compiler places these files in the system memory temporarily. |
| ||
| I don't think this would be a good idea. having the object file allows you to distribute your module for instance without releasing source. *EDIT* and it would probably break quick build |
| ||
| Hi Grisu, The .bmx folder is where all of your compiled modules are stored when they are built. If you delete the .bmx folder, then all of your source files will have to be recompiled when you rebuild the source code, not just the ones that have changed. |
| ||
| Well. for the normal tiny programs this does not take THAT long to rebuild. I just hate it that you have to delete all these files by hand to get a clean hdd. |
| ||
| I just hate it that you have to delete all these files by hand to get a clean hdd. It would be quite easy to write a program to do that for you though. |
| ||
| It would be quite easy to write a program to do that for you though. It probably wouldn't be entirely safe though. I just hate it that you have to delete all these files by hand to get a clean hdd. Clean? How do you mean? The files in the .bmx directory are actually rather important, and cannot be stored in memory, as the linker (ld) would then not be able to locate them - more importantly however they would not survive between compilations.Personally, I think having small hidden files on my harddrive is a small, and rather acceptable, price to pay for not having to wait ages for BlitzMAX programs to recompile absolutely everything. |
| ||
| I'm with FlameDuck on this. |
| ||
| I have some problem sometime with compilation :) i need desactivate the QUICK BUILD option for full compilation, because sometime bmax don"t compile your code if you have made some little changes. |
| ||
| Filax, you are not alone. :D It might be ok if you keep the tmp files for main projects. But I dislike it that when I just compile the bmx samples a subfolder and exe is created by "default". Anymore people that like to flame me for that? ;) |
| ||
| But I dislike it that when I just compile the bmx samples a subfolder and exe is created by "default". The BlitzMAX build system is completely different from Blitz3D and BlitzPlus, where the code could be generated and then somehow executed from inside the compiler process so that no standalone executable was created. In BlitzMAX each source file is compiled into an object file, and then the GNU ld tool is invoked to link these objects together to produce an executable. Thus the compiler *has* to generate these objects and a standalone exe. |
| ||
| Grisu, Here's a utility I created to clean up the folders. Deletes the *.bmx folders, *.exe, and *.bak files in the specifed folder. If you place the code in the BlitzMax root folder and run it from there it goes through the samples folder with its sweeping brush. Use at your own risk of course. |
| ||
| Thanks Jim! |
| ||
| The .bmx folder is where all of your compiled modules are stored when they are built. If you delete the .bmx folder, then all of your source files will have to be recompiled when you rebuild the source code, not just the ones that have changed. And this can cause a problem if one of the files in the directory are corrupted. On one occasion I know about, I had a bad/corrupted/locked file in the .bmx directory, and it was giving me trouble compiling. I thought it was my code... it took me a while before deleting the .bmx directory. |
| ||
| deactivating quick build in this cases helps as well. normally this problems come up if you build a subfile on its own and use quick build on the main app afterwards as the .o of the subfile you import isn't created for importation in this case |
   |