Re: [Boost-build] hardcode-dll-paths in shared lib

Subject: Re: [Boost-build] hardcode-dll-paths in shared lib
From: Ling Li (liling_at_[hidden])
Date: 2011-08-26 11:22:22

Sorry to revive such an old conversation.  I am having the same problem,
i.e., I have two shared libs A and B.  B links to A, and will be used as a
Python extension.

lib A
    : [ glob-tree *.cpp ]
    : :  <include>. <library>.//A
    ;

python-extension B  # in another Jamfile
    : B.cpp .//A
    : <hardcode-dll-paths>true  # <dll-path>.//A
    ;

However, <hardcode-dll-paths>true doesn't really work on a shared library
project, as that is disabled in boost-build/tools/builtin.jam:

        # Hardcode DLL paths only when linking executables.
        # Pros: do not need to relink libraries when installing.
        # Cons: "standalone" libraries (plugins, python extensions) can not
        # hardcode paths to dependent libraries.
        if [ $(property-set).get <hardcode-dll-paths> ] = true
            && [ type.is-derived $(self.target-types[1]) EXE ]

Although I understand the pros (of not needing to relink), I think this
should be a choice of the users.  In other words, Boost.Build shouldn't try
to be too smart here.  I think we should remove the restriction on type
being EXE.  (If that sounds too aggressive, maybe we should add a new
feature called hardcode-dll-paths-in-lib?)

Another question is: how can I manually hardcode the dll path of a dependent
project, like "<dll-path>.//A"?  I know it doesn't work that way, since .//A
will only give the path to the source, not the building directory (e.g.,
./bin/gcc-4.6.1/debug).

Thank you for your time.

--
View this message in context: http://boost.2283326.n4.nabble.com/hardcode-dll-paths-in-shared-lib-tp2688925p3771177.html
Sent from the Boost - Build mailing list archive at Nabble.com.