MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015539CMakeCMakepublic2015-04-29 06:272015-11-02 09:13
ReporterMathieu Malaterre 
Assigned To 
PrioritynormalSeveritytextReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake 3.1.2 
Target VersionCMake 3.3Fixed in VersionCMake 3.3 
Summary0015539: Clarify documentation of LIBRARY_OUTPUT_DIRECTORY for MODULE
DescriptionAs per documentation for LIBRARY_OUTPUT_DIRECTORY, we have:

$ cmake --help-property LIBRARY_OUTPUT_DIRECTORY
[...]
For DLL platforms the DLL part of a shared library is
treated as a runtime target and the corresponding import library
is treated as an archive target.
[...]

And

$ cmake --help-command add_library
[...]
  ``MODULE`` libraries are plugins that
are not linked into other targets but may be loaded dynamically at runtime
using dlopen-like functionality.
[...]

However using the following simple demo project:

$ cat foo.c
__declspec( dllexport ) int foo() { return 42; }
$ cat CMakeLists.txt
project(demo)

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/dll_part)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib_part)

add_library(foo_shared SHARED foo.c)
add_library(foo_module MODULE foo.c)


After compilation leads to:

$ find . -name \*.dll
./lib_part/foo_module.dll
./dll_part/foo_shared.dll

Which means:

1. Either MODULE is not a library since it's dll part is generated in `LIBRARY_OUTPUT_DIRECTORY`, which imply the documentation is inaccurate

2. Or MODULE is indeed a library, but there is a bug in cmake where the dll part of the library is generated in the `LIBRARY_OUTPUT_DIRECTORY` path.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-04-29 06:27Mathieu MalaterreNew Issue
2015-04-29 08:53Brad KingNote Added: 0038630
2015-04-29 08:55Mathieu MalaterreNote Added: 0038631
2015-04-29 09:52Brad KingNote Added: 0038632
2015-04-29 09:52Brad KingSeverityminor => text
2015-04-29 09:52Brad KingStatusnew => resolved
2015-04-29 09:52Brad KingResolutionopen => fixed
2015-04-29 09:52Brad KingFixed in Version => CMake 3.3
2015-04-29 09:52Brad KingTarget Version => CMake 3.3
2015-04-29 09:52Brad KingSummaryLIBRARY_OUTPUT_DIRECTORY for MODULE => Clarify documentation of LIBRARY_OUTPUT_DIRECTORY for MODULE
2015-04-29 10:05Mathieu MalaterreNote Added: 0038633
2015-04-29 10:10Brad KingNote Added: 0038634
2015-04-29 10:16Mathieu MalaterreNote Added: 0038635
2015-04-29 10:23Brad KingNote Added: 0038636
2015-04-29 10:28Mathieu MalaterreNote Added: 0038637
2015-04-29 11:18Brad KingNote Added: 0038638
2015-11-02 09:13Robert MaynardNote Added: 0039794
2015-11-02 09:13Robert MaynardStatusresolved => closed

Notes
(0038630)
Brad King   
2015-04-29 08:53   
This is working as intended so we at most need clarification in the documentation. It says "the DLL part of a /shared/ library is treated as a runtime target". A MODULE library is not a SHARED library.
(0038631)
Mathieu Malaterre   
2015-04-29 08:55   
In which case, please rephrase also:

``MODULE`` libraries are plugins

maybe:

``MODULE`` object files are plugins
(0038632)
Brad King   
2015-04-29 09:52   
The term "module library" is still meaningful because the loadable module still provides a library of symbols. It is just linked into the running process dynamically at runtime.

I've updated the documentation to clarify and add more detail:

 Help: Revise buildsystem artifact file type documentation
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef8835e5 [^]
(0038633)
Mathieu Malaterre   
2015-04-29 10:05   
IMHO, there is still a minor glitch with:

http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef8835e5#patch1 [^]

The section `Library Output Artifacts` is missing:

+* On DLL platforms: the import library file (e.g. ``.lib``) of a module
+ library target created by the :command:`add_library` command
+ with the ``MODULE`` option.
(0038634)
Brad King   
2015-04-29 10:10   
Re 0015539:0038633: CMake doesn't allow linking to MODULE libraries so we don't define behavior for their ``.lib`` import library files.
(0038635)
Mathieu Malaterre   
2015-04-29 10:16   
Point taken. However this is very different point that the original documentation issue. I'd still like to see it documented, some people may still want to customize the output destination and/or installation rules.
(0038636)
Brad King   
2015-04-29 10:23   
Re 0015539:0038635: If you want a .lib to install then you should use a SHARED library. They can be loaded as modules too. The whole point of MODULE is to say "don't link to this".
(0038637)
Mathieu Malaterre   
2015-04-29 10:28   
crystal clear
(0038638)
Brad King   
2015-04-29 11:18   
I revised the update to also mention that executables can produce ``.lib`` files when ENABLE_EXPORTS is set:

 Help: Revise buildsystem artifact file type documentation
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d401aa21 [^]
(0039794)
Robert Maynard   
2015-11-02 09:13   
Closing resolved issues that have not been updated in more than 4 months.