<div class="gmail_quote">On Mon, Mar 2, 2009 at 9:39 PM, E. Wing <span dir="ltr">&lt;<a href="mailto:ewmailing@gmail.com">ewmailing@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><br>Also, one additional thing.  If you use Boost_LIBRARIES it will automatically contain all of the libraries you specify after the COMPONENTS line (including debug/optimized keywords).  This is often fine for many Boost use-cases.  If it&#39;s not and you must link individually, the way you were doing it should work fine, just make the components be UPPERCASE.<br>


</div></div></blockquote></div><div><br>So I am building a sub-library (currently static) of a larger project. This sub-library only needs the date_time library of the components I listed. I don&#39;t have a strong opinion either way of whether I link to just date_time or the whole thing; it&#39;s just that the original Makefile I&#39;m converting from singled this out. Do you feel that I&#39;m better off using Boost_LIBRARIES?</div>
</div></blockquote><div><br>If you&#39;re comfortable with maintaining the dependencies where they are needed I would recommend doing it the way you were planning on and use Boost_&lt;COMPONENT&gt;_LIBRARY, it also handles the debug/optimized links for Visual Studio.  I only mentioned Boost_LIBRARIES so you knew it existed and a partial theory as to why this documentation bug probably hasn&#39;t cropped up on the mailing list before.  There actually are a couple of good reasons not to use Boost_LIBRARIES (linking time would in theory be faster, if done correctly you would know at a glance which libraries of yours depend on which boost libraries).<br>
<br>That being said most people probably don&#39;t really care. :)<br><br></div></div>-- <br>Philip Lowman<br>