Re: [boost] Some library dependency and auto liker issues

Subject: Re: [boost] Some library dependency and auto liker issues
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-08-20 15:55:55

Le 20/08/12 18:44, Andrey Semashev a écrit :
> On Monday 20 August 2012 18:20:50 Vicente J. Botet Escriba wrote:
>> Hi,
>>
>> there is an issue https://svn.boost.org/trac/boost/ticket/7045 that I
>> don't know how to fix.
>>
>> The problem is related to library dependencies and auto-linker.
>>
>> * 1st issue: Boost.Threads depends on Boost.DateTime but only for the
>> header only part. Anyway, it includes a DateTime file that includes the
>> boost/config/auto_link.hpp, and this makes the tools using the auto
>> linker to create a dependency on Boost.DateTime. As the Boost.Threads
>> build Jamfile doesn't link with Boost.DateTime, the command
>>
>> bjam toolset=msvc-11.0 --build-type=complete --with-thread
>>
>> doesn't build the library Boost.DateTime and so when a tool such as Visual
>> studio uses the auto linker information, it tries to link with
>> Boost.DateTime and not finds it, as not build (even if it is not needed).
>>
>> What is the best way to fix this?
>> Should Boost.Thread link with Boost.DateTime, even if it don't needs it?
>> Or just document that the user relaying on auto-linker needs to build
>> explicitly the boost_date_time library with the command:
>>
>> bjam toolset=msvc-11.0 --build-type=complete --with-thread --with-date_time
> I think Boost.Thread always depends on Boost.DateTime, at least on Windows. I
> see it includes Boost.DateTime in src/win32/thread.cpp.
Yes, but it uses only inline functions.
>
> I think, the dependency on Boost.DateTime should be in the Jamfile of
> Boost.Thread. This way the build system will know that Boost.DateTime should
> also be compiled when Boost.Thread builds.
An the dependency in on inline functions, I suspect that others than you 
will request that Boost.Thread don't link with Boost.DateTime. Note that 
currently, everything is OK without linking with.
>
>> * 2nd issue: Boost.Threads depends on Boost.Chrono and the library is linked
>> with boost_chrono. When a user includes for example <boost/thread/tss.hpp>
>> the autolinker doesn't detects the chrono dependency as this file don't
>> depends on any file in boost/chrono. But as boost_thread depends on
>> boost_chrono, the linker find some unresolved symbols.
> Does it?
Yes. At least when BOOST_THREAD_DONT_USE_CHRONO is not defined.
> I thought Boost.Chrono-related code in Boost.Thread was header-only.
No the dependent part uses system_clock::now() and steady_clock::now() 
indirectly.

> If so, the chrono-related part should probably be disabled by defining
> BOOST_THREAD_DONT_USE_CHRONO when Boost.Thread builds.
Unfortunately this should be possible only if Boost.Chrono is configured 
as header only, which is not the default.
>> What is the best way to fix this?
>> Should Boost.Thread include boost/chrono.hpp in all their public files even
>> if not needed other than by auto linker tools? Or just document that the
>> user relaying on auto-linker needs to include only the top level file
>> <boost/thread.hpp> so that all the dependencies are covered?
> Please don't do this. I had this problem with Boost.Log, which uses
> Boost.Thread but doesn't use Boost.Chrono. I don't want to introduce
> dependency on Boost.Chrono, so I explicitly disabled it when Boost.Log
> compiles. I would like to keep this dependency optional, if possible.
>
>
So you will admit a fix via documentation, isn't it?

Best,
Vicente