Steven Watanabe wrote:
> Just a couple comments:
...
> * I'm not fond of the ROOT parameter for boost-install.boost-install.
> * Dependencies can be referenced with /boost/$(deps)//[stage|install]
> * You can find the full path to the boost-install.jam with
> [ path.root [ modules.binding $(__name__) ] [ path.pwd ] ]
> This avoids hard-coding the location of boost_install relative
> to the superproject.
Actually, [ modules.binding $(__name__) ] seems to return an absolute path,
so path.root/path.pwd may not be needed here? boostcpp.jam does
BOOST_ROOT = [ modules.binding $(__name__) ] ;
BOOST_ROOT = $(BOOST_ROOT:D) ;
which kind of implies that it relies on getting the absolute path.
> * That just leaves the stage directory, which is tied to the
> project root, and should perhaps be calculated in Jamroot
> instead of in boost_install.
The stage directory needs to be retrieved from boostcpp, but boostcpp just
sets it to "stage", which only works from top-level. It should probably use
$(BOOST_ROOT)/stage, and then other modules can peek for it.
There are other things that are needlessly replicated -
install-header-subdir, install-default-prefix. All of these need to be
peekable from a canonical location.
> * This seems to handle --layout=versioned, but I'm not clear on
> how well it handles --layout=system where we expect to use a
> single compiled library for all configurations.
It worked when I tried it. Note that you can have two libraries
with --layout=system, not just one; libfoo.a and foo.so.
> * Are the error messages that you get from CMake when there
> isn't a configuration that matches the request intelligible?
Not very. There's Boost_DEBUG, which tells you why something was skipped,
but ideally, it needs to detect the case when no variant matched, and _then_
tell you why things were skipped without your having to set Boost_DEBUG
beforehand. I haven't gotten that far yet; usability can be improved once we
have it working.
> It looks like the target will exist but will silently do nothing?
Yes, you get a link error.
> What if something goes wrong and there are multiple matches?
I haven't encountered this so far :-) although it's possible in principle
because at the moment I ignore some "non salient" properties.
> * If generate-cmake-config takes the library as a source,
> then it's possible to derive both the library dependencies
> and the exact library name from the library target. The
> dependencies can be found at the virtual target level in
> generate-cmake-config, and the exact file name will appear
> as the source in generate-cmake-config-. Doing it this way
> also has the side effect that the CMake configuration won't
> be installed if the library fails to build, which may be a
> good thing.
These may take me a while to figure out. :-)
