[ntp:hackers] Re: [Bug 659] libopts will not build on Windows
stenn at ntp.isc.org
Fri Jul 28 19:42:28 UTC 2006
I agree with Bruce.
> >>> 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.
That's because I removed the conditional inclusion bits because not
using config.h would result in an insanely large command-line compile
I also originally intended to use cygwin (or something similar like
mingw) for building ntp under windows (which would be able to run
Bruce> In the autotools build world, "HAVE_CONFIG_H"
Bruce> means precisely that the file "config.h" is available and
Bruce> contains the results of the probes in the project's configure
Bruce> script. If you did not run configure itself, that is okay
Bruce> but it still must contain all the correct answers that would
Bruce> normally be computed by the configure script. If you are saying
Bruce> that it is okay to use a generic "config.h" that you have lying
Bruce> around for the platform, then you are wrong. "config.h" is
Bruce> _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.
I'm not sure exactly what is being discussed here, but it is my
intention that the config.h we have checked in for the windows port be
the correct output "as if" configure was run on the wndows box.
I don't believe this is gonna work as well as Danny and folks say it
will, but if they are ready to handle things like "X doesn't work until
after MS-patch 1234 has been installed" then that's fine with me.
> But it does do that and yet you decided not to allow it to be included
> in libopts.
I'm a bit confused on the point you are making Danny. More below, perhaps.
>>> 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.
I think Danny probably wrote the above. config.h needs the #define
stuff. We now use libopts, so the windows-crafted config.h now needs to
contain that additional info.
>> 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.
Too bad. Bruce is right and while you may have a point on this in
general Danny, in this case that's not how it works, and we are in no
position to ask for anything else.
If we are going to use a windows-crafted config.h and supply
-DHAVE_CONFIG_H then it needs to include the information needed by
Note that when building the libopts code under windows we *can*
-UHAVE_CONFIG_H and supply the needed #define information some other
If you want a list of what has been added to config.h to support
libopts, compare a -stable config.h with a -dev config.h.
> > 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.
This was another choice. If you don't like it then don't use it.
> > 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.
In general, I'm not sure you'd have to be involved in it. I know
somebody is working on building ntp under cygwin, and I'm happy to work
with them on it. If somebody wants to build under mingw I'd work with
But Bruce's point is that one way to get a config.h that will close to
what you need for windows would be do run configure under mingw and use
that generated config.h file as the starting point.
> > 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.
libopts is used by ntp, and on every non-wondows platform the inclusion
of libopts means that config.h must now contain that new info.
Danny, who is the "us" being forced to include things that only libopts
>>>> 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.
Danny, you don't get to dictate decisions like that. I suspect you do
not have sufficient awareness of the problem space. I know I don't, and
having been involved with this stuff for a while I'm willing to grant
that the decisions that have been made here are the most generally
useful and consistent. In hindsight, better decisions could have been
made, but this is a very large beast now and it changes direction
>> __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
> But everything should be set up in windows-config.h in a windows
> environment so that all these different possibilities can be handled
No. Bruce is clearly right on this. Perhaps not in an idealized world,
but in the world we live in that has evolved as it did he is right.
>>> 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, in your first sentence there do you mean you added the
HAVE_SNPRINTF thing to the windows config.h? If so, that is good.
As for your 2nd sentence, why do you even mention that? Everybody knows
this and the whole point here is that the windows porting team needs to
get all of the new config.h bits into the config.h file that is crafted
More information about the hackers