[BuildTools] Removing config_xxx.h (specifically, config_coinutils.h)

[Stefan Vigerske]

Hi,

Lou Hafer wrote:
> Stefan,
>
>> It's also defines for system headers/libraries that should not always be
>> exposed.
>
> This isn't obvious for me. For example, the head of CoinFinite.hpp goes
> to a fair bit of trouble to find the right set of math header files,
> based on the platform. As a developer trying to write
> platform-independent code that's compatible with COIN, I appreciate that
> this work is already done and I don't have to reinvent it. Those folks
> sophisticated enough to want to make other choices are presumably also
> sophisticated enough to figure out how to undo the defaults.
>
> I refer back to the original complaint (Osi Ticket #88).

I thought it's all about BuildTools Ticket #76, but I'm willing to 
share... :-)

> The complaint
> is specifically about the PACKAGE_*. And, if you follow the link from
> the ticket to the autoconf mailing list, ignore the porn, and go to the
> first followup, it specifically mentions `custom naming your config.h
> file to <package>_config.h', and the use of #undef, which is essentially
> what we do.

I didn't find the porn ;-(.

> I'm getting less enthusiastic about this. True, the reply goes on to say
> that the best strategy is do design the public interface so it doesn't
> need this information. But if we can provide it, and the developer would
> need to duplicate it if we don't provide it, it seems to me kind of
> silly to remove it.

Apart from letting CoinFinite.hpp play the role of the header file that 
should be included to get the right math header files included, I see 
your point.
But I still feel reluctant to distribute information about the build 
system like which headers or libraries are available. For COIN-OR 
projects, most projects check for the header files they need anyway and 
do not rely on information in config_coinutils.h.
Thus, I would argue that the config.h file that is installed with a 
library should only include information useful for building against this 
library, i.e., version numbers or other information about the API.
If a developer needs additional information about math headers or things 
like that, then he should check for them by himself, even though it 
means some extra effort. But that way he'll be sure to get the 
information that really fits to his system (and not the system where the 
library he is using was build).

As example, consider a build of CoinUtils on a system where the zlib 
headers are installed, so HAVE_ZLIB is defined, but then someone uses 
this library on a system where only libz is available, but not its 
header files. Then having HAVE_ZLIB defined would be confusing.

Stefan