Differences bewteen Framework and Import ?

All,
I'm a bit confused with the Framework and Import statements.

Could someone be so kind to enlight these concepts to me ?

When is Framework needed ? What it does compared with Import ?

Thanks in advance,
Sergio.

Normally all modules are compiled into your program.
Framework specifies the base module that your program will use and you must implicitly import any other modules you need.

Required modules can be determined with the handy dandy Framework assistant

So, the statement
Framework brl.blitz will de facto import all the .bmx files contained in the brl.mod\blitz.mod directory ?

And the statement
Import brl.system
will import only the file brl.mod\system.mod\system.bmx ?

still quite confused. And yes, I've already noticed that 'Framework Assistant' by jb.

Sergio.

not quite.

let's take hello world:

Print "Hello World"

compile it and it will be 800kb+ in size because bmax compiles all modules into it.


But, compile this and it will be about 36k:

Framework brl.blitz
Import brl.standardio

Print "Hello World"

because it will only compile the modules you specify into it.

Framework sets the base module used and you import any other modules you need from there.

if brl.standardio includes other files or imports other modules, they too will be compiled into your app.

The framework are not very easy to understand ...

But another question :

If i have not import a framework, my exe is bigger , so ..
this executable file will be more slow than an exe made
with framework ? or it's just a size difference ?

no, the execution time will be the same, the extra modules are not actually used.
there *might* be a few milliseconds delay in loading the program into memory.

ok :) upx power :)

The behaviour is a little confusing, but it can be broken down thus:

1. If you don't use Framework at the top of your main code file

The BlitzMAX compiler will import all modules in the <BlitzMaxDir>\mod folder.

This means that for each module it will import the main bmx file (eg. for the Max2D module, it would import the mod/brl.mod/max2d.mod/max2d.bmx file)

2. If you use FrameWork <modulename> at the top of your main code file

BlitzMAX will not import all modules automatically, but just the module specified in the FrameWork statement, and any other modules specified using subsequent Import commands.

The BRL.Blitz module is always imported whether you use framework or not, so "Framework BRL.Blitz" at the top of your code is normally what I do.

If you tell BlitzMAX to import a particular module, it imports only the root source file for that module (<modulename>.bmx), although the root source file will usually import the other BMX files that make up the module.

===

If you do not use FrameWork, then your executables will be bigger, and the initialisation code for every module will be run before your program starts. The initialisation code does things like search for sound cards and OpenGL-compatible graphics cards, or initialise import global variables.

Use of FrameWork will make your executables smaller and they will start slightly faster.

Another use for Framework is to create your own frequently used frameworks. For example, you might want to build small console apps that use only Print and Input, so you could create a module like this example:

' Saved as io.bmx in a folder called mod\pub.mod\io.mod,
' followed by Build Modules from the IDE...

Module pub.io
ModuleInfo "Simple Print/Input Framework"

Import brl.standardio

Then whenever you want to build a simple console app with no extra frills you can just create a new source file and stick the framework name at the top, eg.:

Framework pub.io

Print "Hello world!"

... for a 37K app. Wanna hack out another little console app?

Framework pub.io

Print "Wow, it's so easy now I've created a framework for console apps!"

If you wanted another framework with some file I/O operations you could create another module, eg.:

' Saved as fio.bmx in a folder called mod\pub.mod\fio.mod,
' followed by Build Modules from the IDE...

Module pub.fio
ModuleInfo "Simple Print/Input Framework with File I/O"

Import brl.standardio
Import brl.filesystem

You can then easily create console apps that can read and write files just by specifying that framework instead:

Framework pub.fio

Print "Hello world!"

test = WriteFile ("test123456789.xyz")

If test
	Print "OK! Created test file. Deleting..."
	CloseFile test
	DeleteFile "test123456789.xyz"
	Print "Done."
EndIf

This can be extended to full game setups, eg. you could create a framework module for simple 2D games (eg. "Framework simple2d"), 3D stuff with physics modules imported (eg. "Framework 3dphys") or not imported (eg. "Framework 3dnophys"), etc, etc. You slap the framework name at the top of your program and only compile in what you need.

Ok, now is much more clear to me.

What I understand, is that:
- A Framework statement is always required if you don't want to include the whole modules; so it's like to say:
'do not include the whole thing, but just the module specified in the Framework, and the ones specified in the include statements that follow'

- choosing the right framework depends on which statements are used in the code, and in this case, the Framework Assistant by jb is really handy;

- if I do not use the Framework key word, but only the include statements, this will not prevent the loading of the whole thing.

The Framework as an 'include container' - thanks James - is indeed a good example of how to mantain the code tiny.

Thanks all,
Sergio.