> -----Original Message----- > From: autoconf-bounces+jeff.daily=pnl.gov@xxxxxxx [mailto:autoconf- > bounces+jeff.daily=pnl.gov@xxxxxxx] 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 _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
