Hi,
Zack Weinberg wrote:
This has been proposed several times.
Sorry for bringing this up again, then. But I don't remember any such
discussion since using boost headers only.
There are technical reasons
(having mostly to do with the complexity and abnormality of boost's
build system) why it has never been done, but I do not think they are
insurmountable.
A build system? You don't need no build system for header files.
However, I am not a fan of this idea, because it would mean that we
would have to incorporate part of boost's build system somehow.
I'm proposing to add just the headers, no build system, nothing else.
We
just got done ripping out most of the bits of other libraries' build
systems that we had incorporated. My main motivation for going after
netxx is not to solve the problems associated with netxx itself
(although those are present in my mind) but because it would let us
kill off the remaining stuff in the configure script and Makefile
that's there for someone else's code's benefit rather than our own.
Adding those headers would allow us to rip out even more from the
autoconf stuff. Especially dropping a dependency which has posed
problems for many people on various platforms.
Also, packagers, in general, *want* to carry build dependencies on
their already-packaged libraries rather than rely on bundled versions.
Again, this is not about libraries, but only about header files. I
absolutely agree with you regarding libraries.
Also keep in mind, that we currently advice people to just download the
boost sources and use its header files. That certainly doesn't run them
through any build system either. Let alone a test suite. I fail to see
any disadvantage for including these headers, compared to this approach,
which seems rather silly to me.
Or put the other way around: what does using the system provided headers
buy us here? It's not like distributors gain anything by building
"against" system headers - unlike with libraries, where replacing the
library could fix security issues in monotone (as well) or some such.