Wow, this thread has gone wild... To clarify my case: The prototype of each functions I want to export is prefixed by a MYPROJECT_EXTERNAL preprocessor constant. With Visual Studio, this constant is, by default, set to __declspec(dllimport). This way, I can link against the shared version of this library without having to define anything.
When compiling this library as a shared library, I have to define a MYPROJECT_EXPORT_SHARED constant, which will set MYPROJECT_EXTERNAL to __declspec(dllimport). But if I want to build/link against a static version of this library, I need to pass a MYPROJECT_STATIC as a define in order to set MYPROJECT_EXTERNAL to nothing. >From what I've read in your answers, it seems to be the way to go. My question was perhaps not clear. Compiling the library is not a problem, but from what I understood from Matthew first answer ("implicit compile flags [...] for imported tagets"), I was under the impression that I could get MYPROJECT_STATIC automatically defined when linking another program against a static version of my library (through its imported target). I've looked the documentation of target_compile_definitions, but it seems to be about compiling the library, not linking against its imported target. Am I right? 2013/10/31 David Cole <dlrd...@aol.com> > Microsoft believed in hidden by default for shared libraries. >> > > Don't say things like this: people will never hide anything ever again... > ;-) > > But seriously, making only those things public that are explicitly > exported has some major benefits: for one, it minimizes the probability of > clashes when combining multiple independent components. > > It really should be a software developer's rule of thumb / best practice > to have the minimal set of symbols necessary be exported. Anything exported > that does not need to be is a maintenance burden, a learning curve hurdle > for newbies, and increases the likelihood of name clashes with other > libraries: all bad things. > > So minimize your public APIs and your exports. > > > 2 cents worth, > > D > > -- > > 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: > http://www.cmake.org/mailman/listinfo/cmake >
-- 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: http://www.cmake.org/mailman/listinfo/cmake