Re: [Cvs-dev] GNULIB update patch

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Hyslop <address@hidden> writes:

> [catching up on several portions of this thread]
> 
> Mark D. Baushke wrote:
> > Okay, I have added back the '#define HAVE_STDINT_H 1' which implies that
> > I should also possibly have a pathname to use for
> > 
> > #define FULL_PATH_STDINT_H </path/to/stdint.h>
> > 
> > in there as well...
> 
> I'm not sure that would be necessary. The windows-NT/config.h has 'undef
> FULL_PATH_STDINT_H' in it, but it compiles OK. I haven't run automake,
> though, so that might be a problem there.

The windows-NT/Makefile.am file has a /0/ replacement for HAVE_STDINT_H
right now even though the config.h has a '#define HAVE_STDINT_H 1' in it.

Part of this may be resolved if the GNULIB will avoid doing the
conditional include of <stdint.h> now that the stdint.m4 module should
generate one for us.

> > To be perfectly honest, I suspect that there is some other
> > problem with the HAVE_STDINT_H macro that Jim has not found yet.

> Well, I just updated to the latest trunk, and it builds and compiles
> OK.

Hmmm... I saw where the same was not true of one of the cvs-test-results
builds.

>  Or are you concerned about runtime problems? If that's the case, then
> it would simply be one more bug in the list of problems I'm discovering
> as I try to get sanity.sh to work with the MSVC build (for example, some
> of the diff tests fail because the more recent code uses unlink() to
> delete a read-only file - the Windows version of ulink() doesn't delete
> the file if it's read only).

Sigh. Yeah, we need to address those kinds of problems too.

> BTW, if HAVE_STDINT_H is not defined, then MSVC gives a lot of errors
> trying to compile lib/ files, because it has no declaration of intmax_t
> and uintmax_t.

Yes, I am trying to get that resolved with the GNULIB folks.

> Derek R. Price wrote:
> > Mark D. Baushke wrote:
> >
> >>>I should also possibly have a pathname to use for
> >>>
> >>>#define FULL_PATH_STDINT_H </path/to/stdint.h>
> >>>
> >>>in there as well...
> >
> >
> > Won't this be bad under Windows?  What happens if MSVC is installed to a
> > different directory (through user choice or a change of defaults in
> > different versions of the program)?  Does MSVC6 support the
> > #include_next directive?
> 
> The stdint.h that the Windows build uses does not come with Visual
> Studio, but is part of the CCVS source code in the windows-NT/
> directory. Does that help any?
> 
> No, Visual Studio 6 does not support #include_next.
> 
> > Also, I'm forwarding this question from Dennis Jones, who has been
> > running the nightly CVS builds under Windows.  He wants to know if we
> > are now requiring MSVC++ 6.0 (as opposed to 5.0).  I believe Conrad
> > was
> > rebuilding things with 5.0
> 
> Oh, I'd forgotten that. Yes, if Dennis can use VC6 that's probably
> better, since that's the version I've been using. I don't believe I've
> seen anything from Conrad for a while - am I correct in assuming his
> attention is focused elsewhere?
> 
> > Note that MS support for even MSVC
> > 6.0 ended September of last year
> > so it may be reasonable to discontinue support even for 6.0 ourselves.
> > Especially as it appears that MS now makes a version of MSVC++ 2005
> > (called MS Visual Studio 2005 Express Edition) available for free
> > download.  Of course, I have no idea what is necessary to compile CVS
> > under 2005 Express, if it is even possible.
> 
> I agree, it's time to let this fossil RIP if possible. I'll send a
> message to the bug-cvs list to see if anyone has any objections (or
> possibly has already done it!).

Good.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)

iD8DBQFEmFynCg7APGsDnFERAl20AKCdXtpcVWqIJFnb6uGjXaju9wZ86ACg2Cs3
OrL3o2LQwWzkgNh2BJNLenc=
=swhd
-----END PGP SIGNATURE-----