RE: implement workaround for header files

[Daily, Jeff A]

> -----Original Message-----
> From: address@hidden [mailto:autoconf-
> address@hidden On Behalf Of Peter Johansson
> Sent: Thursday, June 06, 2013 5:04 PM
> To: Autoconf Mailing List
> Subject: implement workaround for header files
> 
> Hi autoconfers,
> 
> I have the following case:
> 
> I maintain a library that uses boost heavily. Recently I learnt that
> <boost/exception_ptr.hpp> is broken with certain version of GCC (4.4.7 for
> example). I would like provide a workaround for users of the library (myself
> e.g.) so we won't even notice the breakage. I've implemented a compile test
> with AC_COMPILE_IFELSE that tests whether the compiler and
> 'exception_ptr.hpp' get along or not, but now I'm not sure what is the best
> way to use this test. If I wrote an application I would AC_DEFINE and whether
> depending on that define or not I could include a patched header file first.
> But since I'm writing a library and the problem is exposed in header files 
> that
> are installed I'm not sure what is the best way to accomplish that. I already
> have a 'public_config.h' with a subset of content in 'config.h', which is
> installed. Yet I'm not sure what is the best way to accomplish a good solution
> here. If I need to install a patched boost header file, it must be hidden away
> so people won't include it by mistake; otherwise I might get a mob after me
> rightfully.
> Anyone having experience with this kind of workaround? I looked at gnulib
> but it seems focused on workarounds for end applications and not installed
> headers, which is slightly different.
> 
> Thanks in advance.
> 
> Cheers,
> Peter

Peter,

I'm not an experienced boost user, but I am aware that much of boost is 
header-only libraries.  And it sounds like from your description above that 
your library installs headers which also include this potentially broken header 
<boost/exception_ptr.hpp>.  The community would need to chime in here, but for 
my projects I don't install the generated config.h or a subset public_config.h 
like you have done, but since you already have that capability it would 
probably be little effort for you to extend public_config.h with an AC_DEFINE 
of the result of your test and then include your public_config.h from the top 
of your installed headers.

As an alternative, doesn't GCC provide version preprocessor macros?
http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
You could test for the version of GCC that doesn't work with this header and 
then include your replacement instead.  Of course this will only work with GCC 
compilers and perhaps other non-GCC compilers which claim to accept the GNU C 
dialect, but those non-GCC compilers might not have the same problem and then 
the configure test would be the better way to go since you test for the feature 
rather than a GCC version.

__________________________________________________ 
Jeff Daily 
Scientist 
Pacific Northwest National Laboratory