#ifdefs are nasty. I strive to avoid them at all costs, or to confine them to a single file or something. If you have build-specific code scattered all over the code then you should probably refactor that functionality into build-specific classes or files.
That said, I'll take a thousand ifdefs over two separate branches. Especially if I'm using VC++ 8, which will color-code ifdefs correctly.
How do you manage multiple builds sharing the same code?
Good luck with #2, that's a horrific solution. Such a waste of time copying back and forth. Why is #3 not an option? Your boss won't allow it? Seems its a personal project. I'd put common code into seperate files and project specific code into seperate files so it can be blocked out.
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'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...
Quote:Original post by Jaymar
#ifdefs are nasty. I strive to avoid them at all costs, or to confine them to a single file or something. If you have build-specific code scattered all over the code then you should probably refactor that functionality into build-specific classes or files.
That said, I'll take a thousand ifdefs over two separate branches. Especially if I'm using VC++ 8, which will color-code ifdefs correctly.
This about sums up my opinion too (with the noteworthy exception of include guards of course). It's a lesser of two evils issue, and manual syncronization is just repeatedly kicking yourself in the nutts (and a horrible violation of the DRY principle - Don't Repeat Youself). The only time I use multiple branches is when I'm working with multiple versions for bug hunting (comparing "buggy" and "bug free" versions), archival purpouses, or large scale OSS apps which use multiple branches to seperate feature testing/debugging off from the trunk for stability purpouses (or similar).
If you use anything like a decent IDE for your development, the best way is to make several distinct build targets.
Target 1 contains the aources with the code shared by both different versions, building a static library.
Target 2 holds the sources making up flavour one, and links with the library produced by Target 1.
Target 3 holds the sources making up flavour two, and links with the library produced by Target 1, too.
Target 1 contains the aources with the code shared by both different versions, building a static library.
Target 2 holds the sources making up flavour one, and links with the library produced by Target 1.
Target 3 holds the sources making up flavour two, and links with the library produced by Target 1, too.
I can't imagine trying to manage 2 separate projects with cut and paste. Ifdefs aren't that bad. It should be possible to push those ifdefs into a small minority of files, which can then be managed separately. Some files can be excluded from certain builds to make life easier too.
I am not sure if I understand your problem, but why can't you use option 2 but without copying and pasting? I mean, why can't you simply have two projects, each of which depend on whatever files they need?
The only reason I could think of is that there are files which a project "only needs half of", but it seems like those situations, beyond being bizarre, could be very easily refactored into two files, and then the target that needs everything could just include both. This wouldn't seem to involve actually writing any code (beyond a few #includes perhaps).
The only reason I could think of is that there are files which a project "only needs half of", but it seems like those situations, beyond being bizarre, could be very easily refactored into two files, and then the target that needs everything could just include both. This wouldn't seem to involve actually writing any code (beyond a few #includes perhaps).
Quote:Original post by SymLinked
Aye, I would had used a shared library if the code wasn't so much dependant on different parts. It would require alot of recoding and that's alot of work.
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.
If you ever think of "copying and pasting" then you should probably look into using some sort of source control. At least then you can use branching which will do the copying and pasting but allow you to more easily merge between the two. I don't know if this is a viable solution for the OP though. If you are thinking of using source control I'd check out Subversion. Its pretty cool and you can use TortoiseSVN for a GUI interface( I think its Windows only, check out RapidSVN for a cross platform gui interface ).
We managed 100+ different kind of platform specific codes by having a seperate platform folders. eg.
\projA\src\main - main program
\projA\src\render - renderer subsystem
\projA\src\ai - AI subsystem
\projA\src\platform\linux\main - main program for Linux generic
\projA\src\platform\linux\render - renderer subsystem for Linux generic
\projA\src\platform\linux\amd64\render - renderer subsystem for Linux AMD64
\projA\src\platform\linux\amd64\ai - AI subsystem for Linux AMD64
Our build system will use the correct files from the targeted platform specific folders when compiling. When no platform specific files is found, the more generic version of the files will be used. That said, it won't be applicable when using the project/workspace build of MSVC; we use command line for the builds.
As for code modification, well yes, you have to apply them to the correct platform specific files manually. We found it rather easier to have seperate files/folders than to put in everything in a file with #ifdef. Remember we have 100+ platforms to support.
\projA\src\main - main program
\projA\src\render - renderer subsystem
\projA\src\ai - AI subsystem
\projA\src\platform\linux\main - main program for Linux generic
\projA\src\platform\linux\render - renderer subsystem for Linux generic
\projA\src\platform\linux\amd64\render - renderer subsystem for Linux AMD64
\projA\src\platform\linux\amd64\ai - AI subsystem for Linux AMD64
Our build system will use the correct files from the targeted platform specific folders when compiling. When no platform specific files is found, the more generic version of the files will be used. That said, it won't be applicable when using the project/workspace build of MSVC; we use command line for the builds.
As for code modification, well yes, you have to apply them to the correct platform specific files manually. We found it rather easier to have seperate files/folders than to put in everything in a file with #ifdef. Remember we have 100+ platforms to support.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
