<div dir="auto">It most definitely is not. I work on a cross platform software distro that includes many hundreds on libraries. There are 3 competing standards (4 if you include mingw-w64):<div dir="auto"><br></div><div dir="auto">lib prefix: ugly when the lib is already prefixed with lib.</div><div dir="auto">-static.lib suffix.</div><div dir="auto">.dll.lib vs .lib.</div><div dir="auto"><br></div><div dir="auto">The point is cmake has defaults for this and they work on other platforms, instead on Windows it ignores this and leaves the entire software development would to deal with it instead.</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, May 19, 2018, 8:43 PM Shoaib Meenai <<a href="mailto:smeenai@fb.com">smeenai@fb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-4794335993815982493WordSection1">
<p class="MsoNormal">The convention in MSVC-land seems to be to prefix (as well as suffix) static libraries with lib. E.g. the static CRT is libcmt.lib, the static VC runtime support library is libvcruntime.lib (whereas the import library for the dynamic equivalent
is vcruntime.lib), and so on. It isn't necessarily the greatest scheme, but it does provide some distinction, at least.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">CMake <<a href="mailto:cmake-bounces@cmake.org" target="_blank" rel="noreferrer">cmake-bounces@cmake.org</a>> on behalf of Ray Donnelly <<a href="mailto:mingw.android@gmail.com" target="_blank" rel="noreferrer">mingw.android@gmail.com</a>><br>
<b>Date: </b>Saturday, May 19, 2018 at 6:10 AM<br>
<b>To: </b>Elvis Stansvik <<a href="mailto:elvis.stansvik@orexplore.com" target="_blank" rel="noreferrer">elvis.stansvik@orexplore.com</a>><br>
<b>Cc: </b>CMake MailingList <<a href="mailto:cmake@cmake.org" target="_blank" rel="noreferrer">cmake@cmake.org</a>><br>
<b>Subject: </b>Re: [CMake] Approach to both shared and static lib (again, sorry)<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">And the situation is *far* worse on Windows where the extension for a dll import library is the same as for a static library because cmake refuses to try to move the needle on this awful 'defacto' decision with
respect to msvc when it is exactly the sort of thing cmake should strive to take the lead on creating this new standard here, in cooperation and discussion with Microsoft (though for pure cmake based things it can be done without that). .dll.lib vs .lib being
the obvious extensions here. <u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">FWIW mingw-w64 fixed this, and it was far from difficult. Here we use .dll.a and .a.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I appeal to the CMake moderators to consider the damage this situation causes to the genericness and hygiene of CMakeList.txt files.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Sat, May 19, 2018, 2:00 PM Elvis Stansvik <<a href="mailto:elvis.stansvik@orexplore.com" target="_blank" rel="noreferrer">elvis.stansvik@orexplore.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-left:.5in">I know this has been asked before, but I've never seen a really<br>
authoritative answer.<br>
<br>
Say I have a simple single-library project.<br>
<br>
The advise I've seen is to not pass SHARED or STATIC to the<br>
add_library(..), but instead let the user pass<br>
-DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either shared<br>
or static.<br>
<br>
That's fine, but leads to packagers having to do ugly things like e.g:<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__salsa.debian.org_hle_dlib_blob_master_debian_rules&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=R7JQmKVI2oxy-AIQVcBC-DX-dqlkBFk5kTCI222ecO8&e=" target="_blank" rel="noreferrer">
https://salsa.debian.org/hle/dlib/blob/master/debian/rules</a><br>
<br>
That is, do two separate configure/build/install, in order to get both<br>
a shared and static version. Note that the above was just an example.<br>
But many packagers do it like this.<br>
<br>
How can I make life easier for the packager?<br>
<br>
I could add a -DFOO_BUILD_SHARED_AND_STATIC_LIBS, and use two<br>
add_library(...), one with SHARED and one with STATIC, but the same<br>
input source files. I could give the two libraries different output<br>
filenames, as to not conflict on e.g. Windows (where I think the .lib<br>
import library containing symbols for the .dll would otherwise<br>
conflict with the static library .lib, or..?).<br>
<br>
To not have to repeat the list of sources, I could keep them in a<br>
variable. But that's not recommended in modern CMake AFAIK.<br>
<br>
I've also seen people add an object library, and then build the shared<br>
+ static lib from that.<br>
<br>
What are your thoughts on all this? How do you go about it? Do you use<br>
the recommended way, with a single add_library(..) and just let<br>
packagers put up with having to do two builds?<br>
<br>
Thanks in advance!<br>
Elvis<br>
-- <br>
<br>
Powered by <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=V3mYr9Flf9Qf-Pq-_OovKbzrwVWhpIOrjcCHuYvbszk&e=" target="_blank" rel="noreferrer">
www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=sX26SQZVFYfGdhl4S0nVhXQDQ6eq_MhGXOy06ZAW9KQ&e=" target="_blank" rel="noreferrer">
http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=BWvA9Izw2G-XbRvZi9ptVgljjbJtkoRi_P7RuctYyTk&e=" target="_blank" rel="noreferrer">
http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=ouA_QmMRSZ16piM4G5xCtdJwt7Sz4fx_anknDStubYU&e=" target="_blank" rel="noreferrer">
http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=qR0yZSqjFyaVr1xJpwSmtk28b-sMXtWDoM_URvLQs7A&e=" target="_blank" rel="noreferrer">
http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=m2pcWM0TtqESkDz4KmjlV9a1VwfRPD2XaiR3Motzbxg&e=" target="_blank" rel="noreferrer">
http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=bmBNxLvBJFPYO0Kd1_VsRIXq2zQXfPQBW72q5lBMPlo&s=_fvbzMfoMh-elt7ju2Fetz2OTx7Z4TmCHGf7D6C4htE&e=" target="_blank" rel="noreferrer">https://cmake.org/mailman/listinfo/cmake</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</blockquote></div>