implement workaround for header files

[Peter Johansson]

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

[Daily, Jeff A]

-----Original Message-----
Sent: Thursday, June 06, 2013 5:04 PM
To: Autoconf Mailing List
Subject: implement workaround for header files
Hi autoconfers,
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

[Peter Johansson]

Post by Daily, Jeff A
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.

Hi Jeff,

Thanks for your input. Yes, I think I prefer to implement a compilation
test rather than try to set up some rules based on GCC versions and
Boost version (although I'm pretty sure problem only occurs for Boost
v1.41). Yet working out which versions of GCC are problematic seems tedious.

Thanks,
Peter

[Gavin Smith]

Post by Peter Johansson
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.

Do users of your library have to use what is declared in
<boost/exception_ptr.hpp>; equivalently, do they have to include this
file to use your library? If not, there wouldn't be a problem - the
source for your library could include an alternative header file, but
it wouldn't have to be installed - it is only needed when the library
itself is compiled.

[Peter Johansson]

Post by Gavin Smith
Do users of your library have to use what is declared in
<boost/exception_ptr.hpp>; equivalently, do they have to include this
file to use your library? If not, there wouldn't be a problem - the
source for your library could include an alternative header file, but
it wouldn't have to be installed - it is only needed when the library
itself is compiled.

Hi Gavin,

Yes, unfortunately the boost header file is included in an installed
header file. The functionality is not used by users directly though, but
inclusion is required because the Class holds a private 'boost::mutex'.
I could probably have changed that by hiding the members in a pimpl
pattern. But I've already implemented a fix that installs the patched
header files and uses the original header file if possible

http://dev.thep.lu.se/yat/changeset?reponame=&new=3045%40trunk%2Fyat%2Futility%2Fboost_exception_ptr.h&old=3044%40trunk%2Fyat%2Futility%2Fboost_exception_ptr.h

Cheers,
Peter