Re: [CMake] IMPORTED DLL-only Target on MSVC
> -Ursprüngliche Nachricht-
> Von: CMake [mailto:cmake-boun...@cmake.org] Im Auftrag von Marek
> Vojtko (Firaxis)
> Gesendet: Dienstag, 3. April 2018 23:24
> An: cmake@cmake.org
> Betreff: Re: [CMake] IMPORTED DLL-only Target on MSVC
>
> > > Is it not possible to wrap an external DLL-only library in an IMPORTED
> target?
> > >
> >
> > Yes it is.
> >
> > > I have an external dependency that is a single DLL (shared library)
> > > and a header file, but no LIB (static library) file.
> >
> > How does this work in Visual Studio C++? If I am not completely
> > mistaken you ALWAYS need a .lib file along with your .dll to link to
> > the shared library. And you Need a header with the API as well of course.
> >
> > The only case I know with .dll and without .lib file is when you have
> > managed
> > C++ or C# targets.
> >
>
> The DLL gets loaded using LoadLibrary("MyDependency.dll") at runtime and
> its functions are accessed through GetProcAddress():
Ok, I missed this case :-). But in my opinion MyDependency.dll is not a TARGET
in
the sense of CMake targets. It's just a variable/filename which is used in the
project
somewhere. This is actually also how Visual Studio treats the .dll: you only
pass
the filename somewhere, not mentioning "link to this" or something else.
If you want to deploy/copy the .dll to your binary directory I'd simply add a
POST_BUILD custom command which copies the file over so you don't have to
do it manually.
>
> HINSTANCE hLib = LoadLibrary(DLL_NAME);
> If(hLib)
> {
> typedef int (*DLL_FUNC)();
> myFunc = (DLL_FUNC)GetProcAddress(hLib, "DLLFunction"); }
>
> Like I said, it's an external dependency and I don't have any control over it.
> The dependency's include directories have to be added to my executable's
> include directories and I need to copy the DLL next to the executable. I
> thought I'd solve (at least the include directories) by creating an IMPORTED
> target, but no matter what I try, the DLL ends up in the linker command line,
> wreaking havoc.
Adding include directories/files only via target could be done by putting the
Include files in a INTERFACE library. Not sure if this is an elegant solution
for
your case but I'd probably start like this.
>
> Of course I can work around this issue by not creating an IMPORTED target
> and just relying on two variables (MyDependency_INCLUDE_DIR and
> MyDependency_SHARED_LIB). Before I do, however, I wanted to make sure
> that CMake does not in fact support a DLL-and-header-only library set up.
>
> Thanks,
> Marek
>
> --
>
> 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
--
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
Re: [CMake] IMPORTED DLL-only Target on MSVC
> > Is it not possible to wrap an external DLL-only library in an IMPORTED
> > target?
> >
>
> Yes it is.
>
> > I have an external dependency that is a single DLL (shared library) and a
> > header file, but no LIB (static library) file.
>
> How does this work in Visual Studio C++? If I am not completely mistaken you
> ALWAYS need a .lib file along with your .dll to link to the shared library.
> And you
> Need a header with the API as well of course.
>
> The only case I know with .dll and without .lib file is when you have managed
> C++ or C# targets.
>
The DLL gets loaded using LoadLibrary("MyDependency.dll") at runtime and its
functions are accessed through GetProcAddress():
HINSTANCE hLib = LoadLibrary(DLL_NAME);
If(hLib)
{
typedef int (*DLL_FUNC)();
myFunc = (DLL_FUNC)GetProcAddress(hLib, "DLLFunction");
}
Like I said, it's an external dependency and I don't have any control over it.
The dependency's include directories have to be added to my executable's
include directories and I need to copy the DLL next to the executable. I
thought I'd solve (at least the include directories) by creating an IMPORTED
target, but no matter what I try, the DLL ends up in the linker command line,
wreaking havoc.
Of course I can work around this issue by not creating an IMPORTED target and
just relying on two variables (MyDependency_INCLUDE_DIR and
MyDependency_SHARED_LIB). Before I do, however, I wanted to make sure that
CMake does not in fact support a DLL-and-header-only library set up.
Thanks,
Marek
--
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
Re: [CMake] CMake Version Specific Code and Testing
Ok cool thank you for explaining! Somewhat related, I really enjoy that I can build CMake 2.8.12 with CMake 3.10 :) -- 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
Re: [CMake] CMake Version Specific Code and Testing
> if I (accidentally, or through ignorance) write code that would only work in > CMake 3.x but not in 2.8.12, will the build fail or should I make sure to > install 2.8.12 and test using that? if I ended up using an entirely new > command that did not exist at the time of 2.8.12, but does exist in 3.10 of > my installed CMake, should the build fail or succeed? The in both cases if you have CMake 3.X installed the configure/generate of your project will succeed. You will need to install CMake 2.8.12 and test with that. > Policy logic You are correct about policy guards allowing older versions of CMake to safely ignore policies from new releases, while people running newer versions of CMake can leverage those ( generally the performance related policies ). On Tue, Apr 3, 2018 at 12:38 PM, Stephen McDowell wrote: > Hello, > > Suppose I have a cmake_minimum_required(VERSION 2.8.12) project I would like > to contribute to. > > So when I am testing code for a v2.8.12 project, but my installed CMake > version is say 3.10, if I (accidentally, or through ignorance) write code > that would only work in CMake 3.x but not in 2.8.12, will the build fail or > should I make sure to install 2.8.12 and test using that? > > For example, my understanding is that for things like policies, I can do > > if (POLICY CMP) > cmake_policy(SET CMP NEW) > endif() > > and this will mean that an older version of CMake running this code that > does not know about policy will still work. But if I ended up using an > entirely new command that did not exist at the time of 2.8.12, but does > exist in 3.10 of my installed CMake, should the build fail or succeed? > > Thanks for any guidance, I’m sorry if this question doesn’t make any sense… > > -Stephen > > > -- > > 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 > -- 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
Re: [CMake] cmake --find-package deprecated?
On 2018 M04 3, Tue 16:01:58 CEST jeandet wrote: > Hi all, > > Reading the documentation I can see: > https://cmake.org/cmake/help/v3.11/manual/cmake.1.html?highlight=find%2 > 0package#find-package-tool-mode id="-x-evo-selection-start-marker"> > " > Note > > This mode is not well-supported due to some technical limitations. It > is kept for compatibility but should not be used in new projects. > " > > Does this means that: > 1) We will always support this but it's limited. > 2) We will be supported for a long time, but you shouldn't use it. > 3) We plan to remove this soon, don't use this! I think it's in 2). > In fact this mode would really be useful outside of CMake, to use > libraries/stuff which doesn't provide pc files but only CMake packages. > Even if this has limitations, it's better than nothing. Yes, that was my motivation a few years back. There is even a cmake.m4 which adds a cmake_find_package macro for configure. Since then, there was close to no feedback. I also can't remember any volunteer contributions for this feature. Currently it has more limitations than it had 7 or 8 years ago or so. The idea was to run cmake in script mode, and basically just execute the requested FindFoo.cmake script, which basically searches a set of directories and returns the results. With imported targets, their link interfaces and e.g. generator expressions things got more complicated. I'd be happy if somebody picks up the work and makes this feature work properly. Alex -- 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
[CMake] CMake Version Specific Code and Testing
Hello, Suppose I have a cmake_minimum_required(VERSION 2.8.12) project I would like to contribute to. So when I am testing code for a v2.8.12 project, but my installed CMake version is say 3.10, if I (accidentally, or through ignorance) write code that would only work in CMake 3.x but not in 2.8.12, will the build fail or should I make sure to install 2.8.12 and test using that? For example, my understanding is that for things like policies, I can do if (POLICY CMP) cmake_policy(SET CMP NEW) endif() and this will mean that an older version of CMake running this code that does not know about policy will still work. But if I ended up using an entirely new command that did not exist at the time of 2.8.12, but does exist in 3.10 of my installed CMake, should the build fail or succeed? Thanks for any guidance, I’m sorry if this question doesn’t make any sense… -Stephen -- 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
[CMake] cmake --find-package deprecated?
Hi all, Reading the documentation I can see: https://cmake.org/cmake/help/v3.11/manual/cmake.1.html?highlight=find%2 0package#find-package-tool-mode id="-x-evo-selection-start-marker"> " Note This mode is not well-supported due to some technical limitations. It is kept for compatibility but should not be used in new projects. " Does this means that: 1) We will always support this but it's limited. 2) We will be supported for a long time, but you shouldn't use it. 3) We plan to remove this soon, don't use this! In fact this mode would really be useful outside of CMake, to use libraries/stuff which doesn't provide pc files but only CMake packages. Even if this has limitations, it's better than nothing. Best regards, Alexis.-- 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
Re: [CMake] [ANNOUNCE] CMake 3.11.0 available for download
You are correct this doesn't work with ninja and ExternalProjects due
to the jobserver work not being upstreamed. There are forks of ninja
that do have jobserver support and therefore this would work with
those.
On Fri, Mar 30, 2018 at 1:27 PM, Isaiah Norton wrote:
>> A "CMAKE_JOB_POOLS" variable was added specify a value to use for
>> the "JOB_POOLS" property. This enables control over build
>> parallelism with command line configuration parameters when using
>> the Ninja generator.
>
>
> Does this work with ExternalProject sub-builds? If not, I would suggest a
> big warning sign on the flag will save some headache...
>
> (my limited understanding of ninja's job pool implementation leads me to
> think not -- that would need jobserver support, the PR for which has
> languished. Would be very happy to learn otherwise!)
>
> On Wed, Mar 28, 2018 at 2:14 PM, Robert Maynard
> wrote:
>>
>> I am proud to announce that CMake 3.11.0 is now available for download at:
>> https://cmake.org/download/
>>
>> Documentation is available at:
>> https://cmake.org/cmake/help/v3.11
>>
>> Release notes appear below and are also published at
>> https://cmake.org/cmake/help/v3.11/release/3.11.html
>>
>> Some of the more significant changes in CMake 3.11 are:
>>
>> * The Makefile Generators and the "Ninja" generator learned to add
>> compiler launcher tools along with the compiler for the "Fortran"
>> language ("C", "CXX", and "CUDA" were supported previously). See the
>> "CMAKE__COMPILER_LAUNCHER" variable and
>> "_COMPILER_LAUNCHER" target property for details.
>>
>> * Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
>> "generator expression" in target-wide "COMPILE_DEFINITIONS",
>> "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See
>> generator expression documentation for caveats.
>>
>> * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE"
>> "generator expression" in target-wide "COMPILE_DEFINITIONS" and
>> "INCLUDE_DIRECTORIES". It previously supported only
>> "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
>> documentation for caveats.
>>
>> * "add_library()" and "add_executable()" commands can now be called
>> without any sources and will not complain as long as sources are
>> added later via the "target_sources()" command.
>>
>> * The "target_compile_definitions()" command learned to set the
>> "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.
>>
>> * The "target_compile_features()" command learned to set the
>> "INTERFACE_COMPILE_FEATURES" property on Imported Targets.
>>
>> * The "target_compile_options()" command learned to set the
>> "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.
>>
>> * The "target_include_directories()" command learned to set the
>> "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.
>>
>> * The "target_sources()" command learned to set the
>> "INTERFACE_SOURCES" property on Imported Targets.
>>
>> * The "target_link_libraries()" command learned to set the
>> "INTERFACE_LINK_LIBRARIES" property on Imported Targets.
>>
>> * The "COMPILE_DEFINITIONS" source file property learned to support
>> "generator expressions".
>>
>> * A "COMPILE_OPTIONS" source file property was added to manage list
>> of options to pass to the compiler.
>>
>> * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
>> parallel "moc" or "uic" processes to reduce the build time. A new
>> "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
>> property may be set to specify the number of parallel "moc" or "uic"
>> processes to start. The default is derived from the number of CPUs
>> on the host.
>>
>>
>> CMake 3.11 Release Notes
>>
>>
>> Changes made since CMake 3.10 include the following.
>>
>>
>> New Features
>>
>>
>>
>> Platforms
>> -
>>
>> * TI C/C++ compilers are now supported by the "Ninja" generator.
>>
>>
>> Generators
>> --
>>
>> * The "CodeBlocks" extra generator learned to check a
>> "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler
>> identification value to place in the project file.
>>
>> * The Makefile Generators and the "Ninja" generator learned to add
>> compiler launcher tools along with the compiler for the "Fortran"
>> language ("C", "CXX", and "CUDA" were supported previously). See the
>> "CMAKE__COMPILER_LAUNCHER" variable and
>> "_COMPILER_LAUNCHER" target property for details.
>>
>> * Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
>> "generator expression" in target-wide "COMPILE_DEFINITIONS",
>> "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)". See
>> generator expression documentation for caveats.
>>
>> * The "Xcode" generator learned to support the "COMPILE_LANGUAGE"
>> "generator expression" in target-wide "COMPILE_DEFINITIONS" and
>> "INCLUDE_DIRECTORIES". It previously supported only
>> "COMPILE_OP
Re: [CMake] IMPORTED DLL-only Target on MSVC
>From the CMake side of things yes, but MSVC requires an import library. You
>could use a tool such as Digital Mars' implib tool
>(https://digitalmars.com/ctg/implib.html), or use dumpbin to list all exports,
>put those in a .def file and use lib to create an import library from the def
>file. If I am not mistaken, CMake's GNUtoMS switch (for the Mingw Makefiles
>generator) does something like this automatically, so you could have a look at
>how it is done there. But I assume it's simply parsing the dumpbin /exports
>output to write a def file and running lib afterwards.
Regards,
Johannes
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5 | 64283 Darmstadt | Germany
Tel +49 6151 155-606 | Fax +49 6151 155-139
johannes.mueller-roe...@igd.fraunhofer.de | www.igd.fraunhofer.de
-Original Message-
From: CMake On Behalf Of Marek Vojtko (Firaxis)
Sent: Tuesday, April 3, 2018 00:49
To: cmake@cmake.org
Subject: [CMake] IMPORTED DLL-only Target on MSVC
Hi,
Is it not possible to wrap an external DLL-only library in an IMPORTED target?
I have an external dependency that is a single DLL (shared library) and a
header file, but no LIB (static library) file. When I create an IMPORTED target
and depend on it via target_link_libraries() I run into linkage issues, because
on MSVC CMake puts the DLL into the linker command (the "Input" text field in
the "Linker" settings of the Project Properties).
add_library( MyDependency::MyDependency MODULE IMPORTED )
set_target_properties( MyDependency::MyDependency
PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${MyDependency_INCLUDE_DIR}"
IMPORTED_LOCATION "${MyDependency_SHARED_LIB}"
)
[..]
add_executable( MyExecutable ... )
target_link_libraries( MyExecutable PRIVATE MyDependency::MyDependency )
I tried changing the library type in my add_library() call:
- STATIC obviously didn't work, because I don't have a .lib file and the .dll
file in IMPORTED_LOCATION was added to MyExecutable's linker line.
- SHARED did not work because CMake expects a .dll in IMPORTED_LOCATION and a
.lib in IMPORTED_IMP_LOCATION, so MyExecutable's linker line had a
MyDependency::MyDependency-NOTFOUND entry in it.
- MODULE seemed like the right choice when reading the documentation, but
MyExecutable's linker line still contains the .dll file specified in
IMPORTED_LOCATION.
What am I doing wrong?
Thanks,
Marek
--
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
--
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
