Re: [Monotone-devel] nvm.asio

[Zack Weinberg]

Yes, that's exactly what I had in mind.  There's the beginnings of it
in the library-build branch, but making autoconf do what we need is
not straightforward.

On 1/27/09, Matthew Nicholson <address@hidden> wrote:
> 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
>