Boost logo

Boost-Build :

From: Jurko Gospodnetić (jurko.gospodnetic_at_[hidden])
Date: 2008-08-30 20:21:25

   Hi Steven.

>>> I can't see why bjam install works from the boost root directory.
>>> Can anyone else see how /boost//install-headers is defined?
>>> I could only find /boost//install-proper-headers and
>>> /boost/some-lib//install-headers
> Solution: The targets created by boost_install are ignored by Jamroot.
>> Yes, I think you've found the problem. Replacing
>> /boost//install-headers with //boost-install-proper-headers in Jamroot
>> makes install in a library subproject work.
>> However, it doesn't appear to actually force the headers to install.
>> Does "explicit" override a dependency? Should it?
> Jamroot globs for headers in the current working directory.
> I'm attaching a patch that seems to work.

   Anyone played around with this patch yet? Anyone have something

   Here are some of my comments on it:

   * Rule boost-install() seems to have an echo call leftover from some
debugging/development effort.

   * What is the install-proper-headers target? Or more precisely, what
is the install-proper stage target and how does it relate to the install
stage target created in the boost-install() rule.

   * Not sure if your question 'where does the install-headers target
get created' is still an active one but as I see it it gets created in
the very same package.install() call that uses it.

   If this is a valid patch that actually does solve a real usability
problem with the Boost library's build, I'd hate to see it fall through
the cracks.

   I committed parts of the patch related to the tools/package.jam
module and that module truly did have an extra grist part in some of the
path properties passed to its underlying worker stage rules. Why & how
that ever worked I have no idea :-) but am too lazy to check right now.

   Changeset link:

   Best regards,
     Jurko Gospodnetić

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at