monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] nvm.asio


From: Markus Wanner
Subject: Re: [Monotone-devel] nvm.asio
Date: Mon, 26 Jan 2009 17:30:52 +0100
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

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.

Regards

Markus Wanner





reply via email to

[Prev in Thread] Current Thread [Next in Thread]