On 5/7/2011 12:06 PM, Totte Karlsson wrote:
> Hi,
> I'm working on a codebase that is to be used by two different
> compilers. I have a trunk-branch layout but realize that does not work
> that well for this. What seems to be needed are two "trunks" somehow.
> Is that possible?
>
> I would like to be able to avoid to clutter the code with #ifdefs in
> regards to the compilers, if possible. However, it goes further. Both
> compilers will for example read certain project files. These files
> can't be "shared". I would like to keep the same naming on files for
> both compilers too.
>
> The problem now is, as being told in this forum, "feature" branches
> are to be abandoned after merged back into the tree. There are some
> ways to avoid that, but it seem to esoteric for me.
>
> Anyway, anyone having some suggestions on how to deal with this scenario?
>
>
Two trunks is no different than having a trunk and a branch; Subversion
just tracks the state of a directory structure over time. The directory
names you create and the way in which you manage those directories are
your decisions. So the troubles you will have trying to keep a branch
in sync with a trunk will be the same as those you will have trying to
sync two trunks. Don't do it.
The usual way of dealing with compiler differences (I use Watcom C++,
Visual C++, and g++) is to define your own types etc. so that the
conditional compilation is restricted to the places where those types
are defined. Macros, used carefully, can also help.
If all else fails, define an abstraction layer of your own routines,
create copies of this abstraction layer for each compiler, and then call
only the abstracted code. The abstraction layer should have as little
as possible in it; don't copy any code.
The goal in both cases is to minimize the number of places where you
have compiler-dependent code. If compiler-dependent code is sprinkled
everywhere (either with #ifdef or as differences in trunk 1 vs. trunk 2
copies of the files) then you are most likely not organizing your code
in the most effective way.
As for project files, I create copies, then the post-checkout script
(run manually in my case) renames the appropriate copy. So I would have
a "makefile.wat", "makefile.msvs", and "makefile.unx", then rename one
of them to Makefile after checking out. Sometimes I set up build
scripts, then run the appropriate script and have it use "make -f
makefile.wat" etc. To minimize edits to the makefiles, I often define
"defs.mk" and "deps.mk" files that do some of the abstraction. So
makefile.wat would have something like:
!include ..\watcom.mk
!include defs.mk
!include deps.mk
target...
Master Watcom configuration parameters are in the parent directory
"watcom.mk" file, and it defines compiler flags, file extensions, and
generic build commands (e.g. ".cpp.obj"). Then the "defs.mk" file
defines the include and object file lists in machine-independent form,
while the "deps.mk" file defines the dependencies in machine-independent
form. Anything that cannot be machine-dependent goes into the
compiler-specific makefile, e.g. "makefile.wat".
--
David Chapman dcchapman_at_acm.org
Chapman Consulting -- San Jose, CA
Received on 2011-05-07 21:50:38 CEST