Sorry for garbage in previous response. I top posted partial response and bottom-posted more completed one.
Not easy to edit longish emails on mobile :) Mateusz Loskot, mate...@loskot.net (Sent from mobile) On Sun, 20 May 2018, 00:03 Mateusz Loskot, <mate...@loskot.net> wrote: > I understand your > > Mateusz Loskot, mate...@loskot.net > (Sent from mobile) > > On Sat, 19 May 2018, 22:54 Ray Donnelly, <mingw.andr...@gmail.com> wrote: > >> On Sat, May 19, 2018, 9:38 PM Mateusz Loskot <mate...@loskot.net> wrote: >> >>> On 19 May 2018 at 22:16, Ray Donnelly <mingw.andr...@gmail.com> wrote: >>> > On Sat, May 19, 2018, 8:50 PM Mateusz Loskot <mate...@loskot.net> >>> wrote: >>> >> On 19 May 2018 at 15:00, Elvis Stansvik <elvis.stans...@orexplore.com> >>> wrote: >>> >> > I know this has been asked before, but I've never seen a really >>> >> > authoritative answer. >>> >> > >>> >> > Say I have a simple single-library project. >>> >> > >>> >> > The advise I've seen is to not pass SHARED or STATIC to the >>> >> > add_library(..), but instead let the user pass >>> >> > -DBUILD_SHARED_LIBS:BOOL=ON/OFF to build the library as either >>> shared >>> >> > or static. >>> >> > >>> >> > That's fine, but leads to packagers having to do ugly things like >>> e.g: >>> >> > >>> >> > https://salsa.debian.org/hle/dlib/blob/master/debian/rules >>> >> > >>> >> > That is, do two separate configure/build/install, in order to get >>> both >>> >> > a shared and static version. >>> >> >>> >> IMHO, there is nothing ugly in this approach. >>> >> Not every system allows (or recomments) to generate both, >>> >> static and shared, from the same object files. >>> >> Why not view static vs shared as the similar to 32 vs 64 bit? >>> > >>> > >>> > Because they are different architectures that in many cases require >>> > different compilers and in some cases different host machines to run >>> on. >>> > Static vs shared has none of these issues to contend with. >>> >>> Both, static and shared may use quite different compilation/linking, >>> that is enough to treat them differently. >>> Apparently, my point hasn't made it through. Nevermind. >>> >> >> Yes of course they do but the tooling in and around cmake (including >> things like pkg-config and libtool) support this already. All I am pushing >> for is for parity between the main 3 OSes here so that users of cmake do >> not have to implement ugly hacks purely due to this. >> > > > I understand. I just have learned to live with lacking of such parity in > CMake. > Look, CMake does not event abstract such a basic thing as filesystem > case-sensitivity, for example > > find_package(protobuf) > vs > find_package(Protobuf) > > The former won't work on OS witch case-sensitive filesystem. > > > > Best regards, > Mateusz Loskot > > >
-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: https://cmake.org/mailman/listinfo/cmake
