monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] nvm.asio


From: Matthew Nicholson
Subject: Re: [Monotone-devel] nvm.asio
Date: Tue, 27 Jan 2009 19:34:49 -0600
User-agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)

Zack Weinberg wrote:
(this was meant to go to the list yesterday)

On Mon, Jan 26, 2009 at 8:30 AM, Markus Wanner <address@hidden> wrote:
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.

Hm, the last time I remember it coming up was at the face-to-face
conference back in 2007(?) and of course you weren't there.  Sorry.

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.

I was going to say that we would at least need the logic to generate
boost/config.hpp but it turns out that's all done with #ifdefs when
the thing is used, which is not completely crazy as it means you can
use one installation with many compilers.  However, I don't want to
count on it staying that way.

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.

If we use the system provided headers, then when there is a security
issue in boost, distributors only have to apply the patch to their
boost package and then recompile everything that depends on it, which
is highly automated.  If we bundle our own copy of boost headers, they
have to keep our package on a special list of additional places to
patch when there is a security issue in boost.

Let me restate my position a different way:  I think there are
significant advantages to shipping *none* of the libraries we depend
on: we make life easier for Linux-style binary distributors, who only
have to carry one copy of any given piece of source; we make life
easier for ourselves, as we do not have to watch for new releases of
the libraries and do the integration work; we don't have to carry
around any pieces of the libraries' configuration scripts in our own,
and we don't lose performance because we left that piece of the
configuration out to save hassle (e.g. for Botan's assembly
optimizations).

There are also different, significant advantages to shipping *all* of
the libraries we depend on (with the possible exception of zlib, which
is so stable and so ubiquitous that no one has ever had a problem to
date with our not shipping it): we control the exact version of each
library we use, so we're insulated from API churn; we can apply local
patches to fix problems that affect us, before new library versions
come out;  we make life easier for people building from source on
systems poor in libraries, e.g. windows.

Any point in between those extremes gets the downsides of both and
only some of the advantages of either.  In particular, we don't make
it significantly easier for people building from source unless we ship
all the packages, and we don't make it significantly easier for
distributors - or ourselves - unless we ship none.

I think there is a middle road, though.  Let .stripped become
mainline.  Then we revisit the .library-build branch, where we package
up exact copies of all the upstream libraries we depend upon, in
sibling directories to our own code.  We can then offer two tarballs -
the "thin" one with no upstream code, and the "fat" one that includes
everything and builds it all from source.

I think this is a great idea. I haven't looked at the library-build branch yet, but off the top of my head we could basically just use the build system of each library and make them install into a special staging dir, then build monotone against that statically linked.

--
Matthew Nicholson
matt-land.com




reply via email to

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