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 <[email protected]> wrote: > Zack Weinberg wrote: >> (this was meant to go to the list yesterday) >> >> On Mon, Jan 26, 2009 at 8:30 AM, Markus Wanner <[email protected]> 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 > _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
