Quote:Original post by l3mon
Ever heard of "post-build-events" and "include paths"?
I'd go with number 2 if the projects have nothing to do with each other except sharing some convenient code.

Just make a "common" include directory and have your project update anything you need to after you built it. Same goes for "pre-build-events" :)

But if it's a huge bunch of code as you described, you should really go for a lib...

I never thought about it that way. I still don't see how it solves my "issue" as mentioned before, though.

Say I put the renderer into it's own project and include it in the solution. Now, say that main.cpp has calls to the renderer in it, and that both builds share this file.

The build which does not include the renderer will get errors. This was the whole deal with #ifdefs and why I wanted to use them in the first place, as I could place them around any calls to the renderer AS WELL as the actual renderer.cpp/renderer.h files. But this way the source files became very cluttered and I just couldn't stand it.

Thanks for your suggestion!

Quote:Original post by yaustar
I would use number 3 as suggested above but as an alternative, I would create two project/solution files that only compiles/includes the files needed for the build.

Not possible since they share some of the same files, and those files might contain (for example) calls to the renderer, which is not present in both builds. This is why I considered #ifdefs.

Quote:Original post by JasonBlochowiak
As far as this type of thing goes, there are two kinds of work: The kind you pay for up front, by doing the organizational and planning work that you should, and then there's the kind of work you pay for constantly down the line, because instead of doing the organizational and planning work, you took the "easy" way out.

The easy way seems cheaper, just because you don't necessarily see the subsequent wasted time in one chunk. However, it's almost always more expensive, because, instead of one lump of time, you're constantly being pulled off of what you're intending to work on, in order to fix whatever broke this time.

Good point! And in this case I saw that it would mean *alot* more work (and thus: time) to put everything into a lib rather than use two builds, which so far haven't been a problem at all.

Honestly, I think this is a matter of taste more than anything. Perhaps you guys are working with larger projects than I am and that I'm not seeing the issues with my approach until I scale :)

Quote:Original post by SymLinked
I still don't see how it solves my "issue" as mentioned before, though.

Say I put the renderer into it's own project and include it in the solution. Now, say that main.cpp has calls to the renderer in it, and that both builds share this file.

Well either you put your render project into the same solution and make sure the build order is correct, or you have a seperate project for the renderer and each time you update the code, you'll need a post-build-event, which then copies your render files to a common directory. In your other projects you simply have an additional include path to that common directory.
That way you make sure every project uses the up-to-date version of your renderer. Of course you should only make modifications to the renderer in the renderer project as any changes would be simply overwritten by the post-built-event the next time you build the renderer project.

Hope that removes the confusion, or did I get something wrong?

Quote:Original post by SymLinked

Quote:Original post by JasonBlochowiak
As far as this type of thing goes, there are two kinds of work: The kind you pay for up front, by doing the organizational and planning work that you should, and then there's the kind of work you pay for constantly down the line, because instead of doing the organizational and planning work, you took the "easy" way out.

The easy way seems cheaper, just because you don't necessarily see the subsequent wasted time in one chunk. However, it's almost always more expensive, because, instead of one lump of time, you're constantly being pulled off of what you're intending to work on, in order to fix whatever broke this time.

Good point! And in this case I saw that it would mean *alot* more work (and thus: time) to put everything into a lib rather than use two builds, which so far haven't been a problem at all.

Honestly, I think this is a matter of taste more than anything. Perhaps you guys are working with larger projects than I am and that I'm not seeing the issues with my approach until I scale :)

I wouldn't say it's so much a matter of taste as it is good habits. Bad habits are easy to get into, and tend to follow you around as you move from one project to another. Good habits are a pain up front, but tend to reward you continuously.

To your point, though, yes - I am used to working with full-sized real game projects, with hundreds of modules and tens of libraries. Good organizational habits are more relevant in that case than for situations with tens of modules. I do, however, stick by the notion that it's easier to learn good habits in a smaller scope, before you really need them, because usually by the time you've realized you've in a situation where you really need them, it's too late, and you have to go back and do cleanup work.