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

Reply via email to