tech-pkg archive


Re: boost, BOOST_HAS_VARIADIC_TMPL and std=c++0x

On 11/2/11 11:13 AM, Anthony Mallet wrote:

Thanks for you answer.

On Wednesday, at 10:22, Julio Merino wrote:
| Other libraries (not Boost) solve this problem by providing a pkg-config
| file that stores the necessary flags that users of the library must use.
|   Maybe Boost.Build already provides this functionality and you should
| just be using it; I don't know.

Yeah, a pkg-config or similar would be cleaner. The sofware I try to compile is
not really mine and it already uses cmake for the build, so changing to is not really an option.

I see. Is the software being built as a pkgsrc package? If so, we could do some tricks in the boost file to pass around the right compilation flags.

| The other alternative is to NOT run autoconf in our packages and rely on
| Boost.Config.  This has caused problems in the past, and I'm afraid it
| will open the door to many other problems though: for example, consider
| boost-libs.  If you are linking against installed binary libraries that
| were compiled with -std=c++0x and you don't use this flag in your
| build... there may be problems.  (The same applies to any of the other
| automatically detected features; -std=c++0x is just the example at hand.)

I definitely agree with you when you say that mixing different compilers is
probably wrong. Yet, the user.hpp file found on the linux box that I have
access to are not setup like this (i.e. they don't define BOOST_NO_CONFIG and
rely on runtime detection). So I don't know how it works for linux (and I will
never claim that Linux is a reference :), but it _seems_ to work (maybe that's
just an illusion :)

Well, the problem is that Boost.Config relies on "static assumptions" that, over time, have proven to be not really that portable to "obscure" Unix platforms (NetBSD being one of them) and hardware platforms (again, NetBSD being a good example due to the wide hardware support). In particular, I recall several issues in NetBSD and, at the time, were "easily" fixed by switching to the autoconf alternative.

Maybe it's time to revisit the decision of using autoconf. Boost.Config clearly works in other platforms and should be doing the right thing already... maybe what we ought to do is cope with any problems that arise in Boost.Config and fix them in the library instead of working them around by using the autoconf approach. Maybe the answer to this is just to provide build slaves for the Boost testing system that run on multiple NetBSD variants; this way, they'd have data on their dashboards (1).

That said, doing the change is tricky.

So I don't know. Maybe the boost-* packages could just define a c++0x option,
so that you install boost with enabled/disabled support for c++0x ?

I don't think this is a good idea. Why would you ever want to enable this option if the package built without it would work in all cases, and be "more compatible"?


Home | Main Index | Thread Index | Old Index