Better Linking?

BlitzMax Forums/BlitzMax Programming/Better Linking?

Gabriel(Posted 2008) [#1]
There has to be a better way of linking than I'm doing with my game engine. It's a big engine now, with probably 100+ source files, and that doesn't include the graphics engine or any of the modules I use.

Currently I have a main source file which imports all source files which are completely without dependencies ( very few ) and includes files which have dependencies. It takes a good thirty seconds to compile and link the whole thing.

Ideally I'd import everything, but as I say, most everything has dependencies. For example, many of my classes have the ability to write themselves out to an xml node. So they have a SaveToNode(Node:TXmlNode) method which passes an XML node from bah.libxml and writes out the object. So if I import all these files, they now each need to import bah.libxml. Now I know that the linker is smart and will only link the library once, but I don't really like the idea of cluttering up every source file with includes and imports at the top. I much prefer doing all of that in one file.

Am I missing a better way of doing this or do I just have to grit my teeth and decide whether 30 seconds for a small change or cluttering up every source file with imports is the lesser evil?


Brucey(Posted 2008) [#2]
It's the includes that are slowing you down. If you were able to Import everything the build would obviously be much faster - what with not having to create the large main file from lots of separate ones.

You have SuperStrict at the top of all your files, don't you? (at least those that you Import), a few lines of extra Imports won't hurt :-)
C works the same with it's #includes, doesn't it?

It's not clutter :-)
And, it depends how often you build? If my stuff took 30 seconds to build everytime I had to test something I'd be a tad frustrated...


Gabriel(Posted 2008) [#3]
Well I tried converting a few includes to imports and the compiler started throwing errors like "cannot convert from MyLongAndMeaninglessType to MyLongAndMeaninglessType" which makes no sense because MyLongAndMeaninglessType was imported well before that, so I guess I'll have to stick with the 30 second compiles.


GW(Posted 2008) [#4]
I've had this same problem with my project that includes many files.
The way BMax handles imports Bull***t!
the Include directive is the only thing that works for large projects.


Brucey(Posted 2008) [#5]
the Include directive is the only thing that works for large projects.

which is obviously completely untrue :-p

If your design is good, you can use Imports without any issues at all.

I've never used Include since I started with BlitzMax, and I've got one or two smallish projects which prove the design point.


DavidDC(Posted 2008) [#6]
@the Include directive is the only thing that works for large projects.

My current project is over 250 .bmx files without a single include.

But I still suffer Gabriel's problem of slow build times. It's a tough one to overcome. If my design was a little cleaner then I'm sure I could have split it into more modules than I have. But the final structure isn't always obvious when you start out, no matter how well intentioned your design graphs...


Blueapples(Posted 2008) [#7]
The machine you're on can make a huge difference. For me, I see drastically different compile times between my work machine (Windows 2000), home PC (Windows XP Media Center) and my laptop (Mac OS X).

Maybe get a faster machine or upgrade? It's a bit of a drastic move but if it's really bothering you I'd say it's worth it.


JoshK(Posted 2008) [#8]
Importing doesn't really work for me. My code files always reference each other, so most of my code does not work as a neat little self-contained unit.


Grey Alien(Posted 2008) [#9]
I've always used include (and suffered long compile times - was thinking of upgrading the PC) but recently one of my framework customers turned my framework into a module which I can now import. I think it's probably the best way to go...


slenkar(Posted 2008) [#10]
i always try to put as much code into a module as possible.
The way blitz handles modules and imports is pretty good


Gabriel(Posted 2008) [#11]
Sorry, I should have been clearer. The machine it's being compiled on is already about as fast as you can currently get. I'm actually surprised it compiles as fast as it does, considering the size of the source.

The game engine is already a module. It's just a very, very big one. About 3.5 megabytes of source, not including various modules which it imports itself.

Most objects interact with other objects, so creating a structure where I could group sections isn't easy. And as I said earlier, even when I do, I get the compiler throwing silly errors.

As for whether C/C++ work the same way, I don't know, probably. I've never written anything remotely approaching this size in C++. I know that I never had any problems with my TV module, but I guess that's not huge.


slenkar(Posted 2008) [#12]
how many lines of code do you have that are not in modules?

how many incbins do you have?


Dreamora(Posted 2008) [#13]
I always do the best of both worlds: Clusters like Java

-> I import subsystems in the main file. These subsystems consist of stuff thats interrelated and therefor need to be included.

This gives the benefit of no need to recompile subsystems as well as enclosed variable spaces (I often used private globals etc).

Stuff that I think is well enough structured etc eventually makes it into a module, but that does not happen until it works etc as debugging is really annoying with modules.


Gabriel(Posted 2008) [#14]
how many lines of code do you have that are not in modules?

Eleven.

how many incbins do you have?

None.


slenkar(Posted 2008) [#15]
hmm ive seen adverts in magazines for programs that can use multiple computers to compile a C++ project.

I wonder if blitzmax uses all the cores on a CPU to compile a program?

I take it that it would be a lot faster if you could create a DLL?
I dont know if its possible to create one with blitzmax source code