Question about user modules
BlitzMax Forums/BlitzMax Programming/Question about user modules
| ||
| If you make your own module and place it in with the BRL ones (instead of keeping it seperate from them) will it automatically be included when you compile your program or do you still have to manually import it at the top of your code? I know that this will add to the size of your .exe but I would just like to know as I do not currently have mingw on my machine to test it myself. Thanks, Jason. |
| ||
| No idea but you should create a folder called, say, QuickSilva.mod, then a QuickSilvasFirstModLiekEver.mod within, and have your module there. It is senseless to NOT use Framework/Import, since using them will cut your executable size down dramatically, as only the modules you need will be included. Use Jim Brown's Framework Assistant to determine which modules you need. |
| ||
| ...will it automatically be included when you compile your program or do you still have to manually import it at the top of your code? No it will not. Only a few BRL modules get imported to any source code automatically (when Framework is not used). It is senseless to NOT use Framework/Import, since using them will cut your executable size down dramatically, as only the modules you need will be included. 100% agree. |
| ||
| No it will not. I was under the impression all BRL and Pub modules are included when you don't use Framework. <EDIT> I just tested it out, and it certainly appears to be true. |
| ||
| Thanks for trying it. I was just curious really. I can certainly see the benefits of having user modules in there own folder but I thought that it would be intersting to see if it worked. Jason. |
| ||
| I just tested it out, and it certainly appears to be true. Interesting.. |
| ||
| yes brl and pub modules get fully included if you're not using framework. But writing user modules and give them brl or pub scope is a bad idea. 1. It is blowing your app size and compilation time. 2. brl and pub folders will completely update with each bmax update. So you have to manually copy your mods each time a new update was installed. In my opinion user modules should never be placed in brl or pub folder. I remember dreamotion which was/is build in pub scope and every small app which was build later was trying to load the dll needed for dreamotion, if you didn't use framework. And to be honest thats a no go if you just want to test small things. |
| ||
| Could be handy if you want to include some features to existing BMax mods though without actually changing them, ones that you always want to be present. Jason. |
| ||
| ones that you always want to be present. If you use Framework, you are only guaranteed to have BRL.Blitz and Pub.Stdc. (By default also BRL.AppStub - but you can override that). The rest, you would of course Import - although, since there are other dependencies, importing one module will likely get you a bunch of others as required. There's no reason not to use Framework. :-) |
| ||
Just for fun, here's the BlitzMax import tree (for BRL and Pub) : (as generated by BaH.Graphviz no less :-p ) Without using Framework, you get ALL of these!! Yay! |
| ||
| I fancy some spag-bol for dinner. Dunno why... |
| ||
| Do you have to use Framework when building a module as well? |
| ||
| No. Framework is implied - so you need to import everything you need. |
| ||
| To add to this discussion: Can I use Framework twice in the same code? It seems that the IDE shows me an error and I haven't quite understood if I can use it multiple times or if I should use Import for other modules. If I have something like: Framework maxgui.Drivers Framework bah.DBSQLite the IDE won't let me proceed. Am I doing it the wrong way? :/ |
| ||
| Am I doing it the wrong way? :/ Yes. When you have Framework, you're essentially saying "I don't need anything else except this". So saying it a second time makes no sense. Any modules you need above and beyond what you define with Framework need to be Import'ed. ' JUST ONE FRAMEWORK Framework maxgui.Drivers ' THEN IMPORTS Import bah.DBSQLite ' MORE IMPORTS IF YOU NEED THEM ' | ' | ' | |
| ||
| Thanks for the explanation, Gabriel. I guess what still confuses me is that Framework is supposed to let the user manually choose what to import. But what about the brl modules? Aren't some of them necessary? The idea I have of Framework is that when you use it you have to import everything you need manually. My application worked with only this: Framework maxgui.drivers Shouldn't some basic system modules be included manually? |
| ||
| I don't have a recent copy of MaxGUI downloaded, and I guess SVN is up the chute at the moment, so I can't download it to test. I rather suspect, however, that if you open the module, you'll find that it imports a number of other modules itself. In other words, if the module you import needs other modules itself, those will be imported too. MaxGUI is a pretty big one, so it probably needs lots of stuff. |
| ||
| The only Module that is necessary for any program is brl.blitz (and it is always imported regardless of framework). I prefer to do Framework brl.blitz ' Imports.. for anything I write. |
| ||
| Thank you guys. So summing up the lessons learnt here: In a game: brl.blitz is the minimum framework I can use. In a GUI application: I could use the maxgui framework because it imports mostly everything that's necessary. With that, my executable size dropped considerably. :) |
| ||
| Personally, I'd like to see something like Framework Assistant incorporated into the compiler so code is automagically made as small and efficient as possible. And throw in auto-UPX for good measure... Russell |
| ||
| Personally, I'd like to see something like Framework Assistant incorporated into the compiler so code is automagically made as small and efficient as possible. And throw in auto-UPX for good measure... Apparently the biggest hurdle was determining whether or not you need things like jpgloader, bmploader, oggloader, etc. because it's not always possible to determine ahead of time which data formats the program would be dealing with... But you'd think that the compiler should be able to rule out at least some of the modules automatically... |
   |