RE: Attn Dennis Jones: CVS Windows Build, Visual C++ Project Files

[Conrad T. Pino]

Hi Dennis

> From: Dennis Jones [mailto:djones@oregon.com]
> 
> As far as I have been able to determine, VC5 has no trouble building CVS
> using the VC6 project files.  If this continues to be true, I would have no
> problem with changing the lowest common denominator requirement for CVS from
> VC5 to VC6.

OK that's different than what I proposed.  To summarize, dropping VC5 support
and upgrading the existing project files to VC6 is acceptable.

> However, the main problem Derek and I have discovered recently is not an
> incompatibility between VC5 and VC6, but rather that they both tend to put
> absolute paths in some of the project files (libdiff in particular).
> Neither of us have been able to determine how/why this happens.  Perhaps it
> is a bug in the VC++ environment, or perhaps there is something about the
> project files themselves that makes the IDE think it should use absolute
> paths when generating the makefile (if this is the case, I have not been
> able to find the piece of information that triggers the absolute paths).

I can't make this go away either.  I'm calling it a bug but loading the
latest VC6 Service Pack 6 doesn't help at all.  It's as if VC runs a full
dependency check then subtracts it's internal files and always missing just
one.  The only absolute path I can replicate with VC6 occurs only in the
"cvsnt.dep" file created by "Export Makefile...".  A typical entry looks
like:

.\src\buffer.c : \
        ".\lib\exit.h"\
        ".\lib\fnmatch.h"\
[snip]
        ".\windows-NT\ndir.h"\
        ".\windows-NT\pwd.h"\
        "c:\program files\microsoft visual studio\vc98\include\basetsd.h"\

The absolute path is *ALWAYS* for "basetsd.h" which is a nested Windows
SDK inner level include.  Can you verify if it's the same include set on
your system or send me your unmodified regenerated files?

> Another problem seems to be that some of the files seem to get built in
> debug mode, regardless of which mode is selected.

I can't replicate this but I suspect it was true.  Derek's good hands
may be at work here.  The problem is likely to arise again because the
current *.dsp files contain a large number of configuration dependant
property overrides within the project node tree.  If the override values
are wrong on some nodes then mixed mode WinDebug and WinRel output will
occur.

I've proposed a patch to the *.dsp files which removes all the property
overrides assuring correct builds and is easy to audit.  The patch thread
begins at http://mail.gnu.org/archive/html/bug-cvs/2004-04/msg00037.html
and I would appreciate you checking it out.

I would appreciate your regenerated *.dep & *.mak files from this patch
so I can see the absolute paths that are different than mine.

> Whatever the reason, these are the biggest problems with getting a portable
> CVS makefile, regardless of the VC version, because every change to the
> project files that requires a regeneration of the makefile forces someone to
> manually correct the problems afterward.

If the way above holds the a simple "grep -v basetsd\.h ..." based script
would automate the fix up prior to committing.

> As it turns out, the only reason I even keep VC5 on my system, is to build
> CVS -- and the only reason I bother building CVS at all, is because there
> never seems to be an "official" Windows build available, and I like to stay
> up-to-date.  And so, because I provide a CVS executable to my co-workers, I
> do need to be able to build it on occasion.

The grief with VC(5,6) has motivated me to try MinGW http://www.mingw.org/
gcc 3.2.3 port currently in MinGW 3.1.0 package.  Expect preliminary report
in a separate thread.  Is compiling cvs with gcc on Windows appealing to you?

> I am currently building CVS for Derek on a nightly basis.  This allows him
> (and any CVS developer) to be aware of how his changes affect the build for
> Windows users.  This was prompted by the fact that I have often had trouble
> building CVS on Windows because the Windows side of things does not get the
> same attention with regard to buildability and testing that Unix builds do.
> This awareness now significantly benefits not only CVS developers, but
> anyone who wants to be able to build CVS on the Windows platform.

Thank you.  I'll certainly benefit from this.

> Other than those few reasons, I have no REAL stake in CVS Windows builds.
> And again, I don't think I really care if the *.dsp, *.dsw, and *.mak files
> are in VC6 format, as it appears that VC5 (which is the only version I have)
> is currently still able to build CVS using the newer version of the files.
> If, at some point, VC5 is unable to build CVS, then I will either have to
> upgrade my version of VC++, or search the Internet for an official (or even
> unofficial) build of CVS when I want to get the update.

Thank you and I'll keep this all in mind.

> Does this adequately answered your questions?

Yes it has.  I'm very grateful for your generosity with your time.

> - Dennis

Thanks again,

Conrad