Framework Command...

BlitzMax Forums/BlitzMax Beginners Area/Framework Command...

Shortwind(Posted 2010) [#1]
I'm looking for a precise reason for the current use of the FRAMEWORK command.

It seems to me that it would be more useful if you could include more than one specific library on the framework command line.

1. Why is it limited to just one library? I've seen no case where in reality you will not need to also use a number of Import commands. So what was the "original" intent of this command? Anyone have a good explanation?

2. It limits the size of the executable a little bit... So what? I mean in this day and age, is a 300K executable compared to a 1,200K-1,400K executable really going to effect a modern computer system?

3. Using it or not does not effect execution speed, so why use it?

4. Is using Framework a more useful command if your compiling a project for Win, Linux, and Mac?

Just curious. Is their any "real" reason I should use this command, or is it just a matter of preference?

Thanks... :D


Czar Flavius(Posted 2010) [#2]
File size can be important for downloads over slow connections. I agree it's unusual you are limited to one library.


xlsior(Posted 2010) [#3]
It seems to me that it would be more useful if you could include more than one specific library on the framework command line.

1. Why is it limited to just one library? I've seen no case where in reality you will not need to also use a number of Import commands. So what was the "original" intent of this command? Anyone have a good explanation?


That's just the syntax: by using 'framework' as the first import, you tell blitzmax not to include *everything* under the sun. the library on the 'framework' line is treated the same as any additional imports you may do afterwards. One framework + multiple import = your binary only contains those specific modules, instead of the default 'just include everything in the pub.* and brl.* folders'

2. It limits the size of the executable a little bit... So what? I mean in this day and age, is a 300K executable compared to a 1,200K-1,400K executable really going to effect a modern computer system?


It can make a great deal of difference if you have a popular game that has hundreds of thousands of downloads, and you're the one paying for the bandwidth bill.

It takes literally 30 seconds with Framework Assistant to optimize your program so it's a third of the filesize (media files not taken into consideration, of course).

Just because you apparently don't care about file size doesn't mean that the same applies to the users of your programs... Besides, it just seems sloppy to have an inflated executable size filled with unnecessary code when there is absolutely no reason to do so.

3. Using it or not does not effect execution speed, so why use it?


It wastes system resources (bandwidth, disk space), and unnecessarily large executables look like bad programming and/or lazyness. It's absolutely trivial to make your program look more professional by not wasting those resources, so why wouldn't you?

4. Is using Framework a more useful command if your compiling a project for Win, Linux, and Mac?


It does exactly the same on all three, so the 'usefulness' is identical on all platforms as well.

Just curious. Is their any "real" reason I should use this command, or is it just a matter of preference?


You don't have to, but personally I couldn't see why you wouldn't


Shortwind(Posted 2010) [#4]
These are all perfectly reasonable answers to the question. Nicely written, concise, and logical answers to the main questions. Thanks, well done.

;D


Gabriel(Posted 2010) [#5]
Just to cover one other thing which I didn't see mentioned before. Framework is not limited to one module. This is a fundamental point about how imports are viral in nature.

Open up the brl.basic module. It's in C:\Program Files\BlitzMax\mod\brl.mod\basic.mod if you installed BMax in the default directory.

It's nothing but a long line of import statements. This is how you structure a module if you want to use a whole bunch of modules with one framework command & no additional imports. Imports, as I say, are viral in nature so importing them in one module makes them available from anywhere in the program. So you could actually type Framework brl.basic at the beginning of your program and have access to all of the modules contained within.

So if you want to set up a group of modules as a framework all of their own for you to use over and over, that's how you might go about it.