Re: [CMake] MSVC /M[TD] as a compatible interface property?
Yeah, that issue with /MD and /MT is the reason every project I've seen
that deals with this problem uses something like this:
#
https://cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F
foreach(flag_var
CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO)
if(${flag_var} MATCHES "/MD")
string(REGEX REPLACE "/MD" "/MT" ${flag_var} "${${flag_var}}")
endif(${flag_var} MATCHES "/MD")
endforeach(flag_var)
Just appending also means that you cant just check if the compile flags
contain one or the other using string(FIND...)
/MD and /MT are by no means unique in being a compile flag that needs to be
the same between linked packages. I'd forgotten about
HAS_ITERATOR_DEBUGGING, but STL version also comes to mind (vs10 vs vs12,
libstdc++ vs libc++, ect)
On Thu, Jun 9, 2016 at 2:54 PM Daniel Schepler <
dschep...@scalable-networks.com> wrote:
> A while ago I did an experiment along the same lines, using something like
> this in CMake/MTflags.cmake. (What we really needed was forcing /MT
> /D_HAS_ITERATOR_DEBUGGING=0 even on debug builds, because we were using an
> external library only available in /MT format. So I might have
> accidentally broken it while adapting it here.)
>
> add_library(MTflags INTERFACE)
> target_compile_options(MTflags INTERFACE "/MT$<$:d>")
> set_property(TARGET MTflags
> PROPERTY INTERFACE_MSVC_MT ON)
> set_property(TARGET MTflags
> APPEND PROPERTY COMPATIBLE_INTERFACE_BOOL MSVC_MT)
>
> # Example usage:
> # include(MTflags)
> # add_library(A STATIC src1.cpp src2.cpp...)
> # target_link_libraries(A PUBLIC MTflags)
>
> That almost did what we wanted. The biggest problem (and the one annoying
> enough to make me abandon the experiment for the time being) was: if you
> configured using the "NMake Makefiles" generator, then the compiler would
> give a warning on each source file because the build system was passing
> both the default /MD[d] and the additional /MT.
> --
> Daniel Schepler
> --
> *From:* CMake [cmake-boun...@cmake.org] on behalf of Walter Gray [
> chrysal...@gmail.com]
> *Sent:* Thursday, June 09, 2016 1:58 PM
> *To:* Cmake Mailing List
> *Subject:* [CMake] MSVC /M[TD] as a compatible interface property?
>
> Setting /MT or /MD is pretty important, and is a transitive requirement.
> See: https://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx
>
> The standard mechanism of using target_compile_options isn't quite
> appropriate because it will simply append the flags used by each library
> and use the last one with no complaint if there is a mismatch.
>
> Example:
> A uses /MT, B uses /MD, C Depends on both.
> This will result in errors when compiling, but will configure just fine. I
> would like to make it so that if there is a mismatch between linked
> targets, cmake will either fail or issue a warning.
>
>
> https://cmake.org/cmake/help/v3.5/manual/cmake-buildsystem.7.html#compatible-interface-properties
> This seems to be meant to be used for exactly this type of thing, but
> because there is no specific property for specifying MSVC_RUNTIME, that
> system cannot be used in this case.
>
> Any thoughts on how to address this?
>
>
--
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://public.kitware.com/mailman/listinfo/cmake
[CMake] MSVC /M[TD] as a compatible interface property?
Setting /MT or /MD is pretty important, and is a transitive requirement. See: https://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.80).aspx The standard mechanism of using target_compile_options isn't quite appropriate because it will simply append the flags used by each library and use the last one with no complaint if there is a mismatch. Example: A uses /MT, B uses /MD, C Depends on both. This will result in errors when compiling, but will configure just fine. I would like to make it so that if there is a mismatch between linked targets, cmake will either fail or issue a warning. https://cmake.org/cmake/help/v3.5/manual/cmake-buildsystem.7.html#compatible-interface-properties This seems to be meant to be used for exactly this type of thing, but because there is no specific property for specifying MSVC_RUNTIME, that system cannot be used in this case. Any thoughts on how to address this? -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Calling find_package(self) for in-project builds
Very true, but adding the option of sometimes having the targets be aliases and sometimes having them be imported means that protobuf-module.cmake.in has to get much more complicated and means that we have to conditionally include protobuf-targets.cmake I'd like to minimize the differences between building the examples independently and building them as part of a combined build. On Thu, Jun 2, 2016 at 10:40 PM Konstantin Podsvirov < konstan...@podsvirov.pro> wrote: > Hello. > > 8:34, 3 june 2016 г., Walter Gray : > > Interesting idea, that could be possible. > > > Possible, but realy need? It can be alternative. Now we can use ALIASES > for build tree configuration - It's work (I check) > > On Thu, Jun 2, 2016 at 8:45 PM Dan Liew wrote: > > > What would be the suggested way to handle this? > > Couldn't you build the examples using CMake's ``ExternalProject`` > module [1] and have that build after the main project has finished > building? > > [1] https://cmake.org/cmake/help/v3.5/module/ExternalProject.html > > > > > -- > > 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://public.kitware.com/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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Calling find_package(self) for in-project builds
Interesting idea, that could be possible. On Thu, Jun 2, 2016 at 8:45 PM Dan Liew wrote: > > What would be the suggested way to handle this? > > Couldn't you build the examples using CMake's ``ExternalProject`` > module [1] and have that build after the main project has finished > building? > > [1] https://cmake.org/cmake/help/v3.5/module/ExternalProject.html > -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Calling find_package(self) for in-project builds
That only gets me part way - there's also the issue of the options & extra
functions defined in protobuf-config.in. My best guess ATM would be to do
something simmilar and create namespaced aliases, then just not include the
protobuf-targets.cmake file from protobuf-config.cmake if
CMAKE_CURRENT_LIST_DIR STREQUAL CMAKE_BINARY_DIR.
On Thu, Jun 2, 2016 at 6:16 PM Nicholas Braden
wrote:
> Although not ideal, you could alias the targets to the names they
> would have when imported with find_package() by using
> add_library(ALIAS), and then use if(TARGET) to conditionally call
> find_package(). This also is a step toward supporting using the
> library via add_subdirectory(), if that ever becomes a goal.
>
> On Thu, Jun 2, 2016 at 8:06 PM, Walter Gray wrote:
> > I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a
> bit
> > of a chicken and egg problem.
> >
> > There is an examples directory containing a CMakeLists.txt which we would
> > like to work as both a standalone examples directory and include as a sub
> > directory of the full build. For obvious reasons, the CMakeLists.txt file
> > contains a call to find_package(protobuf).
> >
> > I can call find_package(protobuf HINTS ${CMAKE_BINARY_DIR}) outside of
> the
> > examples/CMakeLists.txt file to ensure that we've already found the
> correct
> > version, but the problem is that the protobuf-config.cmake file includes
> the
> > export-generated file protobuf-targets.cmake, as well as implementing
> some
> > custom functions that we want to show off as part of the examples.
> >
> > The obvious solution to me was to use the export command to generate
> > protobuf-targets.cmake, but there are 2 problems. First, export(EXPORT)
> > doesn't create a file until generation time, but I can get around this
> using
> > export(TARGETS). The second is that, reading CMP0024, this appears to be
> not
> > garunted behavior, and actively discouraged.
> >
> > What would be the suggested way to handle this?
> >
> > --
> >
> > 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://public.kitware.com/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://public.kitware.com/mailman/listinfo/cmake
[CMake] Calling find_package(self) for in-project builds
I'm currently working on protobuf-3.0.0's cmake scripts, and I've hit a bit
of a chicken and egg problem.
There is an examples directory containing a CMakeLists.txt which we would
like to work as both a standalone examples directory and include as a sub
directory of the full build. For obvious reasons, the CMakeLists.txt file
contains a call to find_package(protobuf).
I can call find_package(protobuf HINTS ${CMAKE_BINARY_DIR}) outside of the
examples/CMakeLists.txt file to ensure that we've already found the correct
version, but the problem is that the protobuf-config.cmake file includes
the export-generated file protobuf-targets.cmake, as well as implementing
some custom functions that we want to show off as part of the examples.
The obvious solution to me was to use the export command to generate
protobuf-targets.cmake, but there are 2 problems. First, export(EXPORT)
doesn't create a file until generation time, but I can get around this
using export(TARGETS). The second is that, reading CMP0024, this appears to
be not garunted behavior, and actively discouraged.
What would be the suggested way to handle this?
--
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://public.kitware.com/mailman/listinfo/cmake
[CMake] Unit Testing for CMake Scripts
I was about to ask the list, but some googling lead me to this: https://github.com/polysquare/cmake-unit I am not the developer, but he doesn't appear to be on here so I thought I should share. This looks incredibly useful -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Cross Compilation & Source file generators
Nope, sorry. We build android from mac and windows too. And again, I'm more
concerned with how protobuf's config.cmake scripts should be set up to
easily enable users to deal with this problem. I'm trying to get their
build scripts up to date before 3.0.0 leaves beta.
On Tue, May 24, 2016 at 6:05 PM Dave Flogeras wrote:
> Another "outside the box" solution that I have had success with is as
> follows (Note this solution will only work with Linux):
>
> You can use the Linux binfmt_misc driver to execute non-native executables
> through an interpreter. If you google for qemu binfmt wrapper, you'll find
> various suitable approaches, but basically, you register a wrapper
> executable that calls binaries via qemu if the shell detects that it is of
> a specific type (namely ARM elf).
>
> After that, you can run the detected protoc "natively". Note this also
> has the side benefit of protoc will always match the version of the
> protobuf headers. I had earlier hacked my build system into finding my ARM
> installaed protobuf headers, but using the native protoc, but it complained
> because they weren't exactly the same version, which is unsupported under
> protobuf IIRC.
>
> Hope that helps,
> Dave
>
> On Tue, May 24, 2016 at 5:02 PM, Walter Gray wrote:
>
>> @Hendrik - Yes, unfortunately it didn't help me too much.
>> Superbuilds are not really an appropriate solution here - The project I'm
>> working on is too heavily down an alternative path, and I'm trying to set
>> up the exported .cmake files in the protobuf 3.0 beta to properly support
>> any sort of option.
>>
>> I suppose the question I should have asked is 'When setting up exported
>> package config files, what is the best way to handle the case where some
>> users will want to mix and match components based on platform?'.
>>
>> The concept of a protobuf_PROTOC override variable would certainly do the
>> job, but seems like a bit of a hack. I'd like to establish what the
>> canonical 'best practice' for solving this problem should be in a way that
>> supports using pre-built libraries.
>>
>> I'm thinking if I split the protobuf project's exports into 2 components,
>> one for the libraries and one for protoc, I can have clients call
>> find_package twice with different search paths and component lists, and add
>> some checks to reject a match if, for example, someone targeting arm tries
>> to link libraries compiled for mac.
>>
>> On Mon, May 23, 2016 at 5:17 AM David E DeMarle
>> wrote:
>>
>>> Just to clarify, although ParaView's superbuild assists you to set up
>>> and compile in either "compile TOOLS" or "CROSS compile" mode (or the
>>> default "HOST" mode) the protobuf inclusion I was speaking of in is found
>>> within paraview's source code and is not an external project.
>>> See ${PVSOURCE}/ThirdParty/protobuf
>>>
>>> hope that helps
>>>
>>> On Saturday, May 21, 2016, Craig Scott wrote:
>>>
>>>> There's also the technique described in this stack overflow
>>>> question/answer:
>>>>
>>>>
>>>> http://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run
>>>>
>>>> I'd probably recommend the superbuild approach used by Paraview though
>>>> if your build can be structured that way. With the superbuild approach,
>>>> it's a bit easier to tell what's going on. The method in the above link
>>>> would only be better if you really needed to keep everything in the one
>>>> single build.
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, May 21, 2016 at 11:10 PM, David E DeMarle <
>>>> dave.dema...@kitware.com> wrote:
>>>>
>>>>> Take a look at paraview's internal copy of protobuf. We compile protoc
>>>>> in the host tools pass and then use it when we build libprotobuf in the
>>>>> cross compile pass.
>>>>> On May 20, 2016 10:14 PM, "Walter Gray" wrote:
>>>>>
>>>>>> A small addendum - The way I am currently solving this problem is by
>>>>>> replacing the version of protoc in the library folder for android with
>>>>>> one
>>>>>> that works on the host machine, but this is really not the best since it
>>>>>> means that the library distribution is tied to the host AND the target.
[CMake] CMake "Core Guidelines"?
It occurs to me that, much like C++ itself, there are wide variety of ways to do things in CMake, many of which exist only for legacy compatibility, and the language had a lot of active develpment recently that allows much safer, easier to read programs. C++ now has the Core Guidelines and lots of example projects providing reference for what a good, modern project should look like, even providing automated tools for detecting when you're doing things in a way that is considered archatic, but all CMake has is a blog post and an old powerpoint slide. Seriously, these are the 2 top hits for 'Modern CMake'. Both are almost a year old, neither are in depth, and one references the other: https://rix0r.nl/blog/2015/08/13/cmake-guide/ http://www.slideshare.net/DanielPfeifer1/cmake-48475415 Is there some document that explains how modern cmake is meant to be used, or a particular repository that does so? -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Cross Compilation & Source file generators
@Hendrik - Yes, unfortunately it didn't help me too much.
Superbuilds are not really an appropriate solution here - The project I'm
working on is too heavily down an alternative path, and I'm trying to set
up the exported .cmake files in the protobuf 3.0 beta to properly support
any sort of option.
I suppose the question I should have asked is 'When setting up exported
package config files, what is the best way to handle the case where some
users will want to mix and match components based on platform?'.
The concept of a protobuf_PROTOC override variable would certainly do the
job, but seems like a bit of a hack. I'd like to establish what the
canonical 'best practice' for solving this problem should be in a way that
supports using pre-built libraries.
I'm thinking if I split the protobuf project's exports into 2 components,
one for the libraries and one for protoc, I can have clients call
find_package twice with different search paths and component lists, and add
some checks to reject a match if, for example, someone targeting arm tries
to link libraries compiled for mac.
On Mon, May 23, 2016 at 5:17 AM David E DeMarle
wrote:
> Just to clarify, although ParaView's superbuild assists you to set up and
> compile in either "compile TOOLS" or "CROSS compile" mode (or the default
> "HOST" mode) the protobuf inclusion I was speaking of in is found within
> paraview's source code and is not an external project.
> See ${PVSOURCE}/ThirdParty/protobuf
>
> hope that helps
>
> On Saturday, May 21, 2016, Craig Scott wrote:
>
>> There's also the technique described in this stack overflow
>> question/answer:
>>
>>
>> http://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run
>>
>> I'd probably recommend the superbuild approach used by Paraview though if
>> your build can be structured that way. With the superbuild approach, it's a
>> bit easier to tell what's going on. The method in the above link would only
>> be better if you really needed to keep everything in the one single build.
>>
>>
>>
>>
>> On Sat, May 21, 2016 at 11:10 PM, David E DeMarle <
>> dave.dema...@kitware.com> wrote:
>>
>>> Take a look at paraview's internal copy of protobuf. We compile protoc
>>> in the host tools pass and then use it when we build libprotobuf in the
>>> cross compile pass.
>>> On May 20, 2016 10:14 PM, "Walter Gray" wrote:
>>>
>>>> A small addendum - The way I am currently solving this problem is by
>>>> replacing the version of protoc in the library folder for android with one
>>>> that works on the host machine, but this is really not the best since it
>>>> means that the library distribution is tied to the host AND the target.
>>>>
>>>> Thinking in terms of concepts, I think I would want a find_package that
>>>> understood the difference between finding a package for executing and
>>>> finding a package for linking, but that'd be a pretty fundamental change.
>>>>
>>>> On Fri, May 20, 2016 at 7:02 PM Walter Gray
>>>> wrote:
>>>>
>>>>> I've got a project with a number of target platforms, including some
>>>>> that I have to cross-compile to such as android, that uses protobuf. If
>>>>> you're unfamiliar, the crux of the issue is that there is both a library,
>>>>> libprotobuf, and an 'compiler', protoc, that takes .proto files and
>>>>> generates a .h/.cc pair that are then included in the project.
>>>>>
>>>>> When cross compiling, want to use the libprotobuf that was compiled on
>>>>> andriod, but the protoc that was compiled for my host environment. How
>>>>> could this be achieved?
>>>>>
>>>>> Currently, my build machine has several different directories where I
>>>>> store the external libraries that have been compiled for the various
>>>>> platforms/compilers that we support (Libraries-arm32, Libraries-x64,
>>>>> Libraries-x64-vc14, ect).
>>>>>
>>>>> Solutions that require modifying protobuf's -config.cmake file are
>>>>> welcome, I've already submitted several PR's improving it. I'd like to
>>>>> establish what the best practice for this kind of situation is as I have
>>>>> the same issue with Flatbuffers.
>>>>>
>>>>> On a slightly unrelated note, is there s
Re: [CMake] Cross Compilation & Source file generators
A small addendum - The way I am currently solving this problem is by replacing the version of protoc in the library folder for android with one that works on the host machine, but this is really not the best since it means that the library distribution is tied to the host AND the target. Thinking in terms of concepts, I think I would want a find_package that understood the difference between finding a package for executing and finding a package for linking, but that'd be a pretty fundamental change. On Fri, May 20, 2016 at 7:02 PM Walter Gray wrote: > I've got a project with a number of target platforms, including some that > I have to cross-compile to such as android, that uses protobuf. If you're > unfamiliar, the crux of the issue is that there is both a library, > libprotobuf, and an 'compiler', protoc, that takes .proto files and > generates a .h/.cc pair that are then included in the project. > > When cross compiling, want to use the libprotobuf that was compiled on > andriod, but the protoc that was compiled for my host environment. How > could this be achieved? > > Currently, my build machine has several different directories where I > store the external libraries that have been compiled for the various > platforms/compilers that we support (Libraries-arm32, Libraries-x64, > Libraries-x64-vc14, ect). > > Solutions that require modifying protobuf's -config.cmake file are > welcome, I've already submitted several PR's improving it. I'd like to > establish what the best practice for this kind of situation is as I have > the same issue with Flatbuffers. > > On a slightly unrelated note, is there some way to write something like > the AUTOUIC system without modifying cmake itself? It would be lovely if > all I had to do was include the .proto file in the source file list. > > Thanks! > Walter > -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] Cross Compilation & Source file generators
I've got a project with a number of target platforms, including some that I have to cross-compile to such as android, that uses protobuf. If you're unfamiliar, the crux of the issue is that there is both a library, libprotobuf, and an 'compiler', protoc, that takes .proto files and generates a .h/.cc pair that are then included in the project. When cross compiling, want to use the libprotobuf that was compiled on andriod, but the protoc that was compiled for my host environment. How could this be achieved? Currently, my build machine has several different directories where I store the external libraries that have been compiled for the various platforms/compilers that we support (Libraries-arm32, Libraries-x64, Libraries-x64-vc14, ect). Solutions that require modifying protobuf's -config.cmake file are welcome, I've already submitted several PR's improving it. I'd like to establish what the best practice for this kind of situation is as I have the same issue with Flatbuffers. On a slightly unrelated note, is there some way to write something like the AUTOUIC system without modifying cmake itself? It would be lovely if all I had to do was include the .proto file in the source file list. Thanks! Walter -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] custom command usage requirements?
Hey All - I'm trying to add a custom command to some targets to copy files using a usage requirements kind of pattern, but I'm running into some limitations in CMake that seem somewhat arbitrary. To set the stage, imagine the following toy example: DirectoryA's CMakeLists File: include_directory(B) include_directory(C) DirectoryB's CMakeLists File: add_executable(TestEXE ...) target_link_libraries(TestEXE PUBLIC TestLibrary) #for each dependency of TestEXE add_custom_command(TARGET TestEXE POST_BUILD ...) #for each dependency of the dependency... DirectoryC's CMakeLists File: add_library(TestLibrary STATIC ...) find_packge(SharedLib REQUIRED) target_link_libraries(TestLibrary PUBLIC TestSharedLib::TestSharedLib) Somewhere in the SharedLib find module: add_library(TestSharedLib::TestSharedLib SHARED IMPORTED) #A library with a dll component that must be copied set_property(TARGET TestSharedLib::TestSharedLib PROPERTY IMPORTED_LOCATION path/to/my/library.dll) Things I tried: -Iterate over all the target's link libraries, and for every dependant shared library target, add a custom command to copy the dll. This failed because at the point of DirectoryB, it may be that there are dependencies (such as TestLibrary in the above example) which are not yet defined. One could impose a strict ordering requirement, but nothing else in CMake (AFIK) imposes such a requirement. -Add a resolve_dependencies() function call after each library is declared, or just once at the very end of the root cmakelists file. Using a global property, it keeps track of all exe targets which want dll's copied and traverses that list, adding copy commands to targets that depend on the newly declared library. Fails because you cannot call add_custom_command on a target outside of it's declaration file. Also crappy because it imposes a requirement on the user to call said function. -As above, but make the custom command reference a property on the target in a generator expression, then append any files that need copying to that property. So far the most workable, but the property cannot contain generator expressions which may present a problem. The core of the problem is that within the directory where the exe is defined, TestLibrary is unknown, and in DirectoryC or even DirectoryA, I cannot call add_custom_command on the TestEXE due to an arbitrary limitation cmake imposes (the target is defined, you can edit it, but you can't add commands to it. This means that I can't look up any property of TestLibrary to discover it's dependencies, and I can't find out that it depends on TestSharedLib, which references a .dll file I want to copy into TestEXE's TARGET_DIR. What I *can* do is make the TestEXE's custom command reference a property on TestEXE in a generator expression to get the list of dlls it depends on, but that property cannot itself contain any generator expressions (as would be ideal to deal with differing dlls for debug and release mode or the like). As it stands, I have something that kinda works, but feels kinda ugly. Any one of several different things would give me the functionality I need. In order of usefulness: 1) Allow recursive generator expression resolution: $ where MY_PROP=$<$:mything_d.dll>$<$:mything.dll>. I cannot tell you how many headaches this kind of functionality would save me and unless I'm very mistaken I don't think it would involve very much work. 2) Generic support for INTERFACE_* properties. Only kinda works, since you can't link with MODULE libraries, which contain .dll files I'd want to copy. Could be exposed by an extra argument in define_property() Definitely a crappier version of 1, since with 1 I could just append $ to MY_PROP on the original target. 3) Allow add_custom_command wherever the target is defined. If you can get and set properties on it, it seems weird that you can't do this. 4) Make custom commands inheritable as usage requirements. This would be very weird, but would get the job done. If anyone has any other ideas or feedback, it would be very welcome. I'd be very, very interested in seeing 1) make it into a future cmake release regardless though. -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] Copying shared libraries in a post-build step
Hey all,
I'm working on a module that will allow me to automatically copy all the
required .dll files as defined by well-formed import library targets to
the appropriate location (same folder for windows, Frameworks folder for
OSX bundle, ect). I've got the code that scans an executable's
INTERFACE_LINK_LIBRARIES property recursively to find all such shared
library, however I'm running into a small problem. I really like using
file globbing in higher level source directories to add all appropriate
sub-directories, but this means that sometimes a dependency will not be
fully defined yet. This is normally fine since these things are usually
resolved at *generation* time, but since I'm doing a manual traversal of
the list of link libraries at config time that's not really acceptable.
I realize I could just not do the globbing and just make sure the
directories were setup in the correct order, but I really don't like
making the add_subdirectory calls order dependent.
One solution I've come up with is to add the targets I want to do this
to to a global list, then iterate over that list as the last step in my
top-level cmake lists file, but that has the issue that I can no longer
use add_custom_command on those targets at that point. I'm wondering 3
things:
1)What is the reasoning behind not allowing add_custom_command on
targets not defined in the current directory? Especially now that SOURCE
can be modified, the restriction seems very arbitrary.
2)How stupid would it be to reserve the command using something like
add_custom_command(TARGET ${target} POST_BUILD COMMAND
$)
then use set_property(TARGET ${target} APPEND PROPERTY
COPY_SHARED_LIBS_COMMAND to add more copy steps to the command?
3) Am I completely missing something and there's already a totally well
supported way of making sure that an executable's shared library
dependencies end up in the correct directory? I couldn't find a really
satisfactory answer on stack overflow or the archives.
Thanks!
--
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://public.kitware.com/mailman/listinfo/cmake
[CMake] Including unquoted ENV ProgramFiles in PATHS makes find_* fail
I was working on a find module, and ran into some rather unpredicted behavior - it appears that including ENV ProgramFiles at the end the list of PATHS makes the search fail! Remove that line, put it first, or put it in quotes, and it works just fine. Does anyone have any clue why this might happen? For reference, here's the command and the value of ProgramFiles on my machine: ProgramFiles=C:\Program Files (x86) #Fails: find_path(wxWidgets_ROOT_DIR NAMES include/wx/wx.h PATHS "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\wxWidgets_is1;Inno Setup: App Path]" ENV ProgramFiles ) #Works: find_path(wxWidgets_ROOT_DIR NAMES include/wx/wx.h PATHS ENV ProgramFiles "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\wxWidgets_is1;Inno Setup: App Path]" ) #Works find_path(wxWidgets_ROOT_DIR NAMES include/wx/wx.h PATHS "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\wxWidgets_is1;Inno Setup: App Path]" "ENV ProgramFiles" ) -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] Possible bug install(EXPORT ...) and 'DIRECTORY .' & questions regarding Config file authoring
I've been trying to figure out how to correctly author install steps for
a library that will generate a self-contained folder that can be
distributed and used by others, including a good Config.cmake
file and I ran into what seems like a bug. If you say
install(EXPORT DESTINATION .)
Then the resulting file will, when generating the _IMPORT_PREFIX will
produce the following:
get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
Which for an install directory of C:\libraries\mypackage will produce an
import prefix of C:\libraries.
I can work around this for now by installing to the cmake subdirectory,
but I thought someone should be aware of this. Is this a known issue?
Also, what are the expected best practices regarding the authoring of
good Config.cmake files? The tutorial on
http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html#creating-packages
is somewhat lacking. For example, while it mentions that cmake does not
provide a way to register installed packages with the package registry,
it does say you can do this yourself. Is that the recommended thing to
do? If so, how? providing a .bat or .sh file in your distributed
folder's root that sets that up?
--
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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Is it possible for a dependee to use the dependency LINKER_FLAGS ?
Glen is correct. You should take a look at the docs for interface modules here: http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries I also put up some examples of how to do this on github a while back. https://github.com/wal-rus/cmake-modules Hope that helps! Also for future googling the concept is called Usage Requirements. On Aug 2, 2014 8:11 AM, "Glenn Coombs" wrote: > I think that you can use the target_link_libraries command to do this: > > add_library(A a.cpp) > target_link_libraries(A INTERFACE -custom-flags) > > -- > Glenn > > > > On 30 July 2014 16:51, Adrian M Negreanu wrote: > >> Hi, >> >> Is it possible to attach a property on a target, and that property >> to be used whenever the target is used ? >> >> ex: >> >> add_library(A a.cpp) >> somehow_attach_LINK_FLAGS(A "--custom-flags") >> >> # in a different directory >> add_executable(E e.cpp) >> target_link_libraries(E A) >> # ^--- this would do something similiar to >> set_target_properties(E PROPERTIES LINK_FLAGS "--custom-flags") >> >> For example, to use A:LINK_FLAGS >> >> Thanks >> >> -- >> >> 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://public.kitware.com/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://public.kitware.com/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://public.kitware.com/mailman/listinfo/cmake
[CMake] Defining a function in a macro
Hey List -
Just wanted to put this out there for posterity, and in case anyone runs
into the same question I had. I had a bunch of nearly identical
functions, so I wanted to write a function to define them for me to
reduce code repetition. The problem I ran into was that if you write
macro(_define_function name)
function(namespaced_${function_name} ...)
message(${ARGV} from ${name})
endfunction()
endmacro()
_define_function(foo)
namespaced_foo("Message")
you actually wind up printing "foo from foo", since all variable
references to a macro are expanded first. I also couldn't use a
function, since there would be no way to access ${name} from inside the
function (that I'm aware of - please correct me on this if I'm wrong)
The solution I came up with was, if I wanted to reference the function's
argv, I would do a double-dereference of a string containing "ARGV" like so:
macro(_define_function name)
function(namespaced_${function_name} ...)
set(my_argv ARGV)
message(${${my_argv}} from ${name})
endfunction()
endmacro()
This produced the correct results. If any of you know of a cleaner way
to do this, I'd love to hear about it. If not, have fun writing
functions to write your functions!
As a relatively useless, but I thought entertaining aside:
macro(_define_function name my_argv)
function(namespaced_${function_name} ...)
message(${my_argv} from ${name})
endfunction()
endmacro()
_define_function(foo "\${ARGV}")
namespaced_foo("Message")
The result is "foo Message from foo" because ${my_argv} gets expand to
${ARGV}, which then expands to "foo ${ARGV}".
Thanks!
--
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://public.kitware.com/mailman/listinfo/cmake
[CMake] An interface targets/usage requirements example with automatic shared library handling! Take a look!
Hey all, You may have seen my earlier posts, "find_package" and INTERFACE targets in 3.0" and "Target usage requirements for shared libraries". I've also seen Michael Darling's post "Package found - passing _INCLUDE_DIRS to include_directories() and _LIBRARIES to target_link_libraries()", so I'm assuming there's a fair bit of interest in this topic. After wrestling with it for about a week, I've got a solution that I think works very well, and demonstrates how to properly make use of INTERFACE and IMPORTED targets with the new Usage Requirements Paradigm. I've made a couple of helper functions for generating interface targets from the information exported by Find modules, as well as a couple of example find modules demonstrating their use with pure header, static, and shared libraries, and even one which uses a master INTERFACE target to control link library ordering. I've put the files up on github for you guys to take a look at. I would really appreciate any feedback you may have on how I could make it any clearer or further reduce code duplication between the find modules. https://github.com/wal-rus/cmake-modules -- 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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] find_package and INTERFACE targets in 3.0
Hendrick! That's exactly what I'm trying to do. Do you have an example
of the declaration of the dll import target setup you could share? That
would be immensely helpful.
Thanks
Walter
On 7/19/2014 4:01 AM, Hendrik Sattler wrote:
Hi,
for DLLs, the .lib part has it's own property IMPORTED_IMPLIB.
This is already the case for older versions of CMake but at least the Qt4 find
module makes no use of it.
In our own project, we use global imported targets with dll and import lib set
(and other properties like includes) and use it on Windows to copy the dlls to
the target location with a generator expression and post-build.
I guess on Windows, BundleUtilities could also be simplified if that was done
consistently.
On all platforms it's rather complicated to find out if a .lib/.so is static or
shared. IMHO this should be solved by a function that module writers can use,
either on a CMake module or integrated.
So currently, you can either guess or use UNKNOWN.
Regards,
HS
On 19. Juli 2014 05:13:13 MESZ, Walter Gray wrote:
Thanks Nils!
The examples in the git repo are particularly helpful. It seems that
in
all of the examples, the library type is being set to UNKNOWN. Is
there
a reason for this? It seems that STATIC would be more suitable for most
of those, though the wording in the docs for IMPORTED_LOCATION [1]
makes
it seem like maybe for STATIC's it's just the directory and not the
actual .lib file. I notice cmake doesn't seem to have any way to track
DLLs or dylibs. Is there some recommended way of dealing with
importing
shared libraries? The QT4 module was my best bet but it doesn't seem to
touch the .dlls at all. I tried writing some of my own for shared
libraries like SDL2, I noticed that add_libraries(SHARED IMPORTED) does
not seem to work as I expected. An example for Windows(from memory,
I'll update with the real run outputs on Monday when I'm back at the
office):
add_library(SDL2::SDL2 SHARED IMPORTED GLOBAL)
set_target_properties(SDL2::SDL2 PROPERTIES
INTERFACE_LINK_LIBRARIES
"${SDL_ROOT_DIR}/lib/SDL2main.lib";"${SDL_ROOT_DIR}/lib/SDL2.lib"
INTERFACE_INCLUDE_DIRECTORIES "${SDL_ROOT_DIR}/include"
IMPORTED_LOCATION "${SDL_ROOT_DIR}/lib/SDL2.dll"
)
According to the docs for IMPORTED_LOCATION [1], for shared libraries
on
DLL platforms, it should point to the DLL part of the library. When I
add the SDL2::SDL2 to my main target, it compiles & generates but when
I
run the resulting visual studio project it results in link errors with
(and this is the part I'm not sure about - again, more concrete detail
on Monday) SDL2-NOTFOUND.o and SDL2::SDL2
I suspect I'm using INTERFACE_LINK_LIBRARIES in not quite the right
way,
but those *are* the public .lib files. When I get back on Monday I'll
try a few different approaches based on what I saw in some of the
modules, namely making sub-libraries with UNKNOWN and IMPORTED_LOCATION
set for all the actual .lib files, and just directly setting
LINK_LIBRARIES
[1]
http://www.cmake.org/cmake/help/git-master/prop_tgt/IMPORTED_LOCATION.html
On 7/18/2014 5:23 AM, Nils Gladitz wrote:
On 07/18/2014 05:00 AM, Walter Gray wrote:
Hi list!
I'm a big fan of the new INTERFACE targets & target usage
requirements,
but none of the provided Find.cmake files seem to take
advantage of the new paradigm. Checking the wiki, the old
Find.cmake seem to be deprecated, with most of the
information
on authoring new packages assuming that you are the developer of the
module, not the consumer. What is the recommended way to deal with
packages that don't provide these config files? I'll happily write
my
own Find.cmake files, however that approach seems
deprecated
and I haven't found any good examples of find modules that define
IMPORT
or INTERFACE targets instead of the older method of setting a bunch
of
_xxx variables.
There are a few modules that use imported targets in 3.0 and a few
more were updated in master.
I see e.g. FindGLUT, FindQt4, FindGTK2, FindZLIB, FindOpenGL and
FindGLEW making use of imported targets in master[1].
[2] documents how to write find modules and includes an example with
IMPORTED targets.
Nils
[1]
http://cmake.org/gitweb?p=cmake.git;a=tree;f=Modules;h=5d17682cb231f119b677ce67d804852d3be6d46f;hb=HEAD
[2]
http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#find-modules
--
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
htt
Re: [CMake] Package found - passing _INCLUDE_DIRS to include_directories() and _LIBRARIES to target_link_libraries()
Unless I'm mistaken, it says that the *CONVENTION* is to call
include_directories(${_INCLUDE_DIRS}) manually, not that
it is done automatically. To get that kind of automatic include
directory adding you need to have an import or interface target with
INTERFACE_INCLUDE_DIRECTORIES defined by the find module, then link with
that. Take a look at topics related to Interface Libraries [1] and
writing modern find modules [2]
[1]
http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#interface-libraries
[2]
http://www.cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#find-modules
On 7/18/2014 7:31 PM, Michael Darling wrote:
http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries#How_package_finding_works
seems to indicate if _FOUND is found, the
_INCLUDE_DIRS is passed to the include_directories()
command, and _LIBRARIES is passed to target_link_libraries()
Why is the reduced-case code below calling g++ without including
"-I~/codeTestPackages/lib", causing a "app/app.cpp:1:17: fatal error:
lib.h: No such file or directory" ?
I'm on CMake v3.0.0. Also tried CMake v3.0.20140718-g36a81 (git source.)
All the source is below, and attached as a .tar.gz.
*### CMakeLists.txt ###*
cmake_minimum_required(VERSION 3.0)
project(codeTestPackages)
set(CMAKE_VERBOSE_MAKEFILE on)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ~/codeTestPackages/findModules)
add_subdirectory(lib)
add_subdirectory(app)
*### findModules/Findlib.cmake ###*
IF(NOT lib_FOUND)
set(lib_FOUND "yes")
message("lib_FOUND is ${lib_FOUND}")
set(lib_INCLUDE_DIRS ~/codeTestPackages/lib)
set(lib_LIBRARIES lib)
ENDIF(NOT lib_FOUND)
*### lib/CMakeListst.txt ###*
include_directories(~/codeTestPackages/lib)
add_library(lib lib.cpp)
*### lib/lib.h ###*
#ifndef __LIB__
#define __LIB__
namespace LIB {
unsigned long libFunc(unsigned long inValue);
}
#endif
*### lib/lib.cpp ###*
#include
namespace LIB {
unsigned long libFunc(unsigned long inValue) {
return inValue+1;
}
}
*### app/CMakeLists.txt ###*
find_package(lib REQUIRED)
add_executable(app app.cpp)
*### app/app.cpp ###*
#include
using namespace LIB;
int main() {
unsigned long x = 1;
unsigned long y = libFunc(x);
}
--
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://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] find_package and INTERFACE targets in 3.0
Thanks Nils!
The examples in the git repo are particularly helpful. It seems that in
all of the examples, the library type is being set to UNKNOWN. Is there
a reason for this? It seems that STATIC would be more suitable for most
of those, though the wording in the docs for IMPORTED_LOCATION [1] makes
it seem like maybe for STATIC's it's just the directory and not the
actual .lib file. I notice cmake doesn't seem to have any way to track
DLLs or dylibs. Is there some recommended way of dealing with importing
shared libraries? The QT4 module was my best bet but it doesn't seem to
touch the .dlls at all. I tried writing some of my own for shared
libraries like SDL2, I noticed that add_libraries(SHARED IMPORTED) does
not seem to work as I expected. An example for Windows(from memory,
I'll update with the real run outputs on Monday when I'm back at the
office):
add_library(SDL2::SDL2 SHARED IMPORTED GLOBAL)
set_target_properties(SDL2::SDL2 PROPERTIES
INTERFACE_LINK_LIBRARIES
"${SDL_ROOT_DIR}/lib/SDL2main.lib";"${SDL_ROOT_DIR}/lib/SDL2.lib"
INTERFACE_INCLUDE_DIRECTORIES "${SDL_ROOT_DIR}/include"
IMPORTED_LOCATION "${SDL_ROOT_DIR}/lib/SDL2.dll"
)
According to the docs for IMPORTED_LOCATION [1], for shared libraries on
DLL platforms, it should point to the DLL part of the library. When I
add the SDL2::SDL2 to my main target, it compiles & generates but when I
run the resulting visual studio project it results in link errors with
(and this is the part I'm not sure about - again, more concrete detail
on Monday) SDL2-NOTFOUND.o and SDL2::SDL2
I suspect I'm using INTERFACE_LINK_LIBRARIES in not quite the right way,
but those *are* the public .lib files. When I get back on Monday I'll
try a few different approaches based on what I saw in some of the
modules, namely making sub-libraries with UNKNOWN and IMPORTED_LOCATION
set for all the actual .lib files, and just directly setting LINK_LIBRARIES
[1]
http://www.cmake.org/cmake/help/git-master/prop_tgt/IMPORTED_LOCATION.html
On 7/18/2014 5:23 AM, Nils Gladitz wrote:
On 07/18/2014 05:00 AM, Walter Gray wrote:
Hi list!
I'm a big fan of the new INTERFACE targets & target usage requirements,
but none of the provided Find.cmake files seem to take
advantage of the new paradigm. Checking the wiki, the old
Find.cmake seem to be deprecated, with most of the information
on authoring new packages assuming that you are the developer of the
module, not the consumer. What is the recommended way to deal with
packages that don't provide these config files? I'll happily write my
own Find.cmake files, however that approach seems deprecated
and I haven't found any good examples of find modules that define IMPORT
or INTERFACE targets instead of the older method of setting a bunch of
_xxx variables.
There are a few modules that use imported targets in 3.0 and a few
more were updated in master.
I see e.g. FindGLUT, FindQt4, FindGTK2, FindZLIB, FindOpenGL and
FindGLEW making use of imported targets in master[1].
[2] documents how to write find modules and includes an example with
IMPORTED targets.
Nils
[1]
http://cmake.org/gitweb?p=cmake.git;a=tree;f=Modules;h=5d17682cb231f119b677ce67d804852d3be6d46f;hb=HEAD
[2]
http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#find-modules
--
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://public.kitware.com/mailman/listinfo/cmake
[CMake] Target usage requirements for shared libraries
Hi there! I've got a question I can't seem to find a good answer to: What is the idiomatic way in CMake 3.0 to handle bundling shared libraries? I've exhausted my google-fu and all of the examples seem to be from before CMake 3 was released. None of them take any advantage of 3.0's new and IMO much more elegant target usage requirements paradigm, and there doesn't really seem to be consensus on what the best way to handle this problem is. Given some application and some library with a header, static, and shared library components (.h, .lib, and .dll on windows), it seems like there should be some way to write a definition for an interface library such that by writing target_link_library( ), the appropriate shared libraries are copied to the exe directory (or in some way made accessible) either via a special custom target, a post build step, or install time. Static libraries and headers are handled this way, so why not shared libraries too? Am I just being naive? Thanks for your help. -Walter -- 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://public.kitware.com/mailman/listinfo/cmake
[CMake] find_package and INTERFACE targets in 3.0
Hi list! I'm a big fan of the new INTERFACE targets & target usage requirements, but none of the provided Find.cmake files seem to take advantage of the new paradigm. Checking the wiki, the old Find.cmake seem to be deprecated, with most of the information on authoring new packages assuming that you are the developer of the module, not the consumer. What is the recommended way to deal with packages that don't provide these config files? I'll happily write my own Find.cmake files, however that approach seems deprecated and I haven't found any good examples of find modules that define IMPORT or INTERFACE targets instead of the older method of setting a bunch of _xxx variables. -Walter -- 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://public.kitware.com/mailman/listinfo/cmake
