boost.thread causes autolink to boost.datetime
I see that much care went into Boost.Thread to make it header-only, but autolinking to Boost.DateTime kind of defeats the purpose. :-)
Jeff Garland wrote:
On Sun, Apr 20, 2008 at 9:32 AM, Peter Dimov <pdimov@pdimov.com> wrote:
I see that much care went into Boost.Thread to make it header-only, but autolinking to Boost.DateTime kind of defeats the purpose. :-)
99% of date time can be used inline.
Right, but does it always try to auto-link or only if you use the features that are in the separate library? John.
On Mon, Apr 21, 2008 at 6:05 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Jeff Garland wrote:
On Sun, Apr 20, 2008 at 9:32 AM, Peter Dimov <pdimov@pdimov.com> wrote:
I see that much care went into Boost.Thread to make it header-only, but autolinking to Boost.DateTime kind of defeats the purpose. :-)
99% of date time can be used inline.
Right, but does it always try to auto-link or only if you use the features that are in the separate library?
Well, I'm less certain of that -- it's a windows thing I don't use daily, butI believe it can be shut off undefining BOOST_DATE_TIME_DYN_LINK. If it's a serious problem, for 1.36 I'll just remove the date-time library for good -- it's really only there to support some legacy code now... Jeff
Jeff Garland wrote:
Right, but does it always try to auto-link or only if you use the features that are in the separate library?
Well, I'm less certain of that -- it's a windows thing I don't use daily, butI believe it can be shut off undefining BOOST_DATE_TIME_DYN_LINK. If it's a serious problem, for 1.36 I'll just remove the date-time library for good -- it's really only there to support some legacy code now...
I just had a quick try at fixing this: I refactored the headers so that only: date_generators.hpp greg_month.hpp greg_weekday.hpp try and auto-link. However, including <boost/thread.hpp> resulted in all of those headers being indirectly pulled in by date_time, so auto-linking still occurs :-( So I guess the question is whether this "legacy" code can be factored into separate headers that are only pulled in if you need them? Feels like the right thing to do if it's possible, but I don't understand date_time well enough to do it :-( HTH, John.
On Mon, Apr 21, 2008 at 10:28 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Jeff Garland wrote:
Right, but does it always try to auto-link or only if you use the features that are in the separate library?
Well, I'm less certain of that -- it's a windows thing I don't use daily, butI believe it can be shut off undefining BOOST_DATE_TIME_DYN_LINK. If it's a serious problem, for 1.36 I'll just remove the date-time library for good -- it's really only there to support some legacy code now...
I just had a quick try at fixing this: I refactored the headers so that only:
date_generators.hpp greg_month.hpp greg_weekday.hpp
try and auto-link.
However, including <boost/thread.hpp> resulted in all of those headers being indirectly pulled in by date_time, so auto-linking still occurs :-(
So I guess the question is whether this "legacy" code can be factored into separate headers that are only pulled in if you need them?
Feels like the right thing to do if it's possible, but I don't understand date_time well enough to do it :-(
I'm afraid it's a bit non-trivial in this case -- basically some of the i/o code that I wrote to support ancient compilers like 2.95 needs to be tossed and replaced with the more modern stuff that's already in the library -- that would allow all the to_string stuff to go inline. Jeff
participants (3)
-
Jeff Garland -
John Maddock -
Peter Dimov