[boost-build] building dependencies that use makefiles
I am using boost-build to build my project, but I have added a static library as a dependency that is built using GNU make. If I build this library manually, I can link it to my project in boost build using this simple Jamfile: lib hts : : <link>static <file>lib/lib.a : : <include>lib_headers ; Is there a way to tell boost-build to run make on the directory if the lib/lib.a is not present there? Thank you, Mauricio Carneiro, Ph.D. http://www.broadinstitute.org/~carneiro/
AMDG On 03/23/2014 11:24 AM, Mauricio Carneiro wrote:
I am using boost-build to build my project, but I have added a static library as a dependency that is built using GNU make. If I build this library manually, I can link it to my project in boost build using this simple Jamfile:
lib hts : : <link>static <file>lib/lib.a : : <include>lib_headers ;
Is there a way to tell boost-build to run make on the directory if the lib/lib.a is not present there?
You'll need a custom rule that runs make: path-constant make-dir : path/to/makefile/directory ; actions external-make { cd $(make-dir) && make } make lib.a : : @external-make : <location>directory/of/lib.a ; alias hts : lib.a : <link>static : : <include>lib_headers ; In Christ, Steven Watanabe
Steve,
thank you as always. This worked perfectly.
One quick follow-up question. This library depends on pthreads, and I had
been using the lib pthreads ; dependency and adding it to the sources list
of the library. It works perfectly with clang but fails with gcc 4.8.2. I
switched it to using <threading>multi and it still didn't work until I also
added <threading>multi to the application that is linking to it :
## Library
alias hts
: libhts.a z
: <link>static *<threading>multi*
:
: <include>htslib
;
## Application (boost-test)
run [ glob *.cpp ] /gamgee//gamgee /gamgee/libs//hts
boost_unit_test_framework
:
:
: <define>BOOST_ALL_DYN_LINK *<threading>multi*
: run ;
I thought that the application would learn from the library's dependency on
multi-threading and automatically turn it on, but it didn't. I tried moving
the <threading>multi to the requirements (together with the
<include>htslib) but that didn't do it either. Do you have any insights on
this?
Mauricio Carneiro, Ph.D.
http://www.broadinstitute.org/~carneiro/
On Sun, Mar 23, 2014 at 7:08 PM, Steven Watanabe
AMDG
On 03/23/2014 11:24 AM, Mauricio Carneiro wrote:
I am using boost-build to build my project, but I have added a static library as a dependency that is built using GNU make. If I build this library manually, I can link it to my project in boost build using this simple Jamfile:
lib hts : : <link>static <file>lib/lib.a : : <include>lib_headers ;
Is there a way to tell boost-build to run make on the directory if the lib/lib.a is not present there?
You'll need a custom rule that runs make:
path-constant make-dir : path/to/makefile/directory ; actions external-make { cd $(make-dir) && make }
make lib.a : : @external-make : <location>directory/of/lib.a ;
alias hts : lib.a : <link>static : : <include>lib_headers ;
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG On 03/24/2014 05:22 AM, Mauricio Carneiro wrote:
I thought that the application would learn from the library's dependency on multi-threading and automatically turn it on, but it didn't. I tried moving the <threading>multi to the requirements (together with the <include>htslib) but that didn't do it either. Do you have any insights on this?
You mean that you put <threading>multi in the /usage/ requirements? Only free features work in usage requirements. In theory, I'd like it to work for non-free features, but when features can propagate in both directions, figuring out what properties to use for a target is a nightmare. I'm not even sure that it would be a good idea if I could implement it, as I'm afraid that the surprises that it would cause might be worse than problems like yours. Anyway, the workaround is to use <threading>multi on your application, as you found. In Christ, Steven Watanabe
interesting, thank you again!
Mauricio Carneiro, Ph.D.
http://www.broadinstitute.org/~carneiro/
On Mon, Mar 24, 2014 at 11:40 AM, Steven Watanabe
AMDG
On 03/24/2014 05:22 AM, Mauricio Carneiro wrote:
I thought that the application would learn from the library's dependency
on
multi-threading and automatically turn it on, but it didn't. I tried moving the <threading>multi to the requirements (together with the <include>htslib) but that didn't do it either. Do you have any insights on this?
You mean that you put <threading>multi in the /usage/ requirements? Only free features work in usage requirements. In theory, I'd like it to work for non-free features, but when features can propagate in both directions, figuring out what properties to use for a target is a nightmare. I'm not even sure that it would be a good idea if I could implement it, as I'm afraid that the surprises that it would cause might be worse than problems like yours. Anyway, the workaround is to use <threading>multi on your application, as you found.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Mauricio Carneiro -
Steven Watanabe