All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Benjamin <mbenjamin@redhat.com>
To: Jesse Williamson <jwilliamson@suse.com>
Cc: "Adam C. Emerson" <aemerson@redhat.com>,
	Sage Weil <sage@newdream.net>,
	Allen Samuels <Allen.Samuels@sandisk.com>,
	Ken Dreyer <kdreyer@redhat.com>, Haomai Wang <haomai@xsky.com>,
	ceph-devel@vger.kernel.org
Subject: Re: building boost statically
Date: Mon, 2 May 2016 21:14:35 -0400 (EDT)	[thread overview]
Message-ID: <2047671033.23980927.1462238075772.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.20.1605021757210.21305@ancalagon.suse.com>

Hi Jesse,

----- Original Message -----
> From: "Jesse Williamson" <jwilliamson@suse.com>
> To: "Matt Benjamin" <mbenjamin@redhat.com>
> Cc: "Adam C. Emerson" <aemerson@redhat.com>, "Sage Weil" <sage@newdream.net>, "Allen Samuels"
> <Allen.Samuels@sandisk.com>, "Ken Dreyer" <kdreyer@redhat.com>, "Haomai Wang" <haomai@xsky.com>,
> ceph-devel@vger.kernel.org
> Sent: Monday, May 2, 2016 9:01:44 PM
> Subject: Re: building boost statically
> 
> On Mon, 2 May 2016, Matt Benjamin wrote:
> 
> So, just a quick update here: I used bcp to extract boost containers. This
> works nicely, but you end up with 1628 files. It's doing what it's
> /supposed/ to do, since part of the purpose is to provide all the
> dependencies (for example, Boost::MPL is used), but that seems like maybe
> not what we want to do.

Yes.  I experimented with this, but it didn't seem at all compact enough to be preferable to just building boost.  The latter, building just what Ceph uses from boost now, took less than a minute on a single core (i7).

> 
> Just using the boost/container headers is also possible, at a bit of risk
> that if we try to build on a system where one of the dependencies is
> incompatible in some way, Ceph won't build (perhaps a fairly low risk, but
> I'm throwing it out there). If that risk is acceptable, then we wouldn't
> have a large set of headers, but in effect would still be shipping our own
> little mini-fork.

I experimented with this also.  What I found was that the number of boost internal (including unexposed) dependencies is much larger than container.  This is a marvel of efficiency for the boost library internally, but isn't helpful for extracting a single like small_vector.  In particular, conflicts with an installed boost are many.

> 
> CMake looks like it has a module that can help us, and the general
> direction during an IRC chat was that we should do this as part of the
> move to cmake, rather than fidding with autoconf.

That seems like a good idea.

Matt

> 
> -Jesse
> 
> > Just wanted to ++ this.
> >
> > Matt
> >
> > ----- Original Message -----
> >> From: "Adam C. Emerson" <aemerson@redhat.com>
> >> To: "Jesse Williamson" <jwilliamson@suse.com>
> >> Cc: "Sage Weil" <sage@newdream.net>, "Allen Samuels"
> >> <Allen.Samuels@sandisk.com>, "Ken Dreyer" <kdreyer@redhat.com>,
> >> "Haomai Wang" <haomai@xsky.com>, ceph-devel@vger.kernel.org
> >> Sent: Monday, May 2, 2016 12:14:50 PM
> >> Subject: Re: building boost statically
> >>
> >> On 02/05/2016, Jesse Williamson wrote:
> >>> I think that in the long run, rather than bundling or using bcp, it would
> >>> be
> >>> nice to have cmake/autoconf let you point to the boost version you'd like
> >>> to
> >>> use.
> >>
> >> If we could manage it, that would be my ideal world. Rather than
> >> making it A Submodule, say, if we could have cmake examine the system
> >> boost to see what version it is and, if the version is greater than or
> >> equal to the required version, just use it. Otherwise just fetch the
> >> required version and build against it statically.
> >>
> >> --
> >> Senior Software Engineer           Red Hat Storage, Ann Arbor, MI, US
> >> IRC: Aemerson@{RedHat, OFTC, Freenode}
> >> 0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C  7C12 80F7 544B 90ED BFB9
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>
> >
> > --
> > Matt Benjamin
> > Red Hat, Inc.
> > 315 West Huron Street, Suite 140A
> > Ann Arbor, Michigan 48103
> >
> > http://www.redhat.com/en/technologies/storage
> >
> > tel.  734-707-0660
> > fax.  734-769-8938
> > cel.  734-216-5309
> > --
> > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> 

-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309

  reply	other threads:[~2016-05-03  1:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-28 22:47 building boost statically Sage Weil
2016-04-28 22:56 ` Robin H. Johnson
2016-04-28 23:14   ` Sage Weil
2016-04-28 23:45     ` Matt Benjamin
2016-04-29  7:01     ` Piotr Dałek
2016-04-28 23:05 ` Yehuda Sadeh-Weinraub
2016-04-29  2:31 ` Haomai Wang
2016-04-29 22:55   ` Ken Dreyer
2016-04-30  1:43     ` Sage Weil
2016-04-30  3:24       ` Allen Samuels
2016-05-01 15:08         ` Jesse Williamson
2016-05-01 15:14           ` Sage Weil
2016-05-02  3:28             ` Adam C. Emerson
2016-05-02 16:09               ` Jesse Williamson
2016-05-02 16:14                 ` Adam C. Emerson
2016-05-02 16:18                   ` Jesse Williamson
2016-05-02 16:31                     ` Adam C. Emerson
2016-05-02 23:04                   ` Matt Benjamin
2016-05-03  1:01                     ` Jesse Williamson
2016-05-03  1:14                       ` Matt Benjamin [this message]
2016-05-03 16:28             ` Robert LeBlanc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2047671033.23980927.1462238075772.JavaMail.zimbra@redhat.com \
    --to=mbenjamin@redhat.com \
    --cc=Allen.Samuels@sandisk.com \
    --cc=aemerson@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=haomai@xsky.com \
    --cc=jwilliamson@suse.com \
    --cc=kdreyer@redhat.com \
    --cc=sage@newdream.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.