-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Dennis,
You are correct that support for the windows-based client of CVS has
been neglected. I personally do not have any way to compile it. I only
see the compilation errors being sent to the cvs-test-results list.
If I see something that I think I can fix, I try to do it.
Someone who has the Visual C Studio 6 probably needs to see that these
files are properly updated:
cvsnt.dep
cvsnt.dsp
diff\libdiff.dep
diff\libdiff.dsp
lib\libcvs.dep
lib\libcvs.dsp
windows-NT\SCC\SCC.dsp
A number of files have recently been added to the lib directory as
imported from GNULIB that are not handled in those files.
Someone who knows the windows target will also need to see that the
config.h.in.in file is updated with reasonable answers for these
macros:
HAVE_ISWCNTRL
HAVE_LCHMOD
HAVE_PIPE
HAVE_PTHREAD_MUTEX_RECURSIVE
HAVE_PTHREAD_RWLOCK
PTHREAD_IN_USE_DETECTION_HARD
USE_POSIX_THREADS
USE_POSIX_THREADS_WEAK
USE_SOLARIS_THREADS
USE_SOLARIS_THREADS_WEAK
USE_WIN32_THREADS
I suspect that all but the last one should be left #undef, but I could
be wrong.
As to the regex_internal.h file, I am not sure that the file is
presently being used in the CVS project for the windows-client.
CVS does have an xtime.h file, but it appears that the version CVS is
using is not the GNULIB version. This probably needs to be investigated.
For now, I have installed Paul's suggested patch into the CVS
lib/stdint_.h and regenerated the windows-NT/stdint.h file as well.
In this way, either when Dennis Jones recompiles, or his nightly script
does the job, we might get more information about where the next
build-break occurs.
Thanks,
-- Mark
Dennis Jones <[EMAIL PROTECTED]> writes:
>
> ----- Original Message -----
> From: "Paul Eggert" <[EMAIL PROTECTED]>
> To: "Dennis Jones" <[EMAIL PROTECTED]>
> Cc: <bug-gnulib@gnu.org>; "Mark D. Baushke" <[EMAIL PROTECTED]>;
> <bug-cvs@nongnu.org>
> Sent: Monday, August 21, 2006 9:57 AM
> Subject: Re: GNULIB stdint_.h vs windows VC6 compiler
>
>
> > "Dennis Jones" <[EMAIL PROTECTED]> writes:
> >
> >> #if (LONG_MAX >> 31) >> 31 == 1
> >
> > It's not a good sign if the compiler can't handle binary operator
> > precedence; it suggests that other bugs are lurking in the
> > neighborhood.
> >
> > I assume that this would need to be done in two places? There are two
> > instances of that line in stdint_.h.
> >
> > Can you please explain the bug more generally?
>
> No, I cannot -- I don't use the Microsoft compiler. This would be a
> good question for Microsoft or one of the developers working on the
> Windows-based client (if there are any).
>
>
> > For example, why is
> > that change needed, but changes are not needed here?
> >
> > regex_internal.h:174:#elif BITSET_WORD_MAX >> 31 >> 5 == 1
> > regex_internal.h:176:#elif BITSET_WORD_MAX >> 31 >> 16 == 1
> > regex_internal.h:178:#elif BITSET_WORD_MAX >> 31 >> 28 == 1
> > regex_internal.h:180:#elif BITSET_WORD_MAX >> 31 >> 31 >> 1 == 1
> > regex_internal.h:182:#elif BITSET_WORD_MAX >> 31 >> 31 >> 9 == 1
> > regex_internal.h:184:#elif BITSET_WORD_MAX >> 31 >> 31 >> 31 >> 31
> > >> 3 == 1
> > regex_internal.h:186:#elif BITSET_WORD_MAX >> 31 >> 31 >> 31 >> 31
> > >> 31 >> 31 >> 31 >> 31 >> 7 == 1
> > regex_internal.h:188:#elif BITSET_WORD_MAX >> 31 >> 31 >> 31 >> 31
> > >> 31 >> 31 >> 31 >> 31 >> 7 > 1
> > xtime.h:34:# if LONG_MAX >> 31 >> 31 == 0
>
> No idea.
>
>
> > Does the following patch also fix the problem?
>
> If I applied the patch correctly, then yes, it does -- but other
> (unrelated?) errors then occur elsewhere. Thus, it seems clear that
> no one is actively maintaining the code for the Windows-based client,
> for it seems really messed up right now.
>
> - Dennis
>
>
>
>
> _______________________________________________
> Bug-cvs mailing list
> Bug-cvs@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/bug-cvs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (FreeBSD)
iD8DBQFE6gmQCg7APGsDnFERAsW+AKCuBEkO5imdzPJ5CYO2ZdfCg2H1swCgqs3t
ADCttibxEmuqbzG2yiqPdtA=
=G0rJ
-----END PGP SIGNATURE-----
