[CMake] Using CMake to compile non-standard languages

[Jakob van Bethlehem]

Dear all,

Currently I'm trying to make a case to convert the pure makefile-based
build environment at my company into cmake. This is a rather extensive
build environment, which takes care of many things automatically through a
whole set of internally created tools. I still believe we can do better
with CMake, but I need to make a strong case.

The main problem is that we have (very old) code in an obsure languange
called 'Ratfor'. How can I tell CMake how to compile files written in that
language?

Sincerely,
Jakob van Bethlehem
-- 

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] Not being able to create a 'link' interface for an OBJECT library

[Jakob van Bethlehem]

Dear all,

Recently I read the excellent tip of creating a 'link interface' for an
OBJECT library in order to overcome the inability to directly link an
OBJECT library, see:
https://cmake.org/cmake/help/v3.5/manual/cmake-buildsystem.7.html#object-libraries

This sounded like a perfect idea, so I tried it out on Windows 7 with the
VS 2013 64bit generator.
The first step was to build a shared library out of an object library,
which worked like a charm:


## Setup OBJECT library and a 'object link interface'
add_library(MyLib.Object OBJECT
  ... sources ..
)
target_include_directories(MyLib.Object
  PUBLIC
 includes
)

add_library(MyLib.Object.LinkInterface INTERFACE)
target_sources(MyLib.Object.LinkInterface INTERFACE
$)
target_include_directories(MyLib.Object.LinkInterface
  INTERFACE $
)
target_link_libraries(MyLib.Object.LinkInterface
  INTERFACE
 some dependent libraries
)

## set up shared library:
add_library(MyLib SHARED
  .. some additional sources
)

target_link_libraries(MyLib
  PUBLIC
MyLib.Object.LinkInterface
)


The second step was to try to create an executable that links with the
shared library. That is were I ran into some problems I can't quite fathom:

add_executable(MyExe
  ... sources ...
)

target_link_libraries(MyExe
  MyLib
)


This results in the following error from CMake:
CMake Error at MyExe/CMakeLists.txt:16 (add_executable):
  Cannot find source file:


/InstrumentControl.Object.dir/$(Configuration)/InstrumentControl.obj

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

It seems that for some reason CMake is trying to reuse the same target
sources on the executable, which doesn't make any sense really, as I'm
trying to link against a normal shared library.

The solution is to remove the 'target_sources' and put the
$ directly as a source when creating the shared library.
That is quite unfortunate however. The entire
purpose of the 'object link interface' was to remove the need to put these
generator expressions where there are needed, as explained on the
documentation page I referred to above.

So, the questions I have:
- should the described procedure work?
- if yes, did I something wrong, or did I stumble across a CMake bug?
- if no, it makes sense to put in a very clear warning on the referred
webpage, that the 'trick' will *not* work if one ever tries to link against
the final library.. a


Sincerely,
Jakob
-- 

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] cmake 3.7.2: add_custom_command can't DEPEND on OBJECT library?

[Jakob van Bethlehem]

Hej,

CMake experts may correct me if I'm wrong, but this is actually indeed not
supported (yet). Even though an object-library looks like any ordinary
library, in fact it is just a kind of 'shortcut' for a bunch of object
files - it is *not* a proper cmake TARGET. Some additional explanation can
be found here:
https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#object-libraries

So, then the question obviously becomes how to achieve the desired result.
If the creation of out.map only depends on that one source file, I'd expect
you get the wanted result if instead of writing 'DEPENDS liblface', you
write 'DEPENDS iface.cpp' - I'm not totally sure though.

Sincerely,
Jakob


On Sun, Jan 15, 2017 at 12:35 AM, Paul Smith  wrote:

> If I create an OBJECT library:
>
>   add_library(libIface OBJECT iface.cpp)
>
> Then I create a custom command that depends on this:
>
>   add_custom_command(OUTPUT out.map
>   COMMAND touch out.map
>   DEPENDS libIface
>   VERBATIM)
>
> It doesn't work: the dependency is missing so when I edit the iface.cpp
> file the custom command is not run.  I'm using the Makefile generator,
> on Linux, and if I look at the generated makefile it's obvious that
> there's nothing there representing the OBJECT library:
>
>   out.map:
> @$(CMAKE_COMMAND) -E ... "Generating out.map"
> touch out.map
>
> The documentation for add_custom_command() clearly says that DEPENDS can
> specify "any target (created by the ... add_library() command)".
>
> Is there something missing from the docs that should say it doesn't work
> with OBJECT libraries, or is this a bug in cmake?
>
>
> Repro:
>
> 
> $ cat CMakeLists.txt
> cmake_minimum_required(VERSION 3.5)
> project(MapTest)
>
> add_library(libIface OBJECT iface.cpp)
>
> add_custom_command(OUTPUT out.map
> COMMAND touch out.map
> DEPENDS libIface
> VERBATIM)
>
> add_custom_target(libIfaceMap DEPENDS out.map)
>
> add_library(iface SHARED $ out.map)
>
> $ touch iface.cpp
>
> $ cmake .
>
> $ make
> Scanning dependencies of target libIface
> [ 33%] Building CXX object CMakeFiles/libIface.dir/iface.cpp.o
> [ 33%] Built target libIface
> [ 66%] Generating out.map
> Scanning dependencies of target iface
> [100%] Linking CXX shared library libiface.so
> [100%] Built target iface
>
> $ touch iface.cpp
>
> $ make
> Scanning dependencies of target libIface
> [ 33%] Building CXX object CMakeFiles/libIface.dir/iface.cpp.o
> [ 33%] Built target libIface
> [ 66%] Linking CXX shared library libiface.so
> [100%] Built target iface
> 
>
> Note that in the last step the "out.map" file was not recreated even
> though iface.cpp was modified.
> --
>
> 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] Add dependencies to the automoc/autorcc target?

[Jakob van Bethlehem]

Hej Yves,

The problem is that the 'add_custom_command' does *NOT* create a new
target, which seems to be what you assume, see
https://cmake.org/cmake/help/v3.0/command/add_custom_command.html

The signature you're using is supposed to be used to *add* a custom command
to an *existing* target. In other words, it should read:

add_custom_command(TARGET foo PRE_BUILD COMMAND ${CMAKE_COMMAND} -E touch
  ${CMAKE_BINARY_DIR}/myfile.txt)

(and hopefully it is immediately obvious that the 'sleep' command should go
- CMake will never execute that command)

Sincerely,
Jakob

On Tue, Jan 17, 2017 at 12:02 PM, Yves Frederix <
yves.frederix+cm...@gmail.com> wrote:

> Hi all,
>
> I have a situation in which I would need to define a dependency for
> the automoc target. Is it possible to do this somehow?
>
> Basically, I have a setup in which a resource that is to be embedded
> is generated by another target. However, due to parallelism in the
> build and the lack of a dependency of the _automoc target on this
> target, I often get an error like :
>
>RCC: Error in '.../build/resources.qrc': Cannot find file
> '../build/myfile.txt'
>
> I tried adding a dependency using add_dependencies, but this doesn't
> seem to work.
>
> Minimal example code is below (you will need to create an empty
> main.cpp though). I am using CMake 3.7.1 with a VS generator. My build
> command looks like 'cmake --build . -- -m'.
>
>
> cmake_minimum_required(VERSION 3.7)
>
> project(test CXX)
>
> find_package(Qt5Quick REQUIRED)
>
> set(CMAKE_AUTORCC ON)
>
> # Define target that generates some files.
> add_custom_target(generate_files)
> add_custom_command(TARGET generate_files COMMAND sleep 1) # Wait a bit...
> add_custom_command(TARGET generate_files COMMAND ${CMAKE_COMMAND} -E touch
>   ${CMAKE_BINARY_DIR}/myfile.txt)
>
> # Write the .qrc file for embedding these generated files.
> file(WRITE ${CMAKE_BINARY_DIR}/resources.qrc
>   "   version=\"1.0\">\n\n${CMAKE_BINARY_DIR}/
> myfile.txt\n\n")
>
> add_library(foo SHARED main.cpp ${CMAKE_BINARY_DIR}/resources.qrc)
> add_dependencies(foo generate_files)
> target_link_libraries(foo PRIVATE Qt5::Quick)
>
>
> Thanks!
>
> Regards,
> Yves
> --
>
> 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] Tracing ctest crash on windows

[Jakob van Bethlehem]

Hej,

CTest is not some magical tool that internally runs your test or something
like that - instead CTest just fires up your test executable and does
clever things with the output. In the same way you can just set your test
project as startup-project, and debug it like any other executable.

Sincerely,
Jakob

On Wed, Jan 4, 2017 at 2:43 PM, Aaron Boxer  wrote:

> Hello,
> I am on windows, with visual studio 2015.
> Some of my ctest tests are crashing with exception.
> Is there a way of debugging these tests ?
>
> When I run in debug mode, I get an exception dialog,
> but can't drop into debugging environment.
>
> Thanks,
> Aaron
>
> --
>
> 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] Pointing CMAKE_AUTOMOC to a custom version of Qt and its moc.exe

[Jakob van Bethlehem]

Hej,

On Mon, Nov 7, 2016 at 4:48 PM, Saad Khattak  wrote:

> I am working on a plugin for Maya and it uses a customized version of Qt.
> Maya's SDK comes with everything to build Qt (headers, libraries and
> customized Qt tools such as moc.exe).
>
> I have the following issues:
>
> (1) With CMAKE_AUTOMOC set to ON, I am unable to figure out how to point
> CMake to pick Maya's version of moc.exe (and other Qt utils). The result is
> that I get linking errors since the moc did not run - which I expected.
>
> (2) Maya uses a modified version of Qt 5.6.1. There is currently no way to
> get that version from Autodesk. So I downloaded the official Qt 5.6.1
> distribution. CMAKE_AUTOMOC now sets up my project correctly to be MOC'ed.
> However, it is using the official Qt moc utilities and NOT Maya's
> customized moc. The headers and libraries being used were still from Maya's
> custom Qt.
>
> The reason (2) worked is because I put "find_package(Qt5Widgets REQUIRED)"
> after installing the official version of Qt 5.6.1. However, I did NOT use
> the official Qt headers or libraries - instead, I used Maya's custom
> version of Qt 5.6.1.
>
> Using solution (2) I successfully compile and link my Qt enabled Maya
> plugin and load it in Maya. Things go smoothly until I either (a) unload
> the plugin or (b) delete any widget. I looked at the simplest code that is
> causing a heap corruption debug assertion:
>
> m_button = new QPushButton("MyButton"); // where m_button is a QPointer
> 
> delete m_button; // causes heap corruption debug assertion to fire
>
> A few other people have gone through similar issues but since they didn't
> use CMake, they simply ran Maya's moc utilities in a build step. I would
> like a solution where I can get CMAKE_AUTOMOC to run the custom Qt version.
>
> Thanks.
>
>
I see quite a lot usage of the word 'customized'. to me it sounds like
you may be asking on the wrong user list?

Sincerely,
Jakob
-- 

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] Get libraries from target

[Jakob van Bethlehem]

Hej,

You should be able to query the LINK_LIBRARIES (and maybe some related
properties), see
https://cmake.org/cmake/help/v3.6/prop_tgt/LINK_LIBRARIES.html

Sincerely,
Jakob


On Wed, Nov 9, 2016 at 12:05 AM, Tiago Macarios 
wrote:

> Hi,
>
> Is there a way for me to get CMake libraries out of a target?
>
> For example:
>
> target_link_libraries(A B C)
>
> Can I get B and C from A?
>
> What I am trying to do:
> We are working on adding include-what-you-use into our build system and
> some of the libraries have their on mapping files. So I was wondering if I
> could somehow "attach" the mapping file to the target and then
> "reconstruct" a mapping file for each target.
>
> For example:
>
> Library B and C have their own mapping, so I would:
> set_target_properties(B
> PROPERTIES mapping /path/to/fileB)
> set_target_properties(C
> PROPERTIES mapping /path/to/fileC)
>
> Then a function would reconstruct a mapping for target A:
> set_target_properties(A
> PROPERTIES mapping /path/to/fileA)
>
> create_mapping_function(A):
>  loop over dependencies of A
>  get all mappings
>  recreate a mapping file with all dependencies:
>
> { ref: "/path/to/fileA" },
> { ref: "/path/to/fileB" }
> { ref: "/path/to/fileC" }
>
>
> --
>
> 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] Adding Cmake version in online documentation

[Jakob van Bethlehem]

Oops, totally forgot to mention the crux: I happened to be the guy who
apparently was the first to start using continue() - so by the time my
college got to me, we quickly found out the issue. But before the college
hit the problem, I didn't have the vaguest clue that I was typing code that
would require an update of the minimum cmake version.

Honestly, the fact that we don't have some strict policy in our team for
setting version of 3rd parties like CMake, leading to different developers
ending up with different versions, is questionable, yes, of course. It is
the reality however, and my feeling is this is the reality for many more
teams.

Given the copious amount of traffic this issue has generated on this
thread, and in the past(!), it seems no more than reasonable that at least
*something* should happen. I do assume user feedback plays an important
role in deciding where to go with CMake development?

Sincerely,
Jakob

On Wed, Nov 9, 2016 at 1:38 PM, Jakob van Bethlehem <
jsvanbethle...@gmail.com> wrote:

> +1 for me too - sometime ago a college of mine spend quite some time to
> figure why he couldn't bootstrap our application - turns out he was using
> an (old) CMake version which didn't know about the 'continue' command. The
> error-messages coming out of CMake sometimes help, but more often don't
> really give the correct hint, unless you happen to be one of the local
> CMake gurus.
>
> Sincerely,
> Jakob
>
>
> On Tue, Nov 8, 2016 at 10:33 PM, Craig Scott <craig.sc...@crascit.com>
> wrote:
>
>> Rather than trying to do everything, perhaps there's value in tackling
>> this in stages. At a high level, simply knowing in which CMake version a
>> particular command, property, variable or module was added is a good start.
>> From there, if a command, etc. gained new options, then a note could be
>> added with the text specific to that option to indicate when it was added.
>> Obviously the more fine grained you go, the more time consuming and onerous
>> it would become, but how about just starting with the coarse level? That
>> already provides a big improvement over the current alternative of wading
>> through past versions of documentation and/or source code.
>>
>> I'd also recommend that such version details be part of the actual CMake
>> docs. While the separate compatibility matrix on the wiki is/was a useful
>> resource, by not having it part of the CMake sources/docs, it is inherently
>> a separate effort to try to keep it up to date with each CMake release.
>> Making it part of CMake itself would seem to encourage documenting version
>> details as part of the same merge requests, etc. that add/change things.
>>
>> I'll go out on a limb here and suggest that if a clear guideline was
>> given for *how* version details should be documented, then the community
>> itself would likely work towards populating that information over time. I
>> don't think there is a (realistic) expectation that Kitware would do all
>> the heavy lifting here.
>>
>>
>>
>> On Wed, Nov 9, 2016 at 8:23 AM, Eric Noulard <eric.noul...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> 2016-11-08 20:26 GMT+01:00 Albrecht Schlosser <albrechts.f...@online.de>
>>> :
>>>
>>>> On 08.11.2016 15:22 Nils Gladitz wrote:
>>>>
>>>>> On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote:
>>>>>
>>>>> But how do you know which version to declare on cmake_minimum_required?
>>>>>> If this feature will be added it won't be far from writing a script
>>>>>> that scans the commands you use and outputs the first appropriate
>>>>>> version.
>>>>>>
>>>>>
>>>> I'd also like such an addition to the documentation for reasons
>>>> discussed below.
>>>
>>>
>>>
>>> I think the need is recognized by most CMake user but...
>>>
>>>
>>>>
>>>>
>>>> Strictly speaking cmake_minimum_required(VERSION) is not about command
>>>>> availability but rather about behavior (cmake policies).
>>>>>
>>>> [...]
>>>>
>>>>> I'd start by requesting the highest possible version I could justify
>>>>> (e.g. based on availability on target platforms and user convenience)
>>>>> and then start from there.
>>>>>
>>>>
>>>> And that's exactly the (my) point. How can I find out the "highest
>>>> possible version I could justify"?
>>>>
>>>> I'm a developer of a public GUI library (FLTK). In th

Re: [CMake] Adding Cmake version in online documentation

[Jakob van Bethlehem]

+1 for me too - sometime ago a college of mine spend quite some time to
figure why he couldn't bootstrap our application - turns out he was using
an (old) CMake version which didn't know about the 'continue' command. The
error-messages coming out of CMake sometimes help, but more often don't
really give the correct hint, unless you happen to be one of the local
CMake gurus.

Sincerely,
Jakob


On Tue, Nov 8, 2016 at 10:33 PM, Craig Scott 
wrote:

> Rather than trying to do everything, perhaps there's value in tackling
> this in stages. At a high level, simply knowing in which CMake version a
> particular command, property, variable or module was added is a good start.
> From there, if a command, etc. gained new options, then a note could be
> added with the text specific to that option to indicate when it was added.
> Obviously the more fine grained you go, the more time consuming and onerous
> it would become, but how about just starting with the coarse level? That
> already provides a big improvement over the current alternative of wading
> through past versions of documentation and/or source code.
>
> I'd also recommend that such version details be part of the actual CMake
> docs. While the separate compatibility matrix on the wiki is/was a useful
> resource, by not having it part of the CMake sources/docs, it is inherently
> a separate effort to try to keep it up to date with each CMake release.
> Making it part of CMake itself would seem to encourage documenting version
> details as part of the same merge requests, etc. that add/change things.
>
> I'll go out on a limb here and suggest that if a clear guideline was given
> for *how* version details should be documented, then the community itself
> would likely work towards populating that information over time. I don't
> think there is a (realistic) expectation that Kitware would do all the
> heavy lifting here.
>
>
>
> On Wed, Nov 9, 2016 at 8:23 AM, Eric Noulard 
> wrote:
>
>>
>>
>> 2016-11-08 20:26 GMT+01:00 Albrecht Schlosser :
>>
>>> On 08.11.2016 15:22 Nils Gladitz wrote:
>>>
 On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote:

 But how do you know which version to declare on cmake_minimum_required?
> If this feature will be added it won't be far from writing a script
> that scans the commands you use and outputs the first appropriate
> version.
>

>>> I'd also like such an addition to the documentation for reasons
>>> discussed below.
>>
>>
>>
>> I think the need is recognized by most CMake user but...
>>
>>
>>>
>>>
>>> Strictly speaking cmake_minimum_required(VERSION) is not about command
 availability but rather about behavior (cmake policies).

>>> [...]
>>>
 I'd start by requesting the highest possible version I could justify
 (e.g. based on availability on target platforms and user convenience)
 and then start from there.

>>>
>>> And that's exactly the (my) point. How can I find out the "highest
>>> possible version I could justify"?
>>>
>>> I'm a developer of a public GUI library (FLTK). In this position you
>>> don't know anything about the availability of CMake versions on your target
>>> platforms. Our intention is to keep cmake_minimum_required() as low as
>>> possible.
>>>
>>> That said, whenever you change a CMakeLists.txt file you should be aware
>>> if the commands you use are compatible with the CMake version you
>>> "require". There should be an easy way to find out in which version a
>>> particular CMake command has been introduced. Only with this information
>>> you can decide if you should use this fine command or better find another
>>> way to do the task you're going to do.
>>>
>>> I'd like to have a list of release dates (I'm not sure if there is one)
>>> as well as the exact version a feature was introduced to write
>>> CMakeLists.txt files that run on really old CMake versions
>>
>>
>> Some time ago people came up (dig the ML for the related discussion) with
>> compatibility matrix idea:
>> https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix
>> http://public.kitware.com/pipermail/cmake/2010-December/041202.html
>>
>> And it finally ends with cmake 3.0.0
>> http://public.kitware.com/pipermail/cmake/2015-March/059983.html
>>
>> Note that this is far more complicated than simply listing when one
>> command appears because some command may get more options, or change their
>> default semantic
>> (using POLICY etc..) so the feature granularity leads to question like
>>
>> When did the 'string' cmake command support the UUID argument ?
>>
>> Before which version of CMake does get_target_property
>> accept  non-existent target argument without issuing any error or warning ?
>> (see POLICY CMP0045)
>>
>> So basically, tracking all kind of behavior change is not as easy as it
>> seems.
>>
>> How can we document the changes ? Or better extract them from the code or
>> documentation?
>>
>> --
>> Eric

Re: [CMake] Issues when cmake prints compiler messages

[Jakob van Bethlehem]

Hej Santiago,

Before being able to help you further, I guess it makes sense to fill in some 
details here: which OS, which compiler (version), which version of CMake. 
Personally I have never seen anything like this on a broad range of OS/compiler 
combinations. Also, since you suspect the background color of the terminal is 
the problem here, you could tell us about the background color you set for your 
terminal. 

Even simpler would be for you to change the background color of the terminal, 
and run the compiler again to verify whether your suspicion is correct or not.

Sincerely,
Jakob


> On 09 Jul 2016, at 12:18, Santiago Pagola  wrote:
> 
> Hello everyone!
> 
> I am new on this list, and I would like to ask if someone here has 
> experienced the same error me:
> 
> When I try to compile any project (or even simple programs), the compiler 
> starts printing information. It seems normal except for the fact that when it 
> comes to variable names, these are not shown (that is, instead of showing 
> something like:
> 
> Warning: unused parameter 'm_dummy_variable'
> 
> It shows the following:
> 
> Warning: unused parameter '   '
> 
> The thing is that, when I try to copy-paste the output from the console to a 
> text file, the variables are indeed there, which leads me to believe that the 
> variable names in the terminal may be of the same color that the background 
> of the terminal itself.
> 
> Has anyone had this little issue before? Is is something directly related 
> with cmake or is it the compiler? Any suggestions?
> 
> Thanks in advance!
> 
> Best regards,
> /Santiago
> -- 
> 
> 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] Using CMake on CLion and adding geoip library

[Jakob van Bethlehem]

Hej,

According to https://cmake.org/cmake/help/v3.4/module/CheckIncludeFile.html the 
‘check_include_file’ is a function provided by a module. So you’ll need to 
include(CheckIncludeFile) at the beginning of your lists-file

Sincerely,
Jakob

> On 25 Jun 2016, at 08:09, Hgfjj Hhjgf  wrote:
> 
> I am trying to use an external library (GeoIP). CMake list contains:
> message(STATUS "Looking for MaxMind GeoIP header files")
> 
> set(CMAKE_INCLUDE_PATH "${CMAKE_INCLUDE_PATH} ${GEOIP_INCLUDE_DIR}")
> check_include_file("GeoIP.h" HAVE_GEOIP_H)
> check_include_file("GeoIPCity.h" HAVE_GEOIPCITY_H)
> if (HAVE_GEOIP_H AND HAVE_GEOIPCITY_H)
> message(STATUS "Looking for MaxMind GeoIP header files - found")
> else(HAVE_GEOIP_H AND HAVE_GEOIPCITY_H)
> message(FATAL_ERROR "Could not find one or more MaxMind GeoIP header 
> files. If the MaxMind GeoIP library is installed, you can run CMake again and 
> specify its location with -DGEOIP_INCLUDE_DIR=")
> endif(HAVE_GEOIP_H AND HAVE_GEOIPCITY_H)
> 
> message(STATUS "Looking for MaxMind GeoIP libraries")
> find_library(GEOIP_LIB
> NAMES GeoIP geoip
> PATHS ${GEOIP_LIBRARY_DIR}
> )
> if (GEOIP_LIB)
> message(STATUS "Looking for MaxMind GeoIP libraries - found")
> set(GEOIP_LIBRARIES ${GEOIP_LIB})
> else(GEOIP_LIB)
> message(FATAL_ERROR "Could not find MaxMind GeoIP library")
> endif(GEOIP_LIB)
> 
> but getting error like "Unknown cmake command: check_include_file"
> what's the problem here then?
> -- 
> 
> 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] CMake+QT always failed for the first build, and succeeded for second build or later.

[Jakob van Bethlehem]

> Hey, that was the LTS release until 1 or 2 month ago!

Oops, you're right, my mistake. Somewhere in the back of my head was that
the 4-series was in the 4.12.x or so version, not sure where that came
from. I haven't worked with Qt4 ever, but have become extremely experienced
with Qt5 from Qt 5.4 onwards. Nevertheless, I should've checked before
mentioning it :P.

Sincerely,
Jakob van Bethlehem

On Wed, Jun 1, 2016 at 10:47 AM, Hendrik Sattler <p...@hendrik-sattler.de>
wrote:

>
>
> Am 1. Juni 2016 09:26:18 MESZ, schrieb Jakob van Bethlehem <
> jsvanbethle...@gmail.com>:
> >That is what he said, but it seems to be a typo, because the
> >CMakeLists.txt
> >file clearly states 'set(QT_DIR
> >${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)'
>
> Ok, I overlooked that one...
>
> >- still a stone-age version of Qt actually :(
>
> Hey, that was the LTS release until 1 or 2 month ago!
> And they made Qt 5.6 an LTS release also to quieten people that complain
> about dropping modules without proper replacement (means feature parity)
> and dropping compiler support.
> You will see users of Qt 5.6 for a loong time.
>
> >On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler
> ><p...@hendrik-sattler.de>
> >wrote:
> >
> >>
> >>
> >> Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem <
> >> jsvanbethle...@gmail.com>:
> >> >Hej,
> >> >
> >> >Some things that come to mind:
> >> >* You're generating files *inside* the source tree - you're not
> >> >supposed to
> >> >do that
> >> >* Why do you want to have a special Qt_tmp directory? I don't see
> >the
> >> >benefit, and without that requirement you can simply use the
> >> >qt4_wrap_cpp
> >> >macro explicitly and you still are not forced to use the automoc
> >> >feature
> >> >
> >> >And now for what is probably wrong in your CMakeLists.txt:
> >> >* It seems you made an important mistake regarding the behaviour of
> >> >'file(GLOB)'. That function will do the expansion *while running
> >> >CMake*.
> >> >But at that time the moc_* files *don't exist!* (as a matter of
> >fact,
> >> >the
> >> >tmp directory doesn't even exist). In other words, your
> >${Moc_SOURCES}
> >> >will
> >> >be empty, and hence they are not compiled, and hence you get
> >precisely
> >> >the
> >> >linker errors you see (because these sources implement the functions
> >> >that
> >> >are listed as missing by the linker)
> >> >
> >> >If you would use the qt4_wrap_cpp() macro you don't run into this
> >> >problem,
> >> >so I'd strongly suggest using it.
> >>
> >> Except that he is using Qt3.
> >>
> >> >Sincerely,
> >> >Jakob van Bethlehem
> >> >
> >> >
> >> >
> >> >
> >> >On Tue, May 31, 2016 at 4:52 PM, irene w <ire866...@gmail.com>
> >wrote:
> >> >
> >> >> It seems CMakw could not find the generated moc_xxx files.  I
> >> >modified the
> >> >> scripts to specify moc_xxx files is generated, but it still has
> >same
> >> >errors.
> >> >>
> >> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
> >> >>  COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
> >> >> ${Qt_tmp}/moc_GMWindow.cpp
> >> >>  DEPENDS ${GM_DIR}/GMWindow.h
> >> >>)
> >> >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
> >> >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
> >> >> GENERATED 1)
> >> >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY
> >> >OBJECT_DEPENDS
> >> >> ${Qt_tmp}/moc_GMWindow.cpp)
> >> >>
> >> >> .
> >> >> add_dependencies (GM generate_foo)
> >> >>
> >> >>
> >> >> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
> >> >> setting work for this purposes?  Any help would be greatly
> >> >appreciated !
> >> >>
> >> >>
> >> >> On Wed, May 25, 2016 at 12:48 PM, irene w <ire866...@gmail.com>
> >> &

Re: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later.

[Jakob van Bethlehem]

That is what he said, but it seems to be a typo, because the CMakeLists.txt
file clearly states 'set(QT_DIR
${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)'
- still a stone-age version of Qt actually :(

Sincerely,
Jakob van Bethlehem


On Wed, Jun 1, 2016 at 9:09 AM, Hendrik Sattler <p...@hendrik-sattler.de>
wrote:

>
>
> Am 1. Juni 2016 09:02:41 MESZ, schrieb Jakob van Bethlehem <
> jsvanbethle...@gmail.com>:
> >Hej,
> >
> >Some things that come to mind:
> >* You're generating files *inside* the source tree - you're not
> >supposed to
> >do that
> >* Why do you want to have a special Qt_tmp directory? I don't see the
> >benefit, and without that requirement you can simply use the
> >qt4_wrap_cpp
> >macro explicitly and you still are not forced to use the automoc
> >feature
> >
> >And now for what is probably wrong in your CMakeLists.txt:
> >* It seems you made an important mistake regarding the behaviour of
> >'file(GLOB)'. That function will do the expansion *while running
> >CMake*.
> >But at that time the moc_* files *don't exist!* (as a matter of fact,
> >the
> >tmp directory doesn't even exist). In other words, your ${Moc_SOURCES}
> >will
> >be empty, and hence they are not compiled, and hence you get precisely
> >the
> >linker errors you see (because these sources implement the functions
> >that
> >are listed as missing by the linker)
> >
> >If you would use the qt4_wrap_cpp() macro you don't run into this
> >problem,
> >so I'd strongly suggest using it.
>
> Except that he is using Qt3.
>
> >Sincerely,
> >Jakob van Bethlehem
> >
> >
> >
> >
> >On Tue, May 31, 2016 at 4:52 PM, irene w <ire866...@gmail.com> wrote:
> >
> >> It seems CMakw could not find the generated moc_xxx files.  I
> >modified the
> >> scripts to specify moc_xxx files is generated, but it still has same
> >errors.
> >>
> >> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
> >>  COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
> >> ${Qt_tmp}/moc_GMWindow.cpp
> >>  DEPENDS ${GM_DIR}/GMWindow.h
> >>)
> >> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
> >> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
> >> GENERATED 1)
> >> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY
> >OBJECT_DEPENDS
> >> ${Qt_tmp}/moc_GMWindow.cpp)
> >>
> >> .
> >> add_dependencies (GM generate_foo)
> >>
> >>
> >> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
> >> setting work for this purposes?  Any help would be greatly
> >appreciated !
> >>
> >>
> >> On Wed, May 25, 2016 at 12:48 PM, irene w <ire866...@gmail.com>
> >wrote:
> >>
> >>> Hi,
> >>>
> >>> I am compiling a simple Qt3 application on Linux using CMake. In my
> >case,
> >>> I need to build moc_xxx files with custom options and output to a
> >specified
> >>> directory, So, I was not using CAMKE_AUTO macros. My cmake scripts
> >create a
> >>> "Qt_tmp" directory and output moc_xxx there.
> >>>
> >>> It looked it always failed to link the moc_xxx files for the first
> >time
> >>> build when there is no "Qt_tmp" directory, and succeeded if I ran
> >build
> >>> again if the "Qt_tmp" directory and moc_xxx files created by the
> >failed
> >>> build were kept without removing.  However, it'll fail if I delete
> >>> the "Qt_tmp" directory.
> >>>
> >>> Even it failed at the first build, the moc_xxx files were
> >>> successfully created in the "Qt_tmp" directory.
> >>>
> >>> Here is my cmake scripts and the errors I got.  Can anyone help me
> >to
> >>> figure out the issues? Any help would be greatly appreciated.
> >Thanks.
> >>>
> >>> CMakeLists.txt
> >>>
> >>>
>
> >-
> >>> cmake_minimum_required(VERSION 3.4.1)
> >>> project (GM_Application CXX)
> >>> SET (CMAKE_SYSTEM_NAME Linux)
> >>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++)
> >>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR})
> >>> set (QT_DIR ${CMAKE_CURREN

Re: [CMake] CMake+QT always failed for the first build, and succeeded for second build or later.

[Jakob van Bethlehem]

Hej,

Some things that come to mind:
* You're generating files *inside* the source tree - you're not supposed to
do that
* Why do you want to have a special Qt_tmp directory? I don't see the
benefit, and without that requirement you can simply use the qt4_wrap_cpp
macro explicitly and you still are not forced to use the automoc feature

And now for what is probably wrong in your CMakeLists.txt:
* It seems you made an important mistake regarding the behaviour of
'file(GLOB)'. That function will do the expansion *while running CMake*.
But at that time the moc_* files *don't exist!* (as a matter of fact, the
tmp directory doesn't even exist). In other words, your ${Moc_SOURCES} will
be empty, and hence they are not compiled, and hence you get precisely the
linker errors you see (because these sources implement the functions that
are listed as missing by the linker)

If you would use the qt4_wrap_cpp() macro you don't run into this problem,
so I'd strongly suggest using it.

Sincerely,
Jakob van Bethlehem




On Tue, May 31, 2016 at 4:52 PM, irene w <ire866...@gmail.com> wrote:

> It seems CMakw could not find the generated moc_xxx files.  I modified the
> scripts to specify moc_xxx files is generated, but it still has same errors.
>
> ADD_CUSTOM_COMMAND ( OUTPUT ${Qt_tmp}/moc_GMWindow.cpp
>  COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
> ${Qt_tmp}/moc_GMWindow.cpp
>  DEPENDS ${GM_DIR}/GMWindow.h
>)
> ADD_CUSTOM_TARGET(generate_foo DEPENDS ${Qt_tmp}/moc_GMWindow.cpp)
> SET_SOURCE_FILES_PROPERTIES(${Qt_tmp}/moc_GMWindow.cpp PROPERTIES
> GENERATED 1)
> SET_PROPERTY(SOURCE ${GM_DIR}/GMWindow.cpp APPEND PROPERTY OBJECT_DEPENDS
> ${Qt_tmp}/moc_GMWindow.cpp)
>
> .
> add_dependencies (GM generate_foo)
>
>
> Does the Macro  "SET_SOURCE_FILES_PROPERTIES" with "GENERATED"
> setting work for this purposes?  Any help would be greatly appreciated !
>
>
> On Wed, May 25, 2016 at 12:48 PM, irene w <ire866...@gmail.com> wrote:
>
>> Hi,
>>
>> I am compiling a simple Qt3 application on Linux using CMake. In my case,
>> I need to build moc_xxx files with custom options and output to a specified
>> directory, So, I was not using CAMKE_AUTO macros. My cmake scripts create a
>> "Qt_tmp" directory and output moc_xxx there.
>>
>> It looked it always failed to link the moc_xxx files for the first time
>> build when there is no "Qt_tmp" directory, and succeeded if I ran build
>> again if the "Qt_tmp" directory and moc_xxx files created by the failed
>> build were kept without removing.  However, it'll fail if I delete
>> the "Qt_tmp" directory.
>>
>> Even it failed at the first build, the moc_xxx files were
>> successfully created in the "Qt_tmp" directory.
>>
>> Here is my cmake scripts and the errors I got.  Can anyone help me to
>> figure out the issues? Any help would be greatly appreciated.  Thanks.
>>
>> CMakeLists.txt
>>
>> -
>> cmake_minimum_required(VERSION 3.4.1)
>> project (GM_Application CXX)
>> SET (CMAKE_SYSTEM_NAME Linux)
>> SET (CMAKE_CXX_COMPILER ${COMPILER_PATH}${CROSS_COMPILE}g++)
>> set (GM_DIR ${CMAKE_CURRENT_SOURCE_DIR})
>> set (QT_DIR ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty/Qt/4.8.6)
>> LINK_DIRECTORIES (${QT_DIR}/lib)
>> INCLUDE_DIRECTORIES ("${QT_DIR}/include"
>>  "${GM_DIR}"
>> )
>> # Compiling QT moc and ui  #
>> set (QT_MOC_CMD ${QT_DIR}/bin/moc -I$(QT_DIR)/mkspecs/linux-g++
>> -I${QT_DIR}/include -I${QT_DIR}/include/QtGui)
>> file (MAKE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
>> set (Qt_tmp ${CMAKE_CURRENT_SOURCE_DIR}/Qt_tmp)
>> add_custom_target (Moc_GMWindows
>>COMMAND ${QT_MOC_CMD} ${GM_DIR}/GMWindow.h -o
>> ${Qt_tmp}/moc_GMWindow.cpp
>>   )
>>
>> # Compiling application  #
>> file (GLOB GM_SOURCES ${GM_DIR}/*.h ${GM_DIR}/*.cpp)
>> file (GLOB Moc_SOURCES ${Qt_tmp}/*.h ${Qt_tmp}/*.cpp)
>> add_executable (GM ${GM_SOURCES} ${Moc_SOURCES})
>> target_include_directories (GM PRIVATE ${Qt_tmp})
>> add_dependencies (GM Moc_GMWindows)
>> target_link_libraries (GM QtGui)
>>
>>
>> ---
>> Errors:
>>
>> Scanning dependencies of target Moc_GMWindows
>> [  0%] Built target Moc_GMWindows
>> Scanning dependencies of target GM
>> [ 14%] Building CXX object GM/CMakeFiles/GM.dir/GM/GM.cpp.o
&

Re: [CMake] Setting a value in a sub-project

[Jakob van Bethlehem]

Ah, nice. Good to know. But then still that cache variable is not created
until *after* it was set by Foo, because it is only created when adding the
Bar subdirectory, which explains the output.

Sincerely,
Jakob


On Fri, May 20, 2016 at 1:18 PM, Petr Kmoch <petr.km...@gmail.com> wrote:

> The situation already involves a cache variable, though: `option(abc "cmt"
> ON)` is just syntactic sugar for `set(abc ON CACHE BOOL "cmt")`.
>
> Petr
>
>
> On 20 May 2016 at 13:03, Jakob van Bethlehem <jsvanbethle...@gmail.com>
> wrote:
>
>> You don't have to create a cache variable for this. Put yourself in the
>> position of CMake;
>> * While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1
>> ON FORCE) command, which tells CMake to create a *variable* called OPT1
>> with value ON
>> * Then CMake is asked to include Bar
>> * While scanning Bar, CMake encounters the option() command, so it will
>> create an option called OPT1
>> * end then nothing, CMake finished scanning
>>
>> Only the second time around, when CMake encounters the set(OPT1..)
>> command, it will have gained knowledge of the presence of the OPT1 option,
>> and hence it will realize it needs to change that option instead of
>> creating a variable with that name.
>>
>> So to me, your output is exactly as expected. I suspect if you include
>> Bar before setting the option, you will get the behaviour you expected.
>> This, to me, makes perfect sense, as Bar is a dependency of Foo, and hence
>> needs to be setup before you start setting up Foo. You wouldn't compile Foo
>> before compiling Bar, so why would that be different for the configuration
>> step.
>>
>> Sincerely,
>> Jakob
>>
>> On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson <
>> doug.cuthbert...@gmail.com> wrote:
>>
>>>
>>> CMake (version 3.5.2) surprised me with how it's passing values to
>>> sub-projects, so I was wondering if this is expected behavior. Here's an
>>> example of what I mean. Let's say I have a project Foo in a directory of
>>> the same name. It contains a third-party library called Bar which has a
>>> CMakeLists.txt file that looks like:
>>>
>>> cmake_minimum_required(VERSION 2.8.12)
>>>
>>> option(OPT1
>>>   "Set to OFF|ON (default is OFF) to control build of Bar library"
>>> OFF)
>>>
>>> if(OPT1)
>>>   message("Bar: OPT1 is on")
>>> else(OPT1)
>>>   message("Bar: OPT1 is off")
>>> endif(OPT1)
>>>
>>> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes
>>> Bar:
>>>
>>> cmake_minimum_required(VERSION 2.8.12)
>>>
>>> set(OPT1 ON FORCE)
>>> if(OPT1)
>>>   message("Foo: OPT1 is on")
>>> else(OPT1)
>>>   message("Foo: OPT1 is off")
>>> endif(OPT1)
>>> add_subdirectory(Bar)
>>>
>>> The first time I run cmake the message output is:
>>>
>>> Foo: OPT1 is on
>>> Bar: OPT1 is off
>>>
>>> If I run cmake again, I get:
>>>
>>> Foo: OPT1 is on
>>> Bar: OPT1 is on
>>>
>>> If this is expected behavior, is there any way I can ensure Bar receives
>>> the value of OPT1 the first time? It makes a huge difference when the
>>> option controls, for example, whether a static or dynamic library will be
>>> built.
>>>
>>> Thanks,
>>> Doug
>>>
>>> --
>>>
>>> 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:
>> ht

Re: [CMake] Setting a value in a sub-project

[Jakob van Bethlehem]

You don't have to create a cache variable for this. Put yourself in the
position of CMake;
* While scanning the CMakeLists.txt of Foo CMake encounters the set(OPT1 ON
FORCE) command, which tells CMake to create a *variable* called OPT1 with
value ON
* Then CMake is asked to include Bar
* While scanning Bar, CMake encounters the option() command, so it will
create an option called OPT1
* end then nothing, CMake finished scanning

Only the second time around, when CMake encounters the set(OPT1..) command,
it will have gained knowledge of the presence of the OPT1 option, and hence
it will realize it needs to change that option instead of creating a
variable with that name.

So to me, your output is exactly as expected. I suspect if you include Bar
before setting the option, you will get the behaviour you expected. This,
to me, makes perfect sense, as Bar is a dependency of Foo, and hence needs
to be setup before you start setting up Foo. You wouldn't compile Foo
before compiling Bar, so why would that be different for the configuration
step.

Sincerely,
Jakob

On Fri, May 20, 2016 at 11:24 AM, Doug Cuthbertson <
doug.cuthbert...@gmail.com> wrote:

>
> CMake (version 3.5.2) surprised me with how it's passing values to
> sub-projects, so I was wondering if this is expected behavior. Here's an
> example of what I mean. Let's say I have a project Foo in a directory of
> the same name. It contains a third-party library called Bar which has a
> CMakeLists.txt file that looks like:
>
> cmake_minimum_required(VERSION 2.8.12)
>
> option(OPT1
>   "Set to OFF|ON (default is OFF) to control build of Bar library" OFF)
>
> if(OPT1)
>   message("Bar: OPT1 is on")
> else(OPT1)
>   message("Bar: OPT1 is off")
> endif(OPT1)
>
> I then create CMakeLists.txt for Foo that sets OPT1 to ON and includes Bar:
>
> cmake_minimum_required(VERSION 2.8.12)
>
> set(OPT1 ON FORCE)
> if(OPT1)
>   message("Foo: OPT1 is on")
> else(OPT1)
>   message("Foo: OPT1 is off")
> endif(OPT1)
> add_subdirectory(Bar)
>
> The first time I run cmake the message output is:
>
> Foo: OPT1 is on
> Bar: OPT1 is off
>
> If I run cmake again, I get:
>
> Foo: OPT1 is on
> Bar: OPT1 is on
>
> If this is expected behavior, is there any way I can ensure Bar receives
> the value of OPT1 the first time? It makes a huge difference when the
> option controls, for example, whether a static or dynamic library will be
> built.
>
> Thanks,
> Doug
>
> --
>
> 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] A bug that seems solved, but not listed in mantis log

[Jakob van Bethlehem]

Dear users,

With cmake 3.2.2 doing the following with VS 2013:
add_library(ObjectLib OBJECT source1.cpp source2.cpp)
add_library(MyDll SHARED $<TARGET_OBJECTS:ObjectLib)

there seems to be a problem that there is no explicit dependency added
between the shared library and the object files. In other words: I noticed
VS trying to link the dll, and then complaining that the object files
didn't exist, which was indeed true.

The workaround is to:
add_dependency(MyDll ObjectLib)

With cmake 3.5.2 I noticed this problem is gone, and the workaround could
be removed. Apparently the bug was noted and solved. However, I can't find
a reference to such a bug on https://cmake.org/Bug/changelog_page.php.

Does anyone know whether this bug was solved as part of some other bug or
feature and if yes, which one?

Sincerely,
Jakob van Bethlehem
-- 

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] Finding list of fixed bugs in each CMake release

[Jakob van Bethlehem]

Dear users,

In order to try to 'sell' my team upgrading to the newest CMake version, I
was looking for a list of bugs that are fixed (I think we have workarounds
for some of them, but I'm not sure) in each CMake release. I was expecting
to find them in the release notes, and discovered that 'release notes'
(which were actually simple posts to this list) for CMake 2.x seem to
include them, but from Cmake 3.x onward they don't - I'm referring now to
pages like https://cmake.org/cmake/help/v3.5/release/3.5.html.

So where can I now find the bugs that are solved in a given version of
Cmake?

Sincerely,
Jakob van Bethlehem
-- 

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] Cmake 3.5.2 update problem

[Jakob van Bethlehem]

Dear users,

Today I tried to bootstrap our app with CMake 3.5.2. Unfortunately it
caused problems in one of our custom functions we created. This is for the
Visual Studio 2013 64bit generator.

We have a function to create tests that accepts an 'INCLUDES' parameter,
and we tend to use generator expressions to pass include directories from
other libraries in the solution, i.e. something like this:

add_test(
TARGET TestName
INCLUDES
$
$
 LIBRARIES
 AnotherLib
 YetAnotherLib
SOURCES
TestSource1.cpp
TestSource2.cpp
)

Inside the function definition we use cmake_parse_arguments to parse these
arguments, i.e. something like this:
function(add_test)
 cmake_parse_arguments(
 PARSED_ARGS
 ""
 "TARGET"
 "SOURCES;LIBRARIES;INCLUDES"
 ${ARGN}
)

If I now inspect the value of ${PARSED_ARGS_INCLUDES} I see the result I at
least expected, namely
"$;$".
This value is passed on to target_include_directories inside the function,
like so:
target_include_directories(${PARSED_ARGS_TARGET}
  PRIVATE ${PARSE_ARGS_INCLUDES}
)

It is this line that starts producing unexplainable errors that look like
this:
CMake Error in ../CMakeLists.txt:
  Found relative path while evaluating include directories of
  "TestName":

"PTARGET_PROPERTY:Lib1,INTERFACE_INCLUDE_DIRECTORIES>"

The first letter, here 'P', can be many letters, it seems some random
character appear here, including non-printable characters.

What am I looking at here? Are we using some functionality that was removed
or changed from CMake 3.5.2. From the release notes I don't see anything
that could be related.

Sincerely,
Jakob
-- 

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] Need a example to use dll in vs

[Jakob van Bethlehem]

Hej,

You really should provide more detailed information about your project
structure, and what is going wrong. There are some subtle differences
between Linux/Windows, but not at the level you're referring to. Certainly
the IMPORTED property has nothing to do with a platform distinction.
IMPORTED libraries work exactly the same on Windows/Linux.

There is a very big difference between Linux/Windows though in the sense
that on Windows you need to explicitly export symbols you want to be
available on the interface of the dll. My first guess from your very
limited info is that something is wrong in that area (and if that's the
case, you can easily resolve this using the GenerateExportHeader module).

But back to my original comment: provide more details on what you are
trying to do, and what is failing.

Sincerely,
Jakob van Bethlehem

On Mon, Apr 25, 2016 at 5:13 AM, Chaos Zhang <zcsd2...@gmail.com> wrote:

> Hi all,
>
> I faced a problem when i migrate a project from Linux to windows for the
> visual stdio seem can not use dll directly. I look through a number of
> material  and known i seem should use IMPORTED in add_library(...), but i
> can not find a practical example about how to use it. Could you please give
> me one or some? BTW the dll lib seem could be used in Mingw makefile on
> windows.
>
> Thanks,
> Chao Zhang
>
>
>
> --
> View this message in context:
> http://cmake.3232098.n2.nabble.com/Need-a-example-to-use-dll-in-vs-tp7593331.html
> Sent from the CMake mailing list archive at Nabble.com.
> --
>
> 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] find_package REQUIRED ignores OPTIONAL_COMPONENTS

[Jakob van Bethlehem]

Hm, interesting. I wonder then if Qt-devs are maintaining this, or the
CMake-devs? If the same bug is still present in Qt5, it should be fixed.

Sincerely,
Jakob

On Sun, Mar 20, 2016 at 8:37 PM, Alexander Stein <
alexander.stein+cm...@mailbox.org> wrote:

> On Tuesday 08 March 2016, 10:00:00 wrote Nicholas Braden:
> > Jakob, I don't think there is any confusion about what REQUIRED means.
> > Whether or not REQUIRED is provided, the list of OPTIONAL_COMPONENTS
> > should not be required under any circumstances. The example error
> > message seems pretty clear to me that the expected behavior and actual
> > behavior are different. I went and looked at the source code of the
> > find module:
> >
> > https://github.com/Kitware/CMake/blob/master/Modules/FindQt4.cmake
> >
> > It seems that there is no check whatsoever for
> > Qt4_FIND_REQUIRED_, so the find module just blindly assumes
> > that all components are required.
> >
> > More info:
> https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#find-modules
> >
> > To me this seems like a bug in the find module.
>
> Yep, FindQt4.cmake doesn't support OPTIONAL_COMPONENTS which seems only to
> work if FIND_PACKAGE_HANDLE_STANDARD_ARGS is called with HANDLE_COMPONENTS
> passed. This is not the case and does not work. I guess due to different
> naming scheme used for components. AFAICS they have to be e.g.
> Qt4_QtCore_FOUND, but not QT_QTCORE_FOUND.
>
> Best regards,
> Alexander
>
>
-- 

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] Some Visual Studio/CMake questions

[Jakob van Bethlehem]

Dear users,

Since about a year I work on a project that uses CMake in combination with
Visual Studio. This works kind of oke, but over time some questions have
emerged. Hopefully I can get an answer on this list:

* Our build infrastructure creates a Release and a Debug configuration by
setting the CMAKE_CONFIGURATION_TYPES variable. However, when switching
between these configurations, Visual Studio almost kills itself, and
becomes unresponding for quite some time. Is this a known issue with Visual
Studio and CMake-generated solutions? Or is there something we can do to
improve this?

* The generated solution file makes sure that CMake is ran again if any
change in one of the CMakeLists.txt file is detected. What we typically see
however, is that afterwards Visual Studio recompiles loads of files that
were not changed, and that were already compiled before. It seems that the
CMake run someone makes Visual Studio believe that all, or at least way too
many, files are out of date and need to be recompiled. We make use of a
Visual Studio plugin that provides a bunch of smart functions, which scans
the files in the solution in order to do its job. This plugin has the same
behaviour, so it seems like CMake is the common denominator causing
behaviour one wouldn't expect or want.
Same question: known issue, or something we can improve somehow?

* Over time I have seen a view times that it was mentioned that it is
possible to call the 'project()' function multiple times, and that this
will produce separate Visual Studio solution files. Interestingly, this is
documented absolutely nowhere. As a matter of fact, the documentation of
the 'project()' function clearly states that you should call that function
only once, and exactly once.

What about it? Is this some undocumented feature we can rely on? Or is this
a serious bug, that many people incidentally have come to rely upon. If
this is considered a feature, will this feature remain working for the
foreseeable future? If yes is the answer to these questions, what *exactly*
does this feature contain, so where *can* I get documentation? My main
question is whether it is possible to create dependencies between projects,
i.e. solution files, and will CMake generate calls to msbuild that will
automatically take care that dependencies between solution files are
handled properly?

Hopefully someone can help me out a bit here!

Sincerely,
Jakob van Bethlehem
-- 

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 REQUIRED ignores OPTIONAL_COMPONENTS

[Jakob van Bethlehem]

Hej Alexander,

Yes, you're missing a subtle detail. You assume that the 'REQUIRED' keyword
reflects the fact that COMPONENTS are required. This is not the case. The
REQUIRED keyword reflects that the entire package Qt4 is required, see
https://cmake.org/cmake/help/v3.0/command/find_package.html where it says:
'The REQUIRED option stops processing with an error message if the package
cannot be found'

Confusing, I agree.

Sincerely,
Jakob

On Fri, Mar 4, 2016 at 9:18 AM, Alexander Stein <
alexander.stein+cm...@mailbox.org> wrote:

> Hi,
>
> I want to use some required Qt component while others are optional.
> Apparently if you specify REQUIRED in find_package OPTIONAL_COMPONENTS is
> ignored.
> Here is a minimal CMakeLists.txt:
> project(test)
> cmake_minimum_required(VERSION 3.5)
>
> find_package(Qt4 REQUIRED COMPONENTS QtCore QtGui OPTIONAL_COMPONENTS
> Invalid)
>
> /home/alex/repo/cmake/build/bin/cmake --version
> cmake version 3.5.20160303-gf37f
>
> cmake fails with:
> CMake Error at
> /home/alex/repo/cmake/Modules/FindPackageHandleStandardArgs.cmake:148
> (message):
>   Could NOT find Qt4 (missing: QT_INVALID_INCLUDE_DIR QT_INVALID_LIBRARY)
>   (found version "4.8.7")
> Call Stack (most recent call first):
>   /home/alex/repo/cmake/Modules/FindPackageHandleStandardArgs.cmake:388
> (_FPHSA_FAILURE_MESSAGE)
>   /home/alex/repo/cmake/Modules/FindQt4.cmake:1333
> (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
>   CMakeLists.txt:4 (find_package)
>
> I expected that if required components are missing cmake bails out while
> continuing when OPTIONAL_COMPONENTS are missing. My current workaround is:
> find_package(Qt4 OPTIONAL_COMPONENTS Invalid)
> find_package(Qt4 REQUIRED COMPONENTS QtCore QtGui)
>
> But I would rather use a single line. Am I missing something here?
>
> Best regards,
> Alexander
>
> --
>
> 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] Compile shared library and call it's functions

[Jakob van Bethlehem]

Hej,

A short side-question - you mentioned you are compiling a DLL, yet you
mention also you are on OSX. I'd expect a .dylib on OSX?
Anywaysz, I think Andreas already answered your question quite clearly: you
probably misinterpret the output of nm, since your CMakeLists.txt file
looks exactly as it should.

Sincerely,
Jakob



On Mon, Mar 7, 2016 at 9:29 PM, Ivan  wrote:

> Hello!
> I hope someone could finally help me. I spent about two days to find
> solution for my problem, but with no luck.
>
> Here is my problem:
>
> I want to create a shared library (dll on Windows, .so on Linux, .dylib on
> OS X) that contains some functions. This library should export only these
> functions and nothing else. I guarantee that these function are pure C
> functions, so no C++ STL is needed to call them.
>
> Then I want to create an application that call functions from the shared
> library mentioned above. I mean that the application should not have these
> functions inside. I want OS linker to link the application with the library
> at runtime, when it initializes the application. I know, how to do this on
> Windows with Visual Studio: create DLL project, write functions and
> compile, then there will be two files: .dll and .lib, link the .lib file
> with the application and at runtime Windows will find the .dll. But how can
> I do so with CMake?
>
> Here is my CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.3)
> project(untitled19)
>
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
>
> set(LIBRARY_SRC library.cpp)
>
> add_library(libra SHARED ${LIBRARY_SRC})
>
> set(SOURCE_FILES main.cpp)
> add_executable(untitled19 ${SOURCE_FILES})
> target_link_libraries(untitled19 libra)
>
>
> This works and both library and executable are compiled. Unfortunately 
> library seems to be linked into the executable: ‘nm’ command shows that the 
> executable itself exports needed functions!
>
> I think there should be a solution for this, but I cannot find it. Can anyone 
> help me?
>
> For more clarification: I’m using OS X El Capitan.
>
> ——
>
> Best regards, Ivan.
>
>
>
>
> --
>
> 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] Cannot set FOLDER property to an interface (header-only) target

[Jakob van Bethlehem]

Hej,

Just re-read your question to make sure I understood, because I thought in the 
project I currently work in we had those targets, but not the problems. So I 
checked and realised we actually gotten rid of those INTERFACE libraries, 
because we encountered all kinds of trouble, amongst which one is the problem 
you refer to. Another problem for instance, is that INTERFACE link dependencies 
don’t get transferred like with normal libraries. Extremely annoying, so we 
decided the ‘academical’ use of an INTERFACE library wasn’t (nearly) worth the 
effort.

Not a resolution to your problem though ……

Sincerely, Jakob


> On 02 Jan 2016, at 13:12, Klaim - Joël Lamotte <mjkl...@gmail.com> wrote:
> 
> 
> 
> On 1 January 2016 at 11:00, Jakob van Bethlehem <jsvanbethle...@gmail.com 
> <mailto:jsvanbethle...@gmail.com>> wrote:
> Hej Joël,
> 
> The command you’re looking for is ‘source_group’, see 
> https://cmake.org/cmake/help/v3.0/command/source_group.html 
> <https://cmake.org/cmake/help/v3.0/command/source_group.html>
> 
> 
> I use this already but it works only with source files, not with targets. 
> With targets you need to set the FOLDER property.
>  
> Sincerely,
> Jakob
> 
> 
>> On 30 Dec 2015, at 20:52, Klaim - Joël Lamotte <mjkl...@gmail.com 
>> <mailto:mjkl...@gmail.com>> wrote:
>> 
>> The following CMake script:
>> 
>> cmake_minimum_required(VERSION 3.4)
>> 
>> add_library( mylib INTERFACE )
>> set_property( TARGET mylib PROPERTY FOLDER /some/dir )
>> 
>> 
>> Will trigger this error on configuration:
>> 
>> CMake Error at CMakeLists.txt:4 (set_property):
>>   INTERFACE_LIBRARY targets may only have whitelisted properties.  The
>>   property "FOLDER" is not allowed.
>> 
>> 
>> This prevent any interface library to be organized in Visual Studio virtual 
>> folders.
>> Unfortunately it also mean that header-only targets can't be organized.
>> 
>> I have no idea how this should be solved. Should the property just be 
>> white-listed?
>> Or should a better have a another specific library mode for header-only 
>> targets?
>> 
>> Is there any workaround?
>> 
>> Joël Lamotte
>> 
>> -- 
>> 
>> Powered by www.kitware.com <http://www.kitware.com/>
>> 
>> Please keep messages on-topic and check the CMake FAQ at: 
>> http://www.cmake.org/Wiki/CMake_FAQ <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 
>> <http://cmake.org/cmake/help/support.html>
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html 
>> <http://cmake.org/cmake/help/consulting.html>
>> CMake Training Courses: http://cmake.org/cmake/help/training.html 
>> <http://cmake.org/cmake/help/training.html>
>> 
>> Visit other Kitware open-source projects at 
>> http://www.kitware.com/opensource/opensource.html 
>> <http://www.kitware.com/opensource/opensource.html>
>> 
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake 
>> <http://public.kitware.com/mailman/listinfo/cmake>
> 
> --
> 
> Powered by www.kitware.com <http://www.kitware.com/>
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ <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 
> <http://cmake.org/cmake/help/support.html>
> CMake Consulting: http://cmake.org/cmake/help/consulting.html 
> <http://cmake.org/cmake/help/consulting.html>
> CMake Training Courses: http://cmake.org/cmake/help/training.html 
> <http://cmake.org/cmake/help/training.html>
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html 
> <http://www.kitware.com/opensource/opensource.html>
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake 
> <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] Cannot set FOLDER property to an interface (header-only) target

[Jakob van Bethlehem]

Hej Joël,

The command you’re looking for is ‘source_group’, see 
https://cmake.org/cmake/help/v3.0/command/source_group.html 


Sincerely,
Jakob


> On 30 Dec 2015, at 20:52, Klaim - Joël Lamotte  wrote:
> 
> The following CMake script:
> 
> cmake_minimum_required(VERSION 3.4)
> 
> add_library( mylib INTERFACE )
> set_property( TARGET mylib PROPERTY FOLDER /some/dir )
> 
> 
> Will trigger this error on configuration:
> 
> CMake Error at CMakeLists.txt:4 (set_property):
>   INTERFACE_LIBRARY targets may only have whitelisted properties.  The
>   property "FOLDER" is not allowed.
> 
> 
> This prevent any interface library to be organized in Visual Studio virtual 
> folders.
> Unfortunately it also mean that header-only targets can't be organized.
> 
> I have no idea how this should be solved. Should the property just be 
> white-listed?
> Or should a better have a another specific library mode for header-only 
> targets?
> 
> Is there any workaround?
> 
> Joël Lamotte
> 
> -- 
> 
> 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] Feature request: expose curl to cmake -E

[Jakob van Bethlehem]

> 
> I thought 'curl' is sort of at the level of 'tar', in being a useful
> tool that could be exposed fairly easily in a cmake portable command.

Have you ever checked out the full man page of curl and the full feature list? 
(http://curl.haxx.se/docs/manpage.html)
This is certainly not ‘easy’ to simply port ;-)

Sincerely,
Jakob

-- 

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] CMake, QT5 and cross compilation

[Jakob van Bethlehem]

Maybe you can do something with the ‘HINTS’ option to find_package()?
https://cmake.org/cmake/help/v3.4/command/find_package.html

Sincerely,
Jakob

> On 17 Dec 2015, at 18:03, Hauke Krüger  wrote:
> 
> Hi everybody,
> 
> I have a project which builds to realize a Qt5 application. I use the
> latest CMAKE Qt5 mechanisms such as AUTOMOC etc with good success.
> 
> The project builds on Raspberry Pi if cmake is run on the Raspberry Pi
> itself since all Qt tools are available and run also on the Raspberry Pi.
> 
> Lately, I wanted to compile this project in a cross compile approach.
> For this purpose, I mount the Raspberry Pi file system to be part of the
> directory tree on my host Linux PC.
> Of course, I use find_package to locate the Qt5 package in the directory
> branch related to the Raspberry Pi. The corresponding
> moc, uic and rcc tools have been built for arm. Therefore, I can not
> run the moc from the location as reported by find_package in the cross
> build approach.
> 
> So, here is my question: How can I overwrite the moc-executable (and uic
> etc) path to use another moc version than the one found by the
> find_package mechanism? If I use the moc which is part of my Linux host
> PC rather than the arm compiled moc in the Raspberry file system, the
> code generation should be fine, and afterwards, I will link against the
> Raspberry Pi Qt5 libraries.
> 
> Thank you for any help and best regards
> 
> Hauke
> 
> -- 
> 
> 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] Feature request: expose curl to cmake -E

[Jakob van Bethlehem]

Depending on what you precisely wish to achieve, maybe file(DOWNLOAD) already 
fits your needs?
https://cmake.org/cmake/help/v3.1/command/file.html

Sincerely,
Jakob van Bethlehem

> On 18 Dec 2015, at 19:59, iosif neitzke <iosif.neitzke+cm...@gmail.com> wrote:
> 
> It would be nice to have curl as a platform-independent command like
> 'md5sum', 'tar', and 'compare_files'.
> -- 
> 
> 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] Forcing CMake to rerun

[Jakob van Bethlehem]

Hej,

My first guess would be to have a look at the add_custom_command() function. 
One of the possible invocations of that function creates a target of which the 
outputs are always considered out-of-date (well, if memory serves me correctly, 
it seems cmake.org is currently down so I can’t double check).

Anyways, if the ‘command’ you wish to run is actually a CMake script, have a 
look at the ‘cmake -P’ option. This allows you to run CMake scripts as a custom 
command.

Sincerely,
Jakob

> On 10 Dec 2015, at 22:26, Nicholas Clark  wrote:
> 
> Hi all,
> 
> I'm working on using CMake to create a build system that targets an 
> incredibly hard-to-deal-with IDE/build system, used for doing some embedded 
> programming (Xilinx's Vivado suite).
> 
> One of the pieces I need to get working is a conditional dependency between 
> two files (a project-file generator script that gets archived in Git, and the 
> actual project files that get generated).
> 
> The graph basically looks like this:
> 
> Path 1: .tcl file (in Git) -> .xpr file (used by IDE)
> Path 2: .xpr file (after a user changes something in the IDE) -> .tcl file 
> (needs to be regenerated)
> 
> So on any clean build, the source-controlled TCL file autogenerates a bunch 
> of required project files. On iterative builds at a developer's desk, he 
> might change some IDE setting and then the TCL file needs to be regenerated 
> (without triggering a rebuild of the project files as well). It's kind of a 
> conditional and/or psuedo-circular dependency.
> 
> In pure GNU Make, I can express a conditional dependency with an 'if' 
> statement that uses timestamp checks. It's also easy for me to express this 
> dependency in CMakeLists.txt - I can check the file timestamps, and I can 
> conditionally emit the relevant custom_target/custom_rule. 
> 
> That only works when CMakeLists.txt gets parsed, however. Is there any way 
> for me to force a CMake-generated Makefile to _always_ rerun CMake before 
> trying to build the 'all' target? If not, is there any other clever way that 
> I could express this conditional dependency?
> 
> -Nick
> 
> 
> 
> -- 
> 
> 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] getting paths of header files

[Jakob van Bethlehem]

Hej,

A quick glance doesn't show anything out of the ordinary, except that
* I'd prevent any use of `..` in your folder references (by using things
like $ and
$
* I think it is more or less standard practice now to _not_ use
'include_directories', but instead use target_include_directories()
* you'

On Sun, Oct 18, 2015 at 11:58 PM, Owen Alanzo Hogarth 
wrote:

> I am having some trouble with my cmake build. I recently redesigned the
> physical layout of my files so that it'll be a bit easier to maintain in
> the long run.
>
> I have my project structure setup like this.
>
> MAIN_PROJECT/
> project/main.c # this is the executable
> resources/...# a folder filled with resources
> source/
> source/moduleA/moduleA.h #includes all headers for this module
>  #a user would just import
> moduleA.h
>
> source/moduleA/headers/header1.h header2.h
> source/moduleA/src/source1.c  source2.c
> source/moduleA/common/common_structs.h #holds common structs for
>
> #all src files in this module
>
>
> with my project re-organized like this and try to build my shared
> libraries I get no output.
>
> For example main cmakelists.txt file
>
> PROJECT(project)
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
>
> SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY $(CMAKE_BINARY_DIR)/lib)
> SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY $(CMAKE_BINARY_DIR)/lib)
> SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY $(CMAKE_BINARY_DIR)/bin)
>
> SET(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake_modules)
>
> ADD_SUBDIRECTORY(source)
>
> FILE(COPY ${CMAKE_CURRENT_SOURCE_DIR}/resources/ DESTINATION
> ${CMAKE_CURRENT_BINARY_DIR}/bin/resources/)
>
> this is one module within the source folder, a matrix4
>
> PROJECT(matrix4_scalar)
>
> INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../common")
>
> INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h")
>
> SET(HEADER_FILES "${CMAKE_CURRENT_SOURCE_DIR}/../common/common_structs.h"
> "${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h")
>
>
> SET(SRC_FILES src/matrix4_scalar.c ${HEADER_FILES})
>
> ADD_LIBRARY(matrix4_scalar SHARED ${SRC_FILES})
>
> TARGET_LINK_LIBRARIES(matrix4_scalar vector3_scalar)
>
>
>
> The vector3 class is built in a similar way but has no outside
> dependencies except for the common_struct.h header file.
>
> This matrix class depends on the vector3 class so I have it as a target
> link library.
>
> When I build like this I get no output to my lib directories and I am not
> sure what's going on.
>
> --
>
> 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] getting paths of header files

[Jakob van Bethlehem]

Damn. send the unfinished message, I'll repeat what I had, and type the
rest:

Hej,

A quick glance doesn't show anything out of the ordinary, except that
* I'd prevent any use of `..` in your folder references (by using things
like $<TARGET_PROPERTY:vector3_scalar,INCLUDE_DIRECTORIES> and
$<TARGET_PROPERTY:vector3_scalar,INTERFACE_INCLUDE_DIRECTORIES>
* I think it is more or less standard practice now to _not_ use
'include_directories', but instead use target_include_directories()
* you do add_subdirectory(source), but don't show the lists-file in that
folder, which may cause the problem you're seeing

The first thing I see that seems really wrong though, is that you type the
'project()' command twice. AFAIK you're supposed to use this command
exactly once, to set the properties of the entire project. Using it
multiple times causes undefined behaviour, and may very well be the cause
for what you're seeing

Sincerely,
Jakob


On Mon, Oct 19, 2015 at 8:34 AM, Jakob van Bethlehem <
jsvanbethle...@gmail.com> wrote:

> Hej,
>
> A quick glance doesn't show anything out of the ordinary, except that
> * I'd prevent any use of `..` in your folder references (by using things
> like $<TARGET_PROPERTY:vector3_scalar,INCLUDE_DIRECTORIES> and
> $<TARGET_PROPERTY:vector3_scalar,INTERFACE_INCLUDE_DIRECTORIES>
> * I think it is more or less standard practice now to _not_ use
> 'include_directories', but instead use target_include_directories()
> * you'
>
> On Sun, Oct 18, 2015 at 11:58 PM, Owen Alanzo Hogarth <gurenc...@gmail.com
> > wrote:
>
>> I am having some trouble with my cmake build. I recently redesigned the
>> physical layout of my files so that it'll be a bit easier to maintain in
>> the long run.
>>
>> I have my project structure setup like this.
>>
>> MAIN_PROJECT/
>> project/main.c # this is the executable
>> resources/...# a folder filled with resources
>> source/
>> source/moduleA/moduleA.h #includes all headers for this module
>>  #a user would just import
>> moduleA.h
>>
>> source/moduleA/headers/header1.h header2.h
>> source/moduleA/src/source1.c  source2.c
>> source/moduleA/common/common_structs.h #holds common structs for
>>
>> #all src files in this module
>>
>>
>> with my project re-organized like this and try to build my shared
>> libraries I get no output.
>>
>> For example main cmakelists.txt file
>>
>> PROJECT(project)
>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
>>
>> SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY $(CMAKE_BINARY_DIR)/lib)
>> SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY $(CMAKE_BINARY_DIR)/lib)
>> SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY $(CMAKE_BINARY_DIR)/bin)
>>
>> SET(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake_modules)
>>
>> ADD_SUBDIRECTORY(source)
>>
>> FILE(COPY ${CMAKE_CURRENT_SOURCE_DIR}/resources/ DESTINATION
>> ${CMAKE_CURRENT_BINARY_DIR}/bin/resources/)
>>
>> this is one module within the source folder, a matrix4
>>
>> PROJECT(matrix4_scalar)
>>
>> INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../common")
>>
>> INCLUDE_DIRECTORIES("${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h")
>>
>> SET(HEADER_FILES "${CMAKE_CURRENT_SOURCE_DIR}/../common/common_structs.h"
>> "${CMAKE_CURRENT_SOURCE_DIR}/../vector3_scalar/headers/vector3_scalar.h")
>>
>>
>> SET(SRC_FILES src/matrix4_scalar.c ${HEADER_FILES})
>>
>> ADD_LIBRARY(matrix4_scalar SHARED ${SRC_FILES})
>>
>> TARGET_LINK_LIBRARIES(matrix4_scalar vector3_scalar)
>>
>>
>>
>> The vector3 class is built in a similar way but has no outside
>> dependencies except for the common_struct.h header file.
>>
>> This matrix class depends on the vector3 class so I have it as a target
>> link library.
>>
>> When I build like this I get no output to my lib directories and I am not
>> sure what's going on.
>>
>> --
>>
>> 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
>>
&

Re: [CMake] cmake install behaviour with git

[Jakob van Bethlehem]

Hej,

> 
> Now install behaves differnt, cause cmake checks only file time difference. 
> Files previously overwritten are now
> considered Up-to-date

Why would you want to overwrite files that have not changed? 

> Has anyone found a solution for this after a git migration?

We’re using CMake with git without any trouble - no solution to be found. The 
install target works flawlessly and as expected.

I think you’ll need to provide some more details about what you’re doing. Are 
you by any chance doing in-source builds? Why are you so focussed on 'git 
clone’? That is the kind of thing you would do once, and then almost never 
again, so I don’t see how that can be related to running an install target.

Sincerely, Jakob



-- 

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] FindGit.cmake proposal

[Jakob van Bethlehem]

Hej,
> 
> if this is not the "right way" of proposing such things, where to go to?
> 

Pretty simple if you have a look at the website 
http://www.cmake.org/get-involved/  - 
you’ll need to send patches to the dev-list

Sincerely,
Jakob-- 

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] Generated .rc files silently ignored

[Jakob van Bethlehem]

Hej,

Some more information about how you setup things would be useful. For instance: 
you would need to add the filename of the generated .rc file to the 
executable/library for which it is generated: are you doing that?

In the application I currently work on, we have created a small function to 
wrap the generation of the .rc file. I just checked that we actually also build 
a full path. That actually makes sense, because the generated file is put in 
the ${CMAKE_CURRENT_BINARY_DIR} and *not* in the current source dir. In other 
words: we could never accomplish this with any type of ‘relative’ path anyway. 
Are you maybe also mixing up the *SOURCE_DIR and *BINARY_DIR?

Sincerely,
Jakob

> On 07 Sep 2015, at 13:08, Mueller-Roemer, Johannes Sebastian 
>  wrote:
> 
> While adding versioning info to a  .dll I noticed that .rc files that are 
> generated (via configure_file) are silently being ignored. Adding them via an 
> absolute path works, but using a relative leads to it being ignored.
>  
> Is this a bug or is this by design? At the very least just silently ignoring 
> it seems wrong.
>  
> --
> Johannes S. Mueller-Roemer, MSc
> Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
>  
> 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 
> 
>  
> -- 
> 
> 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] Object targets and link libraries

[Jakob van Bethlehem]

Hej,

Did you notice this one?
https://public.kitware.com/Bug/bug_relationship_graph.php?bug_id=14778=relation
 


Also, since you’re asking about a ‘why’, you could check out this thread:
http://public.kitware.com/pipermail/cmake-developers/2015-February/024518.html 


The less involved option would be to do exactly what you mention you don’t 
want. You don’t mention why you don’t want to create a separate library though, 
which may be of importance to guess a different solution.

Sincerely, Jakob

> On 09 Sep 2015, at 15:02, Daniel Wirtz 
>  wrote:
> 
> Hey all,
> 
> i've been wondering why CMake (3.3.+) yells at me if i want to add link 
> libraries to an OBJECT target.
> Consider the scenario
> 
> find_package(package_with_bar_target)
> 
> add_library(foo OBJECT ${foo_src})
> 
> # Would like to write
> 
> # target_link_libraries(foo bar)
> 
> # But have to use
> 
> target_include_directories(foo PRIVATE 
> $)
> 
> 
> I know that intuitively "link library" is something different than "include 
> directory". but one of the nice things
> of cmake is that it automatically sorts out everything for you when you 
> specify link libraries.
> if there are more bar-dependent properties that need to be set in order to 
> successfully compile foo (e.g. compile flags),
> i have to literally re-write all the nice internal cmake logic to establish 
> the compile environment of bar for foo.
> 
> what's the plan with that? or are there any other (less involved) solutions? 
> i need the objects of foo inside a larger
> target and want to avoid having a separate library being build that needs 
> extra linking.
> 
> cheers!
> 
> -- 
> Dr. Daniel Wirtz
> Dipl. Math. Dipl. Inf.
> SRC SimTech
> Pfaffenwaldring 5a
> +49 711 685 60044
> 
> -- 
> 
> 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] Subclass of external library: unresolved external symbol

[Jakob van Bethlehem]

Hej,

Seems to me at first sight you didn’t implement the New() function

Greetsz, Jakob

> On 01 Sep 2015, at 22:02, Marcos  wrote:
> 
> Hi,
> 
> I can use and include VTK libraries in my project, but I did a 
> vtkInteractorStyleImage subclass, just overriding a method:
> 
> 
> #ifndef dcmInteractorStyleImage_h
> #define dcmInteractorStyleImage_h
> 
> #include "vtkInteractionStyleModule.h" // For export macro
> #include "vtkInteractorStyleImage.h"
> 
> class VTKINTERACTIONSTYLE_EXPORT dcmInteractorStyle : public 
> vtkInteractorStyleImage
> {
> public:
>   static dcmInteractorStyle *New();
>   vtkTypeMacro(dcmInteractorStyle, vtkInteractorStyleImage);
> 
>   virtual void OnLeftButtonDown();
> 
>   void PrintSelf(ostream& os, vtkIndent indent);
> };
> 
> 
> #endif
> 
> 
> The thing is I use it in a Qt class. So I include this in my CMakeLists.txt:
> 
> set(GENERIC_VIEW_CPP
>  View/UI/dcminteractorstyle.cpp
> )
> 
> SET(GENERIC_VIEW_H
>  View/UI/dcminteractorstyle.h
> )
> 
> add_library(generic ${GENERIC_VIEW_CPP} ${GENERIC_VIEW_H})
> ...
> add_library(ui_qt ${UI_QT_CXX}
>  ${UI_FORM_HEADERS} ${UI_RESOURCES_RCC}
>  ${MODEL_WRAPPED_HEADERS}
>  ${GENERIC_VIEW_CPP} ${GENERIC_VIEW_H} #necesary here?
> )
> qt5_use_modules(ui_qt Core Gui Widgets)
> ...
> set_source_files_properties(${UI_RESOURCES_RCC} PROPERTIES GENERATED ON)
> add_executable(UtilidadDICOM WIN32 main.cpp ${UI_RESOURCES_RCC})
> target_link_libraries(UtilidadDICOM
> model
> ui_qt
> generic
> ${Glue}
> ${VTK_LIBRARIES}
> ${ITK_LIBRARIES}
> )
> --
> The error trying to compile:
> ui_qt.lib(viewerwidget.cpp.obj):-1: error: LNK2019: unresolved external 
> symbol "public: static class dcmInteractorStyle * __cdecl 
> dcmInteractorStyle::New(void)" (?New@dcmInteractorStyle@@SAPAV1@XZ) 
> referenced in function "public: static class vtkSmartPointer dcmInteractorStyle> __cdecl vtkSmartPointer dcmInteractorStyle>::New(void)" 
> (?New@?$vtkSmartPointer@VdcmInteractorStyleSA?AV1@XZ)
> 
> ui_qt is a library declared in CMake, as you can see above.
> 
> Any ideas? Thank you.
> -- 
> 
> 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] Prefix header for Makefiles

[Jakob van Bethlehem]

Hej Andrew,

CMake does never scan source files (as far as I know), as it is not a compiler. 
From your question it almost seem you are making this assumption, so I just 
wanted to make sure to mention at least this.

Then, for your particular issue: two things that come to my mind:
* I’d imagine you have somewhere a add_executable(main Main.cpp Prefix.h 
DependHeader.h) - as far as I can tell, the only thing that really matters, is 
that the main executable gets recompiled whenever you make a change in any of 
the headers. To put it differently, I *don’t* think you (should) need the 
OBJECT_DEPENDS.
* If you’re worried about scaling, maybe you could have a look at the file(GLOB 
) command. However, be sure to also carefully read the potential problems with 
that approach. In my current (big) project, we explicitly list each source file 
for most parts of the source tree. In practice you’re surely *not* going to add 
all 50 new files at once. It is a very simple thing to add the newly created 
file to some variable in the correct CMakeLists.txt file. You just have to 
remember to do it, it’s really not a big deal.

By the way, we’re actually using the PrecompiledHeader script - it works 
flawlessly.

Sincerely, Jakob 

 On 26 Aug 2015, at 11:48, Andrew Shaitorov andrew.shaito...@gmail.com wrote:
 
 Hi All!
 
 I have a very annoying problem with CMake Makefiles generator.
 
 I'm using prefix header (see attached archive for minimized test).
 
 There is one source file named Main.cpp and two header files: Prefix.h and 
 DependHeader.h. Prefix.h includes DependHeader.h and Main.cpp includes 
 Prefix.h by using prefix header compiler flag (-include for GCC/Clang and /FI 
 for MSVC):
 
   set_source_files_properties(Main.cpp PROPERTIES
   COMPILE_FLAGS -include Prefix.h
   OBJECT_DEPENDS ${CMAKE_CURRENT_LIST_DIR}/Prefix.h)
 
 When I change Prefix.h, then make recompiles Main.cpp as needed. But when I 
 make a change in DependHeader.h, then no recompilation happens. Its clear for 
 me that I have to specify all depend files in OBJECT_DEPENDS option, but in 
 real project there may be a lot of depend files with nested includes. And the 
 most annoying thing is that the project compiles without any errors and may 
 just crash because of struct layout or other critical changes in depend 
 headers.
 
 I seems like the following script have the same problem when using 
 FORCE_INCLUDE option:
 
 https://github.com/larsch/cmake-precompiled-header/blob/master/PrecompiledHeader.cmake
  
 https://github.com/larsch/cmake-precompiled-header/blob/master/PrecompiledHeader.cmake
 
 I looked in CMake source code and didn't find a way to add Prefix.h in a list 
 for dependency scanning. Also I don't know how to run depend scanner on 
 Prefix.h in CMake script to generate a list of all depend files for 
 OBJECT_DEPENDS option.
 
 Any advise?
 
 Best,
 Andrew.
 
 CMakePrefixHeaderTest.zip-- 
 
 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] [CPack]Call

[Jakob van Bethlehem]

Barth,

Personally I have no experience at all with packaging through CMake, but 
presumably you’ll need something like a CPackConfig.cmake in the top level 
folder?

Beyond that, I think you’ll need to provide a bit more details about your 
environment. My guess is you work on linux, as the setup you provide and the 
behaviour you describe wouldn’t work on Windows with Visual Studio for 
instance. Thinking a bit more, actually I think there is nothing in CMake that 
allows you to do the ‘make’, ‘make test’ etc both from the top level as well as 
the sub projects. My feeling is you did some magic in the top level to make 
this happen. You’ll need to provide some details for others to be able to help 
you further


Sincerely,
Jakob

 On 18 Aug 2015, at 09:54, Barthelemy Von Haller 
 barthelemy.von.hal...@cern.ch wrote:
 
 
 Barthelemy Von Haller Barthelemy.Von.Haller@... writes:
 
 
 
 Hello,
 
 I have a projects looking like this : 
 Repo
 .
 ├── CMakeLists.txt
 ├── ProjA
 │   ├── cmake
 │   │   └── CPackConfig.cmake
 │   ├── CMakeLists.txt
 │   ├── doc
 │   ├── include
 │   ├── src
 │   └── test
 ├── ProjB
 │   ├── cmake
 │   │   └── CPackConfig.cmake
 │   ├── CMakeLists.txt
 │   ├── doc
 │   ├── include
 │   ├── src
 │   └── test
 └── More projects...
 Each project (ProjA, ProjB, ...) is buildable on its own. It can be
 tested, installed and packaged alone.
 
 I want to be able to do the same from the top directory as well. In this
 case, it would apply the target to all subprojects.
 
 It works fine for make, make test, make install but not for make
 package. With the latter, only the last project is packaged not the others.
 
 Is there a clean way to call CPack from the top directory ?
 Thank you, 
 Barthelemy
 
 
 
 
 Dear all, 
 
 I did not get any reply to my enquiry about running make package from a
 top directory containing several sub projects. 
 
 Does anyone has an idea ? 
 
 Best regards,
 Barth
 
 -- 
 
 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] Rerun CMake partially in Visual Studio

[Jakob van Bethlehem]

 
 Yes, things like QtCreator.  Or future IDEs that might use CMake as a build 
 system.
 

FYI: CLion by Jetbrains is the first IDE I know of that fully integrates CMake 
natively. If that IDE is as good as their Python IDE I worked with in the past, 
I may yet spend some bucks on it :)

Sincerely,
Jakob

-- 

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] Rerun CMake partially in Visual Studio

[Jakob van Bethlehem]

Dear users,

CMake has a very nice integration with Visual Studio. One problem I often
encounter with reasonably large solutions is that one I change only one
CMakeLists.txt file, the full solution gets regenerated. Would it possible
somehow to *only* regenerate the project(s) that are affected by the
CMakeLists.txt file I changed?

Sincerely,
Jakob
-- 

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] Exporting/Publishing settings (e. g. include directories) from subdirectories

[Jakob van Bethlehem]

Hej Rainer,

 
 project-dir
 +- component1
 |  +- src
 |  +- include-dir1
 |  +- include-dir2
 +- component2
 
 Let's say I want component2 to add include-dir1 and include-dir2
 from component1 as include directories without component2 knowing
 that these two directories exist.
 

There is no way this is possible afaik, because if component2 uses any header 
file in one of the include directories, you would need to pass these 
directories to your compiler (most of the times using a -I or /I option 
depending on the OS).

However,
is it maybe possible that what you’re *really* asking is, whether it would be 
possible to say something like:
target_link_libraries(component1 component2)
*without* explicitly spilling out the include directories, which would look 
something like:
target_include_directories(component1 PRIVATE 
$OBJECT_PROPERTY:component1,INTERFACE_INCLUDE_DIRECTORIES)
 then the answer would be ‘yes’. You’d need to study the concept of IMPORTed 
and EXPORTed targets in CMake, see for instance 
http://www.cmake.org/cmake/help/v3.0/command/add_executable.html 
http://www.cmake.org/cmake/help/v3.0/command/add_executable.html, 
http://www.cmake.org/cmake/help/v3.0/command/add_library.html 
http://www.cmake.org/cmake/help/v3.0/command/add_library.html and 
http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets 
http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets

These concepts were originally created to nicely handle external dependencies 
(check out for instance the Qt5 documentation on integration with CMake, see 
http://doc.qt.io/qt-5/cmake-manual.html - you simply link with the proper Qt5 
library, and these are set up such that automatically all required include 
folders are added to the list of include locations to build your component). 
However, with some work (essentially, creating some wrapper functions/macros) 
it can just as easily be made to work for dependencies inside a project. I 
don’t know about details, I just know that the infrastructure guys in the team 
I’m working in, made it work like that (borrowing a lot from the CMake files 
that come with Qt5) and it works like a charm!

 Therefore my question: Is there a way to import project
 settings/properties which have been exported from other
 subdirectories? And is cmake intended to be used like that?
 
 I don't know whether I use the correct terms here but I hope that the
 idea is clear.

If you meant to ask what I wrote above, then the question was entirely correct, 
but the idea clear (in particular because I use it that way) and yes, there is 
a way. Whether CMake is ‘intended to be used like that I really wouldn’t know. 
My feeling is that this is definitely not the original intention of the 
feature. However, looking at how it works, this approach certainly also will 
not break as long as the feature is there.

Sincerely,
Jakob van Bethlehem-- 

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] Windows CE deployment of additional files to the device

[Jakob van Bethlehem]

Hej Jochen,

My first guess would be to have a look at the add_custom_command(TARGET ) 
function, see 
http://www.cmake.org/cmake/help/v3.0/command/add_custom_command.html 
http://www.cmake.org/cmake/help/v3.0/command/add_custom_command.html. In your 
situation this would work out something like the following:
add_custom_command(TARGET DeploymentTool POST_BUILD 
   COMMAND cmake -E copy Library.dll 
c:\localDir\l$ENV{CSIDL_PROGRAM_FILES}\KepapTest
)

This is just guessing at the details - in particular I don’t know from the top 
of my head if you can acces CSIDL_PROGRAM_FILES from within CMake. But I think 
this could you get started at least.

Sincerely,
Jakob


 On 10 Jul 2015, at 21:23, Jochen Baier em...@jochen-baier.de wrote:
 
 Hi,
 
 Window CE Visual Studio 2008 projects have the option to specify additional 
 files to deploy to the connected device after the build process (and before 
 executing). For example needed DLLs. The part in the .vsproj looks like that:
 
 DeploymentTool
   ForceDirty=-1
   RemoteDirectory=
   RegisterOutput=0

 AdditionalFiles=Library.dll|c:\localDir\|%CSIDL_PROGRAM_FILES%\KepapTest/
 
 Do somebody know if can generate this withs CMake?
 
 
 Thanks Jochen
 -- 
 
 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] Putting ctest in a 'watch' mode?

[Jakob van Bethlehem]

Dear users,

While developing a bunch of tests, I started wondering whether it is possible 
to put ctest in a kind of ‘watch’ mode, where it is continuously watching a set 
of test executable, and automatically running any (or all) of them when the 
compiler creates a new version of the test executable.

I’m working with cmake 3.2.2 on Windows 7, the compiler is mdvc 2013. I have 
been looking through cmake --help, but I couldn’t find anything obvious there.

Sincerely,
Jakob van Bethlehem

-- 

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] Problems with combo CMake/MSVC2013/Qt5

[Jakob van Bethlehem]

Hello,

Thanks for the quick reply!

On Tue, Feb 24, 2015 at 7:54 PM, Stephen Kelly steve...@gmail.com wrote:

 Jakob van Bethlehem wrote:

  Dear users,

set(CMAKE_PREFIX_PATH C:/Qt/Qt5.4.0/5.4/msvc2013_64_opengl/lib/cmake)

 Don't do this. Pass CMAKE_PREFIX_PATH as an argument to cmake.


Good point; currently I'm in kind of a proof-of-concept phase, but I'll
make this change asap



  The CMakeLists.txt file in the subfolder looks like this:
 
CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0)

 This has effects you probably don't intend. I suggest removing it.

  http://www.cmake.org/cmake/help/v3.1/manual/cmake-policies.7.html


Hm, that's new to me, especially because the examples-page does not mention
this. Alas, something learned today!



  The problem: for some reason when compiling mymain.cpp I get:
fatal error C1083: Cannot open include file: 'mylib_export.h': No such
  file or directory
 
  I already checked that the build-folder is added as an include directory,

 The build folder of the top-level is added as an include directory. Your
 export.h file is in the subdirectory.

 No, the mylib_export.h is created in the top-level build folder, which, as
you mentioned, is added as an include directory as expected. It is
_included_ though from a subdirectory, but AFAIK that shouldn't make a
difference (not that I remember from my Linux experience at least)

Sincerely,
Jakob van Bethlehem
-- 

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] Problems with combo CMake/MSVC2013/Qt5

[Jakob van Bethlehem]

Dear users,

It has been a while since I used CMake and it's the first time I'm using it
on Windows/MSVC2013, so hopefully I'm not missing something obvious. I
tried to create the most basic example that shows the problem.

I'm trying to compile a subfolder of my Qt5 project into a shared library.
The CMakeLists.txt file in the main folder looks like:

  CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0)
  PROJECT(qtapp)

  set(CMAKE_PREFIX_PATH C:/Qt/Qt5.4.0/5.4/msvc2013_64_opengl/lib/cmake)
  FIND_PACKAGE(Qt5Widgets REQUIRED)
  FIND_PACKAGE(Qt5Core REQUIRED)
  SET(CMAKE_AUTOMOC ON)
  SET(CMAKE_INCLUDE_CURRENT_DIR ON)

  add_subdirectory(mylib)

  add_executable(mymain WIN32 mymain.cpp)
  target_link_libraries(mymain mylib)

The CMakeLists.txt file in the subfolder looks like this:

  CMAKE_MINIMUM_REQUIRED(VERSION 3.0.0)
  FILE(GLOB lib_sources *.cpp *.h)
  ADD_LIBRARY(mylib SHARED ${lib_sources})
  TARGET_LINK_LIBRARIES(mylib Qt5::Widgets)

  include(GenerateExportHeader)
  generate_export_header(mylib)

Inside the subfolder I have one header file mylib.h:

  #pragma once
  #include mylib_export.h

  class MYLIB_EXPORT MyClass
  {
  public:
  MyClass();

  };

And there is one source file mylib.cpp:

  #include myclass.h

  MyClass::MyClass()
  {}

In the main file mymain.cpp in the main folder I try to instantiate an
object:

  #include mylib/myclass.h
  int main()
  {
  MyClass klass();
  }

I create a 'build' folder, where I execute 'cmake -G Visual Studio 12 2013
Win64 ..'; subsequently I open the resulting solution file, which I try to
build.

The problem: for some reason when compiling mymain.cpp I get:
  fatal error C1083: Cannot open include file: 'mylib_export.h': No such
file or directory

I already checked that the build-folder is added as an include directory,
both to the main-project and to the library-project. I already noticed that
compilation will succeed if I #include explicitly from the build directory
inside mylib.h (#include ../build/mylib/mylib_export.h) but that
obviously is not my intention.

What am I doing wrong or what did I miss? Any ideas?

Sincerely,
Jakob van Bethlehem
-- 

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] How to compile MPI code

[Jakob van Bethlehem]

Hm... this is the CMake user list, not the MPI-user list. You're 
posing your question on the wrong list.

(but how did you compile? Did you use mpicc?)

Sincerely,
Jakob

On 06/22/2011 02:25 PM, Mª Dolores Villalobos Ortiz wrote:

 What do you mean with it doesn't run correctly? Does it not even
start? How do you start your program?

--

My program's code is:

#include iostream
using namespace std;
#include mpi.h

int main( int argc, char * argv[] )
{

int node;
int num_nodes;
int i, buf;

MPI::Init(argc, argv);
node = MPI::COMM_WORLD.Get_rank();
num_nodes = MPI::COMM_WORLD.Get_size();

std::cout  I am node   node  std::endl;

if ( node == 0 ) {
std::cout  I am node   node  std::endl;
std::cout  Num threads (Get_size) -   num_nodes  std::endl;
}
else
{
std::cout  I am node   node  std::endl;
}
MPI_Finalize();
return 0;
}
--

And, in order to run the program, I type in Ubuntu's terminal:

mpiexec -n 2 ./main_program

-

The program write in terminal:

I am node 0
I am node 0
Num threads (Get_size) - 1
I am node 0
I am node 0
Num threads (Get_size) - 1

instead of:

I am node 0
I am node 0
Num threads (Get_size) - 2
I am node 1
I am node 1


Lola







___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake