[ntp:hackers] Re: [Bug 659] libopts will not build on Windows

Danny Mayer mayer at ntp.isc.org
Fri Jul 28 17:46:07 UTC 2006


Bruce Korb wrote:
> Hi Danny,
> 
> Danny Mayer wrote:
>>> What I really need is:
>>>
>>> #ifdef CONFIG_H_WAS_GENERATED_BY_CONFIGURE_SCRIPT
>>>
>>> but I do usually type that out as:
>>>
>>> #ifdef HAVE_CONFIG_H
>>>
>>> since the configure script inserts that for me automatically.
>>> HAVE_CONFIG_H should *NOT* be defined for vanilla Windows.
>>
>> That's never true. Too much code would break if that were true.
> 
> Whose code?

Ours among others. 99% of our files include "config.h" at the start of
the file before including any other headers. It's not even conditional.

  In the autotools build world, "HAVE_CONFIG_H"
> means precisely that the file "config.h" is available and
> contains the results of the probes in the project's configure
> script.  If you did not run configure itself, that is okay
> but it still must contain all the correct answers that would
> normally be computed by the configure script.  If you are saying
> that it is okay to use a generic "config.h" that you have lying
> around for the platform, then you are wrong.  "config.h" is
> _always_ project specific.
> 

And this is true with what we have for windows. The only difference is
that it is not built with autoconfig which would be very difficult to do
on windows at least for Microsoft's compilers.

>>> If I blew it, I'll fix it.  "windows-config.h" should be included IFF:
>>>
>>> #if defined(_WIN32) && ! defined(HAVE_CONFIG_H)
>>
>> No, that's not true.
> 
> Yes, this is true.  If you have hand created a header specifically
> named "config.h" and gotten it in place and it answers all the
> project specific probes computed via the configure script, then
> (and only then) may you put ``-DHAVE_CONFIG_H'' on the command line.
> I do not believe you have done that.  Do not specify that.
> 

But it does do that and yet you decided not to allow it to be included
in libopts.

>> See above. You need to decide whether the windows
>> includes are in config.h or your windows-config.h so I can decide where
>> to put all of the changes needed to just build libopts.c. Right now my
>> preference is to put the specific stuff into windows-config.h so I don't
>> clutter up the config.h file with a lot of extra stuff just for libopts.
> 
> If you specify -DHAVE_CONFIG_H for libopts compilation, then you
> are claiming that you specifically have a file named "config.h"
> that answers libopts' needs.  Do not do that.  Here are your choices:
> 
> 1.  Include libopts probe results in your hand crafted config.h
>     and specify -DHAVE_CONFIG_H on the command line
> 

I have no idea what the libopts probes are, so one ends up guessing.
config.h contains information needed by the WHOLE project. Parts
specific to a module should go into it's own header. I don't want
libopts specific pieces in config.h if that's the only place it gets used.

> 2.  Include the necessary environment information in windows-config.h
>     and *NOT* specify -DHAVE_CONFIG_H on the command line
> 

Only for libopts? I don't think so.

> 3.  Set up a MingW (sp??) Windows build environment and actually run
>     the configure script for NTP.  It will automatically produce a
>     "config.h" header.  The Makefile-s will also build with
>     -DHAVE_CONFIG_H on the command line.
> 

I'm not aware of anyone building NTP using MingW at this time and I
don't want to get involved in yet another architectural setup.

> If libopts is compiled with -DHAVE_CONFIG_H and libopts probe results
> are not in that header, the build will break.  I do not understand
> why a different result would be expected.
> 

config.h is for NTP. put in windows-config.h for libopts. It can always
include config.h if necessary, but don't force us to include things that
only libopts needs.

>>> If "HAVE_CONFIG_H" has been defined and "_WIN32" is defined, then
>>> I would expect to be running under CygWin.
> 
> (or MingW).
> 
>> That's definitely not true and will never be true. If you are looking
>> for Cywin use the __CYGWIN__ to check for that and nothing else.
> 
> __CYGWIN is not defined for MingW.  It is specific to one particular
> POSIX-for-Windows compatibility environment.  I am looking for the
> results of the configure script probing.  -DHAVE_CONFIG_H says
> *specifically* that it is available.  -UHAVE_CONFIG_H says the
> results are not available.  In that case, I am willing to use
> the indicator ``#ifdef _WIN32'' to say I should include "windows-config.h".
> 

But everything should be set up in windows-config.h in a windows
environment so that all these different possibilities can be handled there.

>> The functions defined in snprintf.c cannot be used on Windows as they
>> already have their own functions in the library. Because of the way
>> these functions are defined on Windows you can never redefine them in
>> this way.
> 
> snprintf should only be pulled in if the HAVE_SNPRINTF macro is not
> defined.  "config.h" or "windows-config.h" should have it defined.
> The probe AC_CHECK_FUNCS(snprintf) should successfully probe for it
> on a CygWin/MingW platform.
> 

I think I ended up adding that to the list. There is no autoconfig for
Microsoft compilers so there is no probe.

Danny

> Cheers - Bruce
> 



More information about the hackers mailing list