Re: Two different platforms sharing common code base: How to do so?

[Todd Denniston]

Spiro Trikaliotis wrote:
> 
> Hello,
> 
> I have a question regarding two projects, which do the same for Windows
> and/or Linux, and share many files of the common code base.
> 
> Unfortunately, the build systems or not compatible: GNU Make with gcc on
> the one hand, Microsoft's BUILD-Tool on the other. MS's solution needs
> the files to be co-located with the .C-files. To make things worse, GNU
> uses a file it calls "Makefile", as well as MS's BUILD-Tools.

I thought it was possible with MS to have them not collocated, but you have
to spend time figuring out how to convince the MS tool of that as it is not
the DEFAULT mode of operation.

> 
> So, a typical directory structure (should) look like this:
> 
> dir1/
> dir1/DIRS          [Win]
> dir1/Makefile      [Linux]
> dir1/dir2/SOURCES  [Win]
> dir1/dir2/Makefile [Win]
> dir1/dir2/Makefile [Linux]
> dir1/dir2/abc.c    [both]
> 
> The problem is obvious: dir1/dir2/Makefile has to be two different
> files, which is not possible at all.
> 
> I see the following solutions:
> 
> 1. Let Linux use a makefile called "GNUMakefile" instead of "Makefile".
> 2. Move the Makefile somewhere else, in other directories.
> 
> No. 1 has been rejected, as the Linux guys thing: "GNUMakefile" is a
> name which is reserved for makefiles which use GNU-specific extensions.
> This is not the case here.
> 
> No. 2 has been rejected, as MS's build tool does not allow having the
> SOURCES and Makefile files somewhere else than the .C files. They think
> it would make the Linux project look like a "2nd class" project if the
> makefiles of Linux or somewhere else, but the makefiles of Windows are
> in the directory itself.
> 
> Now, we ask ourselves how we can integrate both projects into one?
> Currently, we are using two CVS modules now.
> 
> I do not really see a solution to this. It would be nice if we could
> have 3 modules:
> - common files (.C)
> - Linux build system (Makefile)
> - Windows build system (Makefile, dirs, sources)
> 
> Now, if we checkout one module, for example the Windows version, we
> could checkout the common files, too.
> 
> Anyway, as far as I understand it, this is not completely possible with
> CVS, is it? Can we mix files in one directory this way? From my
> understanding of the CVSROOT/modules file, this is not possible, is it?
> For example, an ampersand-module puts another module into a
> sub-directory, they do not overlap.
> 
> Any advice is highly appreciated.
> 
> Regards,
>    Spiro.
I don't necessarily recommend this, but these may be workarounds.
A:
1) install cygwin or another unix like environment on windows, or possibly
even just perl.
2) use something like cvs_acls[1] to prevent anyone from committing a file
called Makefile.
3) create either a makefile (if using cygwin above) or perl script (if using
perl above), which:
3a) on unix an initial `make Makefiles` puts unix_makefile into the Makefile
locations, and on MS copies MS_makefile into Makefile locations.
3b) creates a MS_build dir and copy all the appropriate files there to take
care of collocation.
3c) when ran in commit mode, on MS, copies all appropriate files back to
repository locations.

B:
On second thought from 3b) you probably only need to create the MS_build
directory (and VC it), keep all MS building constructs (Makefile, *.rc,
other MS only files) in that directory, and have a perl/Makefile which takes
care of copying the files in and out of that directory.  Then have
cvs_acls[1] keep them from checking in anything that is not explicitly known
to be MS only in that dir (and subdirs).

C:
If you can get over the MS collocation problems, you should be able to just
use 1, 2, and 3a, and have the MS people copy their Makefile to MS_makefile
when they want to commit, the unix folks will probably quickly take to
editing unix_makefile and `make Makefiles` when they want changes.



End result, no one group is exceptionally happy, no one is first or second
class, everyone is equally troubled by their tools using the same Name with
different meanings, and hopefully gets back to coding while _silently_
resenting the CM person:) .

[1] https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter