Clarification on how BMX uses modules
BlitzMax Forums/BlitzMax Beginners Area/Clarification on how BMX uses modules
| ||
| As far as I understand, on a standard BMX installation, you will automatically include every module in the exe, unless you specifically choose not to. Is this correct? The reason I ask is because it would seem better for the compiler to only add the libraries you actually use to the exe. Andy |
| ||
| That's correct. Apparently you use the `Framework` command to define specific modules to use, and also `Import` can help you structure your application so that you only have to recompile the sourcecodes that change. |
| ||
| I don't understand why the compiler doesn't add the specific modules either. How do people keep track of which modules they have actually used? |
| ||
| Hi, Also you can only have one Framework. Framework Me Import this Import That etc |
| ||
| You would need to know which commands are within which modules, which isn't very easy to tell at the moment. |
| ||
| It's really backwards that you would even need include directives in 2005. But such is life I guess. Andy |
| ||
| I think the argument is that automating the process of deciding which modules to include is a non-trivial exercise that would take quite a lot of effort to implement. By providing a manual mechanism to achieve this, BRL still allow you to achieve small EXE sizes, whilst allowing them time to focus on other things that most people would prefer, and that can help to generate further sales. i.e. Full Win32 & Linux releases, a 3d module, a GUI module, etc. |
| ||
| I seem to recall that Mark stated that this was left to the end user to prevent unexpected behaviour when dealing with variables, among others. For example, if you allow the end user to specify a specific image to load and end up using something like: LoadImage(myfile$) in your code, there is no real way for the compiler to know up front if it needs to include the PNG loader, the JPG loader, BMP loader, or whatever other image formats you may have. That said, in most programs (especially games) the programmer is typically in full control of which files get written or loaded by the program, so the above scenario shouldn't be too common I would think... Even if it would be impossible for Blitz to give a 100% definite answer which modules would be needed, it would be extremely helpful if it were possible for it to generate a 'best guess' that can be finetuned by the programmer... Sure beats making it up from scratch each time. (Of course this might be something that someone else could put together as an external tool as well? analyze a piece of code, analyze the mods, and try to add two and two together?) |
| ||
| >For example, if you allow the end user to specify a >specific image to load and end up using something like: >LoadImage(myfile$) in your code, there is no real way for >the compiler to know up front if it needs to include the >PNG loader, the JPG loader, BMP loader, or whatever other >image formats you may have. I assume that all 'loaders' would be in the same library. It just seems so 'ancient' that the compiler is so 'dumb' that it can't figure out which libraries to include. >Even if it would be impossible for Blitz to give a 100% >definite answer which modules would be needed, it would be >extremely helpful if it were possible for it to generate >a 'best guess' that can be finetuned by the programmer... >Sure beats making it up from scratch each time. If we assume that all commands dealing with loading different kinds of images is in the same library, then it doesn't seem that farfetched. Andy |
| ||
| If we assume that all commands dealing with loading different kinds of images is in the same library, then it doesn't seem that farfetched. It's an incorrect assumption though -- the images are loaded through different modules: - BRL.BMPLoader - BRL.JPGLoader, - BRL.PNGLoader - BRL.TGALoader The major advantage of this is that you can include only the libraries required for the image format(s) your program actually uses, cutting down on filesize again. |
| ||
| >It's an incorrect assumption though -- the images are >loaded through different modules: Ok! >The major advantage of this is that you can include only >the libraries required for the image format(s) your >program actually uses, cutting down on filesize again. But still it would be nice if the user is given an option(Just a menu setting) to include all(standard) or just the max number of modules needed(including all image loaders). It would still not include all modules but would decrease the size of the exe. Ok - I'll stop bitching about it! Andy |
| ||
| On this subject, what is the actual difference between FRAMEWORK and IMPORT..? I know the following: - If I don't use anything every module will be imported - If I use FRAMEWORK the specified module will be imported (and all other modules this module and its dependencies IMPORT) - If I use only IMPORT I can import modules which is not usefull because they all are already imported because I did not use FRAMEWORK Won't it be more clear that if I use 'FRAMEWORK' as a statement to tell the compiler only to IMPORT the modules I wish to IMPORT? Of course you need an extra IMPORT command but it'd be much more logical to me. If I'm wrong, please tell :) |
| ||
| "Import" imports a specific module (or other source-code file). "Framework" tells the compiler NOT to import every module that exists and imports only the given module in the Framework statement (so you can say the Framework command does 2 things: turn automatic importing of every module OFF, and uses the import command to import the given module). |
| ||
| So I got it right then... doesn't really seem logical to me then, but not a problem whatsoever :) |
| ||
If you do...framework BRL.standardio Print "Hello World!!!" you get a 33kb exe. import BRL.standardio print "Hello World!!!" it's 761kb so it seems that Import is best used for 'additional' modules outside the BRL/PUB/custom frawework.. Is that right? |
| ||
| afaik, idd that's why I think 'framework' should be a statement en not a function but hey, who am I anyway ;) |
| ||
| How do you know which modules you are using per program for using with Framework? |
| ||
| The only way I can think, and it's a poor way, is to check which module the commands come under in the docs or by checking the BRL.MOD and PUB.mod directories. |
| ||
| by opening all modules and see where they link to ... a dependency-checker would be nice, but atm I'm not in for writing one ;) |
| ||
| In that case then an auto framework option would be very handy. Or at least in, one of those three projects / debug tabs , that would be an ideal place to have a listing to tell the programmer which modules have been loaded for that particular program. That I feel will be extremely handy and helpfull to everybody. As surely the "Build and run" (F5) dodar must know which ones have just been loaded / started. |
| ||
| As surely the "Build and run" (F5) dodar must know which ones have just been loaded / started. Well... Not really, since It either included the ones you manually specified, or it included 'everything'. but anyway, it should be pretty easy for the program to determine which modules are 'definitely' needed, and a couple which might 'possibly' be needed (e.g. the various image file decoders, audio decoders, etc.) It would be *great* if there were an option where it would show you the 'definite' modules, and give you the option to add the 'possible' modules where the program cannot determine for certain wether or not they might be necesary. (for instance, in the case where use defined files might get loaded, and you want to be able to handle multiple graphic formats. If you know for a fact that you only use PNG in your program, you can then choose to leave out the other decoders) |
| ||
| Would it be possible to allow the reverse? Allow me to tell it to exclude modules I am sure I wont use? |
| ||
| This is very helpful... Framework Assistant |
| ||
| The main point of Framework is to provide a single file that can then import a set of modules as required for a given purpose, eg. a 2D framework, a 3D framework, a console app framework, etc. If you create a module that just imports what you need for a given purpose (eg. you might create a framework for 2D apps, one for console-based network apps, one for GUI apps with networking, etc), you can just call Framework to provide a particular set of modules for the type of program you're writing. Import in conjunction with Framework just lets you add more modules to a particular app as required. |
   |