Source code organization problems with BlitzMax
BlitzMax Forums/BlitzMax Programming/Source code organization problems with BlitzMax
| ||
| I like to separate my engine code from my game code. So the code that handles general engine duties lives in a totally separate directory tree than all the code that is game specific. I'm trying to get this set up with BlitzMax. And I'm having a lot of trouble. Really frustrating, because I felt as though a lot of what BlitzMax had to offer was improved environments for doing this sort of thing. I'd like to find out how others are handling this issue, and I'd like to find out what Blitz Research believes the solution is. One more note: My engine code generally gets large (60,000 lines of Blitz3D code in my old engine) and as such I like to separate the engine code into multiple directories (graphics, sound, input, physics, entities, etc. etc.). I first tried creating a public module for the engine. This seems like it would be perfect because every one of my games can just "import" the engine and poof I'm off and running. The module approach appeared to be working fine in that I could have complex directory hierarchies below the root of my module, with the top-level .bmx file importing in all the other code. I got this all working finally. The problem is, in the debugger, if I try to step into a function that is in the Engine, the debugger cannot step into it (cannot load source code). That's understandable, but it kills the module approach--there is no way for me to execute the bmx source and debug it. This is a show-stopper for me. Then I switched to just having the bmx code live in its own tree, and just import it into one of my game projects. The problem here is that Blitz cannot handle the sub-directories of the engine code. It is as if Blitz requires all imported code to live in the same directory as the original file doing the importer. This again is a show-stopper for me. Anyone else trying to do what I'm doing and having any luck? I'll post (in a follow posting) the exact directory structure I'm using and the compiler errors I'm getting. Driving me nuts. I think this is a serious issue for any serious engine development. Hopefully someone has found a solution to the problems. Ken |
| ||
| Importing seems to be pretty broken. It worked fine for a while for me, bet eventually i started getting strange and incomprehensable error messages. I had to resort to "Include"ing everything. This works fine and actually makes my project compile about 3X faster. |
| ||
| Hi, The problem is, in the debugger, if I try to step into a function that is in the Engine, the debugger cannot step into it (cannot load source code). This sounds like a debugger bug. The problem here is that Blitz cannot handle the sub-directories of the engine code How do you mean 'cannot handle'? What are the symptoms? I'll post (in a follow posting) the exact directory structure I'm using and the compiler errors I'm getting. Please do! I've had no problems with Import for a while now. However, I don't generally use complex source code directory trees so I may have missed something. The biggest restriction on Import is that it cannot be cyclic...ie: a file cannot directly, or indirectly, end up importing itself. Some see this as a bad thing, but I have ended up really liking how it forces you to structure your files. In C/C++, you can all too easily end up with a 'rats nest' of cyclic #INCLUDEs, often resulting in a big, painful refactoring of files further down the track. |
| ||
| There is also an issue of debugging where the call stack is inside a method, but the debugger will only show the type instance name and address. So you cant see local values of the method. ditching import entirely was my workaround. |
| ||
| Well, without some kind of example there's not much I can do! I just had a quick play around (on the Mac) and can step into methods in imported files just fine. Ditto stepping into stuff like the guts of TStream.Write()... |
| ||
| Mark, Thanks for the reply. I upgraded to v1.05, and now I can step into my engine code in the module tree. So I can return to using the paradigm of my engine code being a module unto itself, and the games simply importing my engine as a framework. I think that fixes things for me. If I have any additional problems, I'll post. If anyone pushes the boundaries of complex directories, that will probably be me :-) Thanks again, Ken |
   |