From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-24 01:18:13
On Monday 23 May 2005 19:57, Michael Stevens wrote:
> On Monday 23 May 2005 09:43, Marcel Loose wrote:
> > Hi Victor,
> > The "problem" is that I'm not doing active development on Boost. We are
> > using *some* Boost libraries in our project. Now I don't want to
> > "litter" our project environment (even with 3rd party software) with
> > code that we don't use. I'm among the group of people who believe that
> > "less is better"; or to paraphrase Stroustrup: "You don't pay for what
> > you don't use". That was the reason for me asking this question.
> Agreed stripping down the header files is occassionally useful. I ship
> source code that relies on Boost to a customer. The most important
> thing for me is to avoid any versioning problems. Therefore I ship my code
> with a stripped down set of necessary Boost headers.
> I have no automatic solution, but the manual approach is quick an
> effective. I simply deleted all the header files and directories that
> seemed obviously unrelated. Compilation then failed with a few header not
> found. I put these back step by step. Only took 5 minutes to complete the
> > Besides, IMHO it makes sense to provide an option to only install those
> > header files that you actually use. Why would you only provide an option
> > to install *some* object libraries, without providing the option to only
> > install the headers associated with those libraries?
> I think there are many barriers to implementing this successfully. From the
> C++ perspective as soon as you place files in a location so they can be
> found with #include then they have been "installed".
> I think what you are asking for is a list of header files that a library
> exports. There is no automatic way that BB can determine this. BB can
> determine what header files are required internally for a given build, but
> not which would be required externally.
> Therefore a librarys the Jamfiles would require further extension to list
> the exported headers. This would seem like a lot of complexity for little
> gain. I must admit however to feeling that the inclusion of install
> information into BBv2 has rather detracted from it's elligence for me. The
> level of support effort required to cover the multitude of installation
> scenarios seems to me to be disproportionate!
Can you clarify the above paragraph? In particular, the "elligence" word is
not known by http://www.m-w.com, so I can't understand the reminder either.
It sound like you're pointing out some problems, if that's the case I'd like
to understand what are they.
-- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build V2: http://boost.org/boost-build2
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk