Re: [CMake] cross-testing support in cmake

[Miller Henry]

Easy enough.  ADD_TEST can run whatever you want.

I created a simple cmake function
Function(RUN_REMOTE_TEST testname, other_args)
   # insert useful code here…
   add_test(${testname}
  remote_run_test ${binary_dir}/${testname} other test runner script args…
  )
End_function()

You will have to figure out how to make the above work for your needs, but the 
idea is simple enough.   One useful thing I do in our function is create a 
custom target to run the test as part of the build as well, that way the TDD 
cycle runs all the tests.

From: CMake  On Behalf Of Stefan Seefeld
Sent: Tuesday, November 5, 2019 8:06 PM
To: CMake 
Subject: [CMake] cross-testing support in cmake


Hello,

I'm looking for ways to enable cross-testing with cmake. I imagine some helper 
script that, during test execution, copies the test binary to a test platform, 
runs the binary there, and reports back the test result. Does cmake have 
support for such a scenario ?

Thanks,


[Stefan]

--



  ...ich hab' noch einen Koffer in Berlin...
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Split Build and Test Pipelines

[Miller Henry]

We have had luck packaging all the CTestTestFile.cmake files, and using sed to 
adjust paths for the target location.  You need to install ctest on the test 
machine, along with all the tests.

The only paths we change are the test output location (ie google test .xml 
files: this might not apply to you), and the path to the build directory.  
Something like the following.

 sed -i ‘s/$BUILD_DIR/@CTEST_TARGET_DIR@/g’ $file

When running we first use configure_file in cmake to substitute 
CTEST_TARGET_DIR with whatever path things are installed to on the test machine.

From: CMake  On Behalf Of Dustyn Blasig
Sent: Friday, May 10, 2019 12:07 PM
To: CMake 
Subject: [CMake] Split Build and Test Pipelines

Hi All,

I'm curious if anyone has had success allowing two testing paths to coexist 
well.

Currently, we are using CTest to run our test executables with `make test`. 
However, on our Jenkins system, the build machines have the whole development 
stack but the test machines do not. So we need a way to package up the tests in 
a way that the test machines can simply run some generated script to do the 
equivalent of what CTest would do.

My current thought is to generate OS specific scripts `make test` depends on 
and runs. These scripts can get installed through `make install` if 
ENABLE_TEST_INSTALL is set, and then the test machine can run the installed 
scripts. The tricky part is building up the hierarchy of scripts in such a way 
that the tester just needs to run "test.sh" or "test.bat" at the top-level of 
the install hierarchy.

Any comments and suggestions greatly appreciated!

Cheers!
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] dependencies of cross compiliations

[Miller Henry]

I like the idea, some tweaks that I think you need

add_host_build - executables built here need to be available not as targets, 
but as variables as if FIND_EXECUTABLE was called on them. This is probably 
what you meant, but it didn't come across that way.

In the case where you are cross compiling for more than one target it would be 
useful if you could build the host tools once and then use that build in 
multiple target builds. There are two different workflows for this: building 
locally where the host build directory just needs to be shared (how?); building 
on a CI system where you want to build/package the host tools and then send the 
package to downstream jobs.  In my opinion this second workflow is the more 
important one to have work. 

I would suggest that it work something like this: A new option 
-DCMAKE_HOST_TOOLS_BUILD_DIR which if set will specify the directory to find 
host tools in - if this directory already has a built use, the tools already 
built there (of course re-run that build as required on source changes); 
otherwise configure and build host tools in that directory.  If this options is 
NOT specified first run find_package to see if a cmake config file can be found 
for the correct version of host tools - if so use them (I think we only want to 
support cmake config files not the other options find_package looks for), it is 
the users responsibility to update the installed tools if the source changes.  
If all of the above fails fall back to some directory under the build directory 
(as you proposed?).

The above also solves the problem of what if you want to pass a ton of options 
to the host build.  Adding overrides to cmake options for host vs target (ie 
-DHOST_CMAKE_BUILD_TYPE) gets out of hand quickly, both from the developer that 
has to write all the cmake options and also the user who has to maintain long 
command lines.  

Keep in mind there are some projects where the above cannot work.  I know of 
one program where the host tool creates data packed for the specific CPU 
(endian and bits in an int) and so you cannot share then host build. This 
project doesn't support cross compiling the host tool so I run it under QEMU, 
but you can imagine it being properly supported in the future and so 
add_host_build may need to have something to indicate the target to build the 
host tool for.

Just some thoughts. Since I'm not doing the work I don't get to tell you how to 
do it.

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Rolf Eike Beer
Sent: Tuesday, November 27, 2018 4:28 AM
To: cmake@cmake.org
Cc: cmake-develop...@cmake.org
Subject: Re: [CMake] dependencies of cross compiliations

Am 2018-11-09 10:04, schrieb Torsten Robitzki:
> Hi,
> I hope this question was not asked before. I work in the embedded 
> field and there it is usually to have at least two different build 
> platforms. The Host platform, where unit tests are build (and where 
> CMake is running) and an embedded Target platform, where targets are 
> build with a cross compiler. Sometimes such a system comes with 
> self-written tools that are build and run on the Host platform to 
> build a target for the embedded Target platform (adding meta data to a 
> binary to be used by a bootloader for example).
> 
> Usually I have two different build folders, one for the Host platform 
> and one for the Target platform, using different calls to cmake to 
> choose from a set of tools and targets. But when using this approach, 
> it is necessary that the Host platform build ran before the Target 
> platform build, so that tools that are required for the Target 
> platform are build during the Host target build.
> 
> One solution I’ve came up with, is to build the required tools during 
> the Target platform build, using an add_custom_target() to invoke the 
> Target compiler directly. This works fine, as long as the tools are 
> basically build just out of a couple of files.
> 
> What would be the „CMake-Way“ to add the tools (that have to be build 
> on the Target platform) as dependency to targets that have to be build 
> for the Target (cross compile) platform?

TL;DR: there is not "good" way yet. But there should be one.

I'm hijacking this and move it to the developers list, because that is 
something "big", and we need to think about how to do that. I find it important 
to correctly solve this as it would simplify a lot of things. 
Especially given that Qt is thinking to use CMake to build Qt itself, which I 
bet all of us would love to see. But they will be after us if we don't offer a 
solution for this. And given the increasing amount of cross-setups these days 
I'm sure that a lot of other people would benefit.

My first idea was to have something like add_host_executable(), which would 
only be called when this is not CMAKE_CROSSCOMPILING, but at the end I think 
this clutters things too much.

Then I came up with:

   add_host_build("relative source dir" "build 

Re: [CMake] dependencies of cross compiliations

[Miller Henry]

There are two options. Each with pros and cons.

The first what you are doing now, except you use external project 
https://cmake.org/cmake/help/v3.12/module/ExternalProject.html to build the 
host tools instead of add_custom_command. It otherwise has all the cons you 
mention, but are they significant (this is a question that is different for 
each project)?  Going back to the manual build for host before the target isn't 
bad, though it is harder to teach.

The second is to use a package/dependency manager to setup your build 
environment with all tools. In this approach the host tools would be in a 
separate source control repository and the package manager will download the 
latest binaries. Conan.io comes to mind as a tool to do this, but there are at 
least a dozen others that you can choose from (or write your own if you have a 
year to spend) . This approach is much more complex, but these systems offer 
many other features that are often compelling.

I would recommend you spend some time researching the package/dependency 
manager tools available. It is likely that you (or your team) will look at some 
feature completely unrelated to your question and say "This is a good solution 
to our problem". At that point your question changes from "how do I best make 
cmake do this" to "how do I do this in my new package manager". If after a 
review nothing stands out, your approach is perfectly fine, the only question 
is it worth tweaking.

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Torsten Robitzki
Sent: Friday, November 9, 2018 3:04 AM
To: cmake@cmake.org
Subject: [CMake] dependencies of cross compiliations

Hi,
I hope this question was not asked before. I work in the embedded field and 
there it is usually to have at least two different build platforms. The Host 
platform, where unit tests are build (and where CMake is running) and an 
embedded Target platform, where targets are build with a cross compiler. 
Sometimes such a system comes with self-written tools that are build and run on 
the Host platform to build a target for the embedded Target platform (adding 
meta data to a binary to be used by a bootloader for example).

Usually I have two different build folders, one for the Host platform and one 
for the Target platform, using different calls to cmake to choose from a set of 
tools and targets. But when using this approach, it is necessary that the Host 
platform build ran before the Target platform build, so that tools that are 
required for the Target platform are build during the Host target build.

One solution I’ve came up with, is to build the required tools during the 
Target platform build, using an add_custom_target() to invoke the Target 
compiler directly. This works fine, as long as the tools are basically build 
just out of a couple of files. 

What would be the „CMake-Way“ to add the tools (that have to be build on the 
Target platform) as dependency to targets that have to be build for the Target 
(cross compile) platform?

Kind regards and thanks in advance,

Torsten
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

[CMake] build times increase 1.5x from cmake 2.8.12 to 3

[Miller Henry]

I have a fairly large project that I'm trying to update from building with 
cmake 2.8.12 to 3.10.2. When I make the change my build times go up by half on 
our Jenkins ci build system.  The build machines are 32 core and my build time 
goes from 59m 38s to 1h 28m 33s. When I try this locally the time goes from 80 
minutes to 84 minutes (a 6 core machine, but I'm running Debug while the ci 
system is running RelWithDebInfo so the times cannot be compared).  My current 
effort is targeting 3.10.2, but I've had similar results with 3.2 and 3.9.

I compared command line of just one file and it looks like the only significant 
difference is 2.8.12 was passing -MMD to gcc, while 3.10.2 is using -MD. I'm 
suspecting that this is the significant difference. Is there a way to get cmake 
to use -MMD? Or better yet, since our CI machines never do an incremental build 
is there a way to turn off dependency generation that might speed my build up 
more?  We are using the ninja Generator.

Of course I just sampled one of our 17000 build steps to decide the above was 
the problem. It is entirely possible that I'm off base and something else is 
the issue. If you have an idea of where I should look instead I'm open to that.



-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] target_link_libraries - private public interface rules

[Miller Henry]

Is that the right place to say things like 

If a header file contains
#include 
Then OtherLibrary is probably candidate for PUBLIC, if the header contains the 
predeclaration
class OtherLibraryClass;
then OtherLibrary should be PRIVATE?  

I'm not against putting that content in official cmake documentation, but it 
seems like something that has never been done before.

-Original Message-
From: Robert Maynard [mailto:robert.mayn...@kitware.com] 
Sent: Tuesday, August 22, 2017 9:46 AM
To: Miller Henry <millerhe...@johndeere.com>
Cc: cmake@cmake.org
Subject: Re: [CMake] target_link_libraries - private public interface rules

You could look at extending the official CMake documentation, specifically the 
build system documentation ( 
https://cmake.org/cmake/help/v3.9/manual/cmake-buildsystem.7.html ).

The documentation is all in restructure text and we accept documentation 
changes through our gitlab instance.

cmake gitlab: https://gitlab.kitware.com/cmake/cmake

build-system restructure page:
https://gitlab.kitware.com/cmake/cmake/blob/master/Help/manual/cmake-buildsystem.7.rst

contribution guideline:
https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst

On Tue, Aug 22, 2017 at 9:44 AM, Miller Henry <millerhe...@johndeere.com> wrote:
>
> I’ve been playing with the private/public/interface keyword to 
> target_link_libraries. It seems to me that WHAT they do is well 
> documented, but nobody has ever actually documented what they correct 
> rules of WHEN/WHY you should use any of them. After a lot of misstarts 
> I think I’ve started to understand what the rules should be. I think 
> they need to be written down someplace so that others don’t have to 
> make the mistakes I have. Also it would be nice if others would look 
> this list over to see what else might be overlooking.
>
> Can somebody point me to a good place to do this? Sending to the 
> mailing list seems like a poor solution as corrections will not be easily 
> findable.
> A wiki seems ideal, but which? KDE in particular should probably have 
> these rules in their official requirements, but I’m not sure if they 
> are the correct ones to own them.
>
>
> --
>
> 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] target_link_libraries - private public interface rules

[Miller Henry]

I've been playing with the private/public/interface keyword to 
target_link_libraries. It seems to me that WHAT they do is well documented, but 
nobody has ever actually documented what they correct rules of WHEN/WHY you 
should use any of them. After a lot of misstarts I think I've started to 
understand what the rules should be. I think they need to be written down 
someplace so that others don't have to make the mistakes I have. Also it would 
be nice if others would look this list over to see what else might be 
overlooking.

Can somebody point me to a good place to do this? Sending to the mailing list 
seems like a poor solution as corrections will not be easily findable.  A wiki 
seems ideal, but which? KDE in particular should probably have these rules in 
their official requirements, but I'm not sure if they are the correct ones to 
own them.

-- 

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] Predownload

[Miller Henry]

Instead of trying to do this with the toolchain somehow in cmake I think you 
might want to look into a meta build system that handles the toolchain and all 
other dependencies.  I listed all I know of a couple months ago in this thread. 
 https://cmake.org/pipermail/cmake/2017-March/065229.html


From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Zabel, Oliver
Sent: Monday, April 17, 2017 8:07 AM
To: cmake@cmake.org
Subject: [CMake] Predownload

Hi,

i’m developing Software for embedded Systems and my applications Need to run on 
different target platforms. Until now we are build our Code with make but i’d 
like to Switch to cmake. ATM we’re putting our Compiler toolchains in our VCS 
to be able to produce the same binarys even after years. Until now, there is 
only one toolchain include in a Project as svn-external/git submodule. But i 
want to use toolchain-files with cmake.

Now here is my idea and i’d like to know whether this is possible with cmake.
I have my Project root and in this Folder i’d like to have different toolchain 
files for different Compilers. I’d like to exclude the Compilers as external.
Now i’d like to build the cmake Cache by calling cmake with the required 
toolchain file. Is it now somehow possible, to download the required toolchain 
before the Cache is buidl up? If this would be possible, i could dynamicly 
choose which toolchain i want to have – would be great for Compiler / unit 
Tests as well.

Perhaps someone has a better idea to do this or even i using such a System and 
give me a hint?

Thanks a lot!

Best regards,
Oliver
-- 

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] Building third party libraries along with normal targets

[Miller Henry]

I have found the following projects which all seem to do some variation of a 
meta build so that you can build multiple projects that depend on each other 
and manage dependencies.  (there are a couple others that seem to not be 
maintained as well)

https://gradle.org/
https://bazel.build/ 
https://github.com/LLNL/spack 
https://github.com/ruslo/hunter 
http://www.biicode.com 
https://conan.io/
https://conda.io/

Unfortunately I have never found anyone who has actually compared even two of 
these. None of the projects have good marketing: it appears they somehow solve 
similar problems, but none actually have defined the problem or their solution. 
 It is like everyone assumes that everyone in the world has their exact same 
problem and the solution is obvious so the only thing left is the details of 
implementing it.  This of course tells me nothing about if they handle cross 
compiling (not a common use case but it is yours and mine), what packages they 
create, what compromises they make, what they expect of my environment...  
These are important questions: I'm pretty sure that I could eliminate several 
just by comparing my needs to their features.

I'm currently using an in house system that builds everything in a Docker which 
lets me ensure nobody is accidentally using the wrong compiler. (we cross 
compile for a x86 target - 90% of the time if you build with gcc for the local 
system everything will work just fine, the other 10% of the time our system has 
an imcompatible version of some library and things blow up when you try to use 
some uncommon feature). I'm thinking about moving to one of the above, but I 
haven't actually evaluated anything.

If you do evaluate any of the above please document your experience and in 
particular what is good/bad about the things you look at.

This is getting off-topic for the cmake mailing list, but I don't know where 
else to move the conversation.


-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Dailey
Sent: Wednesday, March 29, 2017 9:39 PM
To: Florent Castelli 
Cc: CMake 
Subject: Re: [CMake] Building third party libraries along with normal targets

On Wed, Mar 29, 2017 at 9:32 PM, Florent Castelli  
wrote:
> On 30/03/2017 03:54, Robert Dailey wrote:
>>
>> On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli 
>>  wrote:
>>>
>>> This is known as "super build".
>>> Yes, this is exactly why I made my Boost CMake build scripts, which 
>>> you use unless you changed your mind today :)
>>
>> You mean this?
>> https://github.com/Orphis/boost-cmake
>>
>> It's on the drawing board, for sure. It's the best solution I've 
>> found. It's also part of the reason I'm asking this question to begin 
>> with.
>>
>> Although, this specific method of building boost doesn't use 
>> superbuild, it uses normal add_subdirectory() with target.
>
> It doesn't "super build" its dependencies, you have to provide them 
> externally, but it is a possible addition.
> But it is designed to be part of a super build environment and is used 
> as such at some large companies shipping to millions of people.
>
>>
>>> It can be done for other projects as well. Sometimes, they even 
>>> provide CMake build scripts you can use directly with 
>>> "add_subdirectory()" so you don't have to write CMake scripts or use 
>>> "ExternalProject_Add()" (which isn't all great since it doesn't 
>>> propagate all your current project settings).
>>
>> Long term, I'm thinking a project like hunter[1] would be the best 
>> choice. The problem with hunter is that it doesn't separate concerns 
>> between host machine and target host. Specifically, when cross 
>> compiling.
>>
>> All the superbuild commands assume linux command syntax, simply 
>> because I specified a toolchain utilizing android NDK. For this 
>> reason it requires a lot of TLC to get working.
>>
>> [1]: https://github.com/ruslo/hunter
>
> There are those issues and also ABI changing flags that can become an 
> issue as they aren't always propagated from what I can see.
>
>>> You can use ccache or its Windows variants to make it faster. But 
>>> you also shouldn't need "ninja clean" most of the time. Possibly, 
>>> you could just clean a specific target "ninja -t clean foo".
>>> If you declare all your dependencies properly, then you could just 
>>> always run "ninja" and the build will just be correct.
>>> If your purpose is to see the compiler output again (to fix 
>>> warnings), it is acceptable to clean and rebuild (with ccache it 
>>> should be fast enough).
>>> Personally, I just have a very long history in my terminal and 
>>> scroll back or pipe the build content to a file to look at it later. 
>>> Some IDEs will also record all the compilation output and make it 
>>> available later (Xcode does it), then it's less of an issue.
>>
>> Never used ccache before, what does it do? Also if even if you 

Re: [CMake] Need ideas/opinions on third party library management

[Miller Henry]

A superbuild will work, and you can write your own Find*.cmake so that 
find_package works - you don't need most of what the real Find_package would do 
for you because you already know what is installed where as you control that.  
But, can you live with the trade off: long build times?

What my company did to solve a similar problem is write a tool (this took most 
of a year for a couple people, a lot that is very specific to our environment 
so sharing doesn't make sense) that that will install packages in a docker 
(linux only) image.  Each project we build has a "pin file" that lists the 
packages that project depends on.When we upgrade boost, the build creates a 
.rpm package which the tool automatically installs for the build to use.

What really makes our approach work is the integration into our CI system, when 
I change boost I verify the build in just one architecture, then push.  The CI 
system takes over to build every supported architecture, and then it deploys 
the packages - I don't have to build them all by hand (of course if something 
fails I need to figure that one out). Then I just have to pin the new package 
and our build system takes care of ensuring the new version is in place.

As I said, the above is complex and very custom to our environment.  I'm not 
entirely happy with it, but I can't come up with anything better for our 
requirements.  In particular I can go backward to any released version of code 
and rebuild it - meaning we can fix bugs in old versions easily if a customer 
isn't willing to upgrade.

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Dailey
Sent: Friday, August 12, 2016 3:00 PM
To: CMake ; CMake Developers 
Subject: [CMake] Need ideas/opinions on third party library management

Hello,

There is an internal C++ product at the company I work for which I have written 
a series of CMake scripts for. This project actually has dependencies on 
several open source libraries, such as boost, freetype, openssl, etc.

Right now what we do is build each of these third party libraries *by hand*, 
once for every platform we support (Windows, Linux x86, Android NDK). Then we 
stuff the includes (headers) and libraries
(static/shared) in a submodule and the primary code base's CMake scripts pull 
them in as interface targets.

This works well and is light-weight but is a pain when upgrading or changing 
libraries. It's a pain because if I want to upgrade boost, I have to build it 
up to 6 times (once for each platform and once for each configuration).

I've been thinking of a different approach for a while. I've done some toying 
around with the "Super Build" concept, where I have a separate CMake project 
that does nothing but use the ExternalProject module to build libraries in real 
time along with our project. So the order of operations would be as follows 
(for our automated build server):

1. Clone our "Third Party" repository
2. Use CMake to generate & build the "Super Build" project (this builds boost, 
openssl, freetype, etc for the current platform).
3. Clone the main code base's repository 4. Use CMake to generate & build, 
using find_package() to refer to interface targets exported by those third 
party libraries built in step 2

Obviously this will make builds take significantly longer, because we're 
constantly rebuilding the same third party libraries over and over again. 
However, it virtually eliminates the maintenance burden for third party 
libraries because they are built inherently with everything else.

Note that I can't refer to pre-built libraries in our build environments 
because we need very specific control over the versions of our libraries as 
well as the toolchains that were used to build them. Also we may specifically 
build our libraries a certain way (such as boost). For this reason we do not 
rely on our external environment or external package managers to fulfill third 
party dependencies, like most open source projects do on Linux for example.

Does this "Super Build" approach sound like a better idea? What other options 
are available? The downside with the "Super Build" solution is that it will 
become very difficult to make the transition between building third party and 
building our code base seamless. I can't do both in the same generate step 
because find_package() can't be called until the libraries are built & 
installed.
-- 

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 

[CMake] Super builds and export with Namespace

[Miller Henry]

I have a few different cmake based projects that depend on each other (as a 
tree, no circular dependencies).  Mostly this works great, but a few people 
have expressed interested in a superbuild which builds everything together for 
various purposes.  I can make this work with ExternalProject, but that isn't a 
useful solution for IDE users.  I'm trying to use add_subdirectory and running 
into a problem with namespaces in my export files

Currently projectA has
   EXPORT(projectA NameSpace ProjectA_)
Which works great, when projectB wants to link to a library in projectA it is 
just FIND_PACKAGE(ProjectA) then TARGET_LINK_LIBRARIES(lib 
ProjectA_LibraryName).  Simple enough without superbuilds.

When I get to a superbuild though I don't know how to handle this.  It is easy 
to do write some sort of FindProjectA.cmake or ProjectAConfig.cmake file to 
make the FIND_PACKAGE work in projectB. However I don't know how to get a 
ProjectA_LibraryName target that I can link to, the superbuild only knows about 
LibraryName without the namespace.

The only idea I can think of is in the superbuild have a bunch of ADD_LIBRARY 
(ProjectA_LibraryName ALIAS LibraryName) lines hard coded. This means I have to 
maintain that file though which I don't like. Does anyone have a better idea?


-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] find*.cmake config files, and Qt4 while cross compiling.

[Miller Henry]

I'm going to ask two questions, but a good answer to the first will make the 
second question redundant.

I work with several different cmake projects that are cross compiled, and they 
depend on each other.  Each project creates a cmake config, so we can use 
find_package to find the contents.  Up until now we have been setting 
LINK_INTERFACE_LIBRARIES to "" SET_TARGET_PROPERTIES(${projectName} PROPERTIES 
LINK_INTERFACE_LIBRARIES ""), but for a few years this has required us to set 
CMP0022 to OLD.  Now that we no longer support older versions of CMake I 
figured it was time to set this to NEW (2.12 is minimum we use and most of us 
are up to 3.2 (I have not tried anything newer than 3.2).

This works great for libraries that provide a cmake config file when we link a 
library to libFoo the config includes the need to link to libFoo. However any 
project that we use a FindXXX.cmake to find (including cmake included like 
FindLibXml2.cmake) the package the config file says you need to link to 
/home/hank/sysroot/path/to/libFoo.  When I package this build and give it to a 
different developer to install into his sysroot it fails because the correct 
path for him is /home/joe/some/other/dir/sysroot/path/to/libFoo. I found a work 
around: in target_link_libraries make libFoo a private link.  This feels wrong 
though, I feel that cmake should handle this automatically.  (I'm fine with 
mark it as private, anything better is probably not implementable)

First question, how can I use libraries from a Find*.cmake file without having 
to mark it as private in every target_link_libraries call.

I couldn't figure this out, but I was able to mitigate it for the most common 
package we link to.  For Qt4 is you have a choice, what we were doing was:
  Find_package(Qt4 REQUIRED)
  INCLUDE(${QT_USE_FILE}
  TARGET_LINK_LIBRARIES(MyProject ${QT_LIBRARIES})
If you use this for you get the full path to each library in your sysroot.

However if you do:
  Find_package(Qt4 REQUIRED)
  TARGET_LINK_LIBRARIES(Qt4:QtGui ...)
You get just the Qt library, which would be what I want except that now the 
INCLUDE_DIRECTORIES for Qt libraries are not SYSTEM libraries and so I'm 
getting a lot of compiler warnings in qt header files which I cannot fix.

Second question: how can I use the TARGET_LINK_LIBRARIES(Qt4:QtGui...) form and 
get the qt headers as system libraries?



-- 

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] Performance issues on very large project

[Miller Henry]

I found the same thing a few years ago, and my solution was the same: only 
include those modules once.  I find that my sub cmake modules are much cleaner 
now as a bonus.

I tend to blame the time not on file IO, but on time to parse those files.  
I've never done actual profiling though.

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Steven Stallion
Sent: Tuesday, April 05, 2016 11:19 PM
To: cmake@cmake.org
Subject: [CMake] Performance issues on very large project

All,

I am currently working on a very large project that contains over 500 (yes, 
really) listfiles. A co-worker was looking into some performance issues we were 
seeing during configuration and found something very interesting. Currently 
configuration is taking 1m57s across several configurations using Mac OS X as a 
host and the latest .dmg from cmake.org (3.5.1).

We have a core module that provides a number of helper functions and macros 
(completely stateless) that is included by most of this listfiles (nearly 400 
of them). We found that an include guard was missing, after adding that 
configuration now clocks in at 1m30s.

Taking things a step further, we removed includes of the module, and simply 
included it once in the top-level listfile. Configuration then dropped to about 
55s.

The results above seem to indicate a possible file I/O bottleneck.
This is very surprising to me - these builds are being run on recent core-i7's 
with SSDs. Is anyone else on the list dealing with large projects or similar 
configuration issues?

TIA,

Steve
-- 

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] CTest usage

[Miller Henry]

I hate to state the obvious, but
set_property (TEST test2 PROPERTY LABELS LABEL1 LABEL2 LABEL1andLABEL2)
I know it isn’t what you asked for, but I don’t want cmake to change, but I 
don’t think it is worthwhile to add more complex set algebra to the -L command 
so that we can support complex things.

On a more philosophical level, I generally find that if I want to run the 
intersection of tests like this, there is a LABEL3 to more accurately describes 
why I want to run that set, and having a label to remind me of it is helpful in 
the future.

From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of CHEVRIER, Marc
Sent: Tuesday, March 08, 2016 5:21 AM
To: cmake@cmake.org
Subject: [CMake] CTest usage


Hi,

Is there someone able to help me regarding ctest usage with labels?

Here is the problem: I have various tests which have labels attached to them:
set_property (TEST test1 PROPERTY LABELS LABEL1)
set_property (TEST test2 PROPERTY LABELS LABEL1 LABEL2)
set_property (TEST test3 PROPERTY LABELS LABEL2)

Now, I want to be able to select tests which have labels LABEL1 AND LABEL2 
attached to them. Unfortunately, the command ctest –L LABEL1 –L LABEL2 will 
select all the tests rather than on the test test2 (a OR is applied on the 
various –L options).

Is there a way to get a AND on the labels specified?

Marc

-- 

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] How can I export source code that needs to be built by downstream projects?

[Miller Henry]

I'm using cmake to build a set of libraries that then gets packaged and shipped 
to other groups that are also using cmake to use the library.  Since I use 
google mock to mock my libraries, and the downstreams also want to mock my 
library I just provide the mock header for their use.  This works, but there 
are some quirks of google mock that make it not work well.

It turns out the it takes a significant amount of time to build the constructor 
and destructor for a mock class.  So we have moved those to a separate .cpp 
file that is compiled and exported into another library to link against.
  INSTALL(FILES MyMock.h DESTINATION include/)
  INSTALL(TARGETS ${PROJECT_NAME} EXPORT my-target LIBRARY DESTINATION lib 
COMPONENT ${MY_COMPONENT})

Now I'm looking at upgrading the version of google mock I compile against, but 
I cannot force my down streams to upgrade (I expect that they will, but 
politically I cannot force it).   The new version is not binary compatible with 
the old version, even though the headers are source compatible.

What I want to do is
  INSTALL(FILES MyMock.h DESTINATION include/)
  INSTALL(FILES MyMock.cpp DESTINATION src/)
  INSTALL(TARGETS MyLibraryMock EXPORT my-target SOURCE_LIBRARY DESTINATION 
src COMPONENT ${MY_COMPONENT})
Then when the downstreams have
  TARGET_LINK_LIBRARIES(THEIR_PROJECT MyLibraryMock)
Cmake knows to build MyLibraryMock, but if they don't link to the mock (I none 
of their tests use it) don't build it.

Does anyone have any idea on how I might be able to achieve that?



-- 

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] Colored diagnostic output for GCC 4.9 through Ninja

[Miller Henry]

I do something like this, which works for clang and should work for gcc 4.9 
though I haven't tested it.   I haven't wrote the right way to do this which is 
to check if the terminal supports color before passing the flag in. I don't 
know what will happen on our e.g. CI system which doesn't support color.

macro(AddCXXFlagIfSupported flag test)
   CHECK_CXX_COMPILER_FLAG(${flag} ${test})
   if( ${${test}} )
  message("adding ${flag}")
  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${flag}")
   endif()
endmacro()

if("Ninja" STREQUAL ${CMAKE_GENERATOR})
   AddCXXFlagIfSupported(-fcolor-diagnostics 
COMPILER_SUPPORTS_fcolor-diagnostics)
endif()

P.s. AddCXXFlagIfSupported ought to be in the default cmake distribution along 
with a lot or similar things

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Robert Dailey
Sent: Wednesday, October 28, 2015 8:43 AM
To: CMake
Subject: [CMake] Colored diagnostic output for GCC 4.9 through Ninja

I'm using CMake + Ninja against GCC 4.9 in the Android NDK. I'm on Windows, 
invoking 'ninja' through CMD.exe.

I do not see colored output for diagnostics (errors, warnings, etc) GCC gives. 
Is there something in CMake I need to configure to enable colored output?
-- 

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] Imported libraries and cross platform target names

[Miller Henry]

Use find_library to find the library.  You will probably need this anyway 
because different systems install libraries in different locations.

http://www.cmake.org/cmake/help/v3.3/command/find_library.html


From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Ette, Anthony (CDS)
Sent: Tuesday, August 18, 2015 1:30 PM
To: CMake@cmake.org
Subject: [CMake] Imported libraries and cross platform target names
Importance: High

Given that add_library() produces a unique filename per platform (the actual 
file name of the library built is constructed based on conventions of the 
native platform (such as libname.a orname.lib), how does one add the 
library to the final application without having to deal with the filename 
difference?  In other words, I've got one library that, by default, produces 
'libtest.a' on Linux and 'test.lib' on Windows.  How can I add this imported 
library into the final application in a cross platform manner?  I know I can 
specify two different imported locations (see below), but it seems odd to me 
that Cmake - the cross-platform build env generator - doesn't have a better 
native way of dealing with this

The snippet below will work, but just seems wrong given the nature of what 
CMake is intended to do...is there a better way that I'm missing?!  If not, can 
I request that a future release of Cmake handle platform naming convention 
difference internally when invoking ADD_LIBRARY with the IMPORTED tag set?  Ok 
so, to be fair, Cmake can be used to cross compile and that certainly 
complicates my feature request but, when not cross compiling, CMake knows what 
platform it's being executed on so it should be able to resolve static archive 
platform decorations internally.

ADD_LIBRARY(test STATIC IMPORTED)
if(WIN32)
   SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/timer.lib)
endif()
if(UNIX)
   SET_PROPERTY(TARGET test PROPERTY IMPORTED_LOCATION ${LIB_D}/libtimer.a)
endif()

Thanks in advance,
Anthony Ette
Control Systems Engineer

Rolls-Royce Controls and Data Services
7661 N Perimeter Rd
Indianapolis, IN 46241
tel: +1 (317) 230-6943
mob: +1 (317) 864-7975
email: anthony.r.e...@controlsdata.commailto:anthony.r.e...@controlsdata.com

This e-mail (including attachments) contains contents owned by Rolls-Royce plc 
and its subsidiaries, affiliated companies or customers and covered by the laws 
of England and Wales, Brazil, US, or Canada (federal, state or provincial). The 
information contained in this email is intended to be confidential, may be 
legally privileged and subject to export controls which may restrict the access 
to and transfer of the information. If you are not the intended recipient, you 
are hereby notified that any retention, dissemination, distribution, 
interception or copying of this communication is strictly prohibited and may 
subject you to further legal action. Reply to the sender if you received this 
email by accident, and then delete the email and any attachments.
-- 

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] 3.3.0-rc1 feedback - CMP0046 doens't obey policy push

[Miller Henry]

I'm trying out my project on 3.3.0-rc1, but currently I'm using 2.8.11 and 
2.8.12.  I got  a couple errors from CMP0046.  Most of them are correct: I've 
fixed a couple places where a non-existent dependency was used, and I want to 
set this policy to NEW so that more do not sneak in.

However there is a problem. I have a test that dynamically loads a bunch of 
.so's, as configured by a .xml file to ensure they are compatible.  Some of the 
.so's are in the same project and some are from a different project and 
installed into the system at build time.  We are running tests as part of the 
make all target, (easy to do with a few add_custom_command/add_custom_target).  
The obvious problem is this test needs to have all the .so's built before the 
test runs, but it doesn't link them.  This was easy enough - I just parsed the 
.xml for the name of the .so and place that name into an add_dependencies. That 
works great in cmake 2.8.11.

In cmake 3.3.0-rc1 it doesn't work.  Some of the .so's are installed on the 
system and not built in the project.  Obviously no target exists for them. What 
I want to do to solve this is:

  cmake_policy(PUSH)
 if(POLICY CMP0046)
CMAKE_POLICY(SET CMP0046 OLD)
  endif()
 add_dependencies(${MyTestRunTarget} ${XML_PARSED_DEPENDENCIES})
  cmake_policy(POP)

This does not work.  It appears that the policy is not actually checked until 
long after the add_dependencies line is done processing, and the fact that I 
want to suppress the policy for just these is not carried along.

Is there some way to achieve changing this policy for just a few select targets?


-- 

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] Export a target that must be built in the import environment

[Miller Henry]

I develop a shared library that gets imported into a number of applications 
(scattered across a number of different repositories).  To aid in testing we 
provide some mocks and fakes, made available by a cmake export files.

This works okay, but it isn't right: google mock doesn't guarantee binary 
compatibility if compile flags are not exactly the same, and less so if the 
version is different between our library and the application. There are a 
couple new features in google mock that I'd like to use, but I cannot upgrade 
without also upgrading all the users of the library at the same time: this is a 
difficult task (both technically and politically)

I know I'm going to have to face the technical and political issue, but I'd 
like to solve this problem completely so I don't hit it again. The solution I'd 
like to install the .cpp files, and have cmake add those files to the build, 
but only build the ones that are actually used in the project.  The actually 
used is somewhat important as building the library for the mocks is fairly 
expensive.

That is in the main CMakeLists.txt
  Find_package(MyLibrary)
Then in a test someplace
  Target_link_libraries(SomeTest, MyLibraryMock)

I'm stuck though, I can't think of any way to actually implement this.  Can 
anyone offer some suggestions, or a different way to accomplish this?

The idea of putting the functions inline in the header will not work: we have 
benchmark data showing that doing this adds significantly to the compile time 
of the project when doing an incremental build (the TDD cycle becomes too long).



-- 

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 set path to library header files?

[Miller Henry]

You need to use include_directories to tell cmake where to find headers.

include_directories(${CMAKE_SOURCE_DIR}/src)

http://www.cmake.org/cmake/help/v3.0/command/include_directories.html
http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_SOURCE_DIR.html


From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Chris Johnson
Sent: Tuesday, December 02, 2014 11:04 AM
To: cmake@cmake.org
Subject: Re: [CMake] How to set path to library header files?

Ah, and I royally typo'd:

prog.cpp includes the header via:

#include mylib/myfunc.h

(not just myfunc.h)

On Tue, Dec 2, 2014 at 11:01 AM, Chris Johnson 
cxjohn...@gmail.commailto:cxjohn...@gmail.com wrote:
Background:  I'm converting an existing project from a custom build process 
which uses BSD Make to CMake.  The source for the project is contained in about 
600 directories, and has about a dozen libraries and maybe a hundred 
executables.  The old build system (make) has to continue working until the new 
CMake-based system is fully operational and tested.  For the most part, this 
has been straight forward and easy, since make is building in source using 
in-source Makefiles.  I've simply added a CMakeLists.txt file to each 
directory, and the actual CMake build occurs out-of-source.  It's only the edge 
cases (of course!) which have given me a headache.  I've solved some of them.  
This message is about one I have not yet been able to solve.

The basic problem is this:  my executables cannot find the header files for 
some of the libraries, because they are in a subdirectory when installed, but 
are not in a subdirectory while in source.

Here's a simplified example (SSCCE) which reproduces this problem.

The file structure:
.
|-- bin/
|-- include/
|   `-- mylib/
|-- lib/
`-- src/
|-- CMakeLists.txt
|-- mylib/
|   |-- CMakeLists.txt
|   |-- myfunc.cpp
|   `-- myfunc.h
`-- prog/
|-- CMakeLists.txt
`-- prog.cpp

The top-level bin, include and lib directories are the install locations, 
exactly parallel to standard Unix locations.  Note that file myfunc.h installs 
into ./include/mylib.  Note also that prog.cpp includes this header via 
#include myfunc.h.

Here are the current CMakeLists.txt files.

Top level (../src):
cmake_minimum_required(VERSION 2.8.4)
project(src)
add_subdirectory(mylib)
add_subdirectory(prog)

mylib:
cmake_minimum_required(VERSION 2.8.4)
project(mylib)

set(CPP_SOURCE myfunc.cpp)
set(HEADERS myfunc.h)

add_library(mylib  ${CPP_SOURCE} )

target_include_directories(
mylib PUBLIC
# Headers used from source/build location:
$BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}
# Headers used from the installed location:
$INSTALL_INTERFACE:include
)

install(TARGETS mylib DESTINATION lib)
install(FILES ${HEADERS} DESTINATION include/mylib)

prog:
cmake_minimum_required(VERSION 2.8.4)
project(prog)

set(SOURCE_FILES prog.cpp)

set(LIBS mylib)

add_executable(prog ${SOURCE_FILES})
target_link_libraries(prog  ${LIBS})
install(TARGETS prog DESTINATION bin)

When I build, I get this error:

src/.build$ make install
-- Configuring done
-- Generating done
-- Build files have been written to: /sandbox/src/.build
Scanning dependencies of target mylib
[ 50%] Building CXX object mylib/CMakeFiles/mylib.dir/myfunc.cpp.o
Linking CXX static library libmylib.a
[ 50%] Built target mylib
Scanning dependencies of target prog
[100%] Building CXX object prog/CMakeFiles/prog.dir/prog.cpp.o
/sandbox/src/prog/prog.cpp:1:10: fatal error: 'mylib/myfunc.h'
  file not found
#include mylib/myfunc.h
 ^
1 error generated.
make[2]: *** [prog/CMakeFiles/prog.dir/prog.cpp.o] Error 1
make[1]: *** [prog/CMakeFiles/prog.dir/all] Error 2
make: *** [all] Error 2


How can I create CMake rules that will allow me to work around this?

As I mentioned above, the existing make-based build has to continue working, so 
I cannot change the #include statement to remove the subdirectory path.

..chris

-- 

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] How can I prevent invalid -DCMAKE_BULD_TYPE values?

[Miller Henry]

One of my co-workers just did a build where they ran cmake with the option 
-DCMAKE_BUILD_TYPE=RelWithDebugInfo  Of course what was obviously meant was 
RelWithDbgInfo.  Because of this incorrect option the build was not as 
expected, but it took a while to figure out why it failed.  Of course once we 
realize the problem it is obvious that they expected to build with 
optimizations, but instead they build with no optimizations. Is there some way 
to make cmake abort when the option is not recognized?  I realize I could add 
any build type, but in this case it doesn't make sense.

The reason the build failed was at some point we have a test that is something 
like this:
#ifdef DEBUG
EXPECT_FLOAT_EQ(7.47869, value);
#else
EXPECT_FLOAT_EQ(6.19632, value);
#endif

The code under test was written about 10 years before we even heard of tests, 
and we have years of real world use that shows it works.  Since the algorithms 
are complex in the typical ways of legacy code: nobody has figured out what is 
going on that compiler optimizations can change a floating point value by this 
much.  This test is just a characterization of current behavior so we don't 
accidentally break it if we have to touch it.

I'm also investigating if I can something different in the preprocessor to get 
the information I need, but this is outside the scope of cmake, and it seems 
that cmake should warn me if my build type option is set to something that 
isn't valid.

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] AStyle or similar code beautifier

[Miller Henry]

I'll second (third) the vote for uncrustify over astyle.  Astyle doesn't have 
enough options to take care of all style issues, with uncrustify you can 
configure everything.  Also check out clang-format - it only supports 3 styles 
(last I checked), but if one of them fit it might be easiest.

What works well for us is a custom script that ties into our version control, 
and code review tool.  Since everyone is using this script to upload code 
reviews they get for free uncrustify run on changed files, and cppcheck (you 
are a fool not to use this as a minimum requirements things in my opinion) is 
also run on all code.  This script is of course tied very closely to our 
development process and servers and so it isn't worth sharing.  However it is 
easy to write something similar for your processes, and seems like a better 
course of action.  Once a file is uncrustifed it doesn't need to be checked on 
everyone's build again.  You just need to ensure the tool is run before the 
code reaches version control.   

On the same lines most source control systems allow you to write a pre checkin 
hook.

While it is possible to do the work in cmake, I don't think it is the right 
approach.

-Original Message-
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Paul Smith
Sent: Friday, January 31, 2014 7:12 AM
To: Alan W. Irwin
Cc: CMake ML
Subject: Re: [CMake] AStyle or similar code beautifier

On Fri, 2014-01-31 at 02:26 -0800, Alan W. Irwin wrote:
 And to answer the OP's question, I can highly recommend uncrustify for 
 code styling

I agree with Alan.  We did a huge reformatting effort last year to change a 
very large C++ codebase from a style based loosely on Whitesmith to a more 
common style.  I started with AStyle which is a solid program, but it has 
limited customization support.

Then I found uncrustify and was quite satisfied with it.  I sent a few patches 
for minor fixes and they were well received.  The main issue with uncrustify is 
that the documentation could be better: for some of the more advanced settings 
it's very hard to understand exactly what they control.

I had to do a bit of scripting around it since uncrustify didn't handle all the 
whitespace conversion we wanted, but it worked great!

We didn't try to integrate it with the build system.  We just checked in the 
configuration file and a script people could use if they wanted to re-beautify 
their code.

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

[CMake] ctest - how to specify tests that must not run in parallel

[Miller Henry]

I just switched to using ctest, which is overall much better, but when I run 
with -j it often happens that some test suite fails.  After investigating I 
discovered that the failing test is not a unit tests (ie a test with everything 
mocked out), but an integration test that is intentionally testing our use of 
global system resources.  The test is failing because a different integration 
test is also using those global resources and changing states.

Is there a way to mark tests as using some global resource and thus not able to 
run in parallel?  My current work around is to use -R and -E to run the tests 
in question separately, but I have enough other tests that don't use this 
global resource that everything could run in parallel if there was some way to 
tell ctest to not schedule them together, and thus increase our total test 
time.  This would also scale better than telling every developer who is using 
ctest the correct -E and -R commands to make things work.

Do I open a feature request, or does this already exist?

--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Alternate compiler specific options - how to specify?

[Miller Henry]

Let me restate the problem: we support several compilers.   When using one 
particular compiler we need to add an option specific to that compiler.  How do 
I make sure that all 200 developer get this option specified right everytime?

I got a great answer for -mtune=atom (seems obvious in hindsight), but I'm not 
clear on how to disable warnings - I'm going to assume that in some other 
compiler this warning exists, but it doesn't product the false positives we 
see.  (I haven't investigated this particular case, I'm assuming the option is 
because of false positives)

-Original Message-
From: Игорь Пашев [mailto:pashev.i...@gmail.com] 
Sent: Wednesday, September 11, 2013 11:31 PM
To: Miller Henry
Cc: cmake@cmake.org
Subject: Re: [CMake] Alternate compiler specific options - how to specify?

2013/9/11 Miller Henry millerhe...@johndeere.com:
 We are using cmake 2.8.11 for out project.

 Our local compiler is gcc-4.4.3.  There is desire to use a newer 
 compiler, but we are not yet ready to commit to anything yet.  In the 
 mean time we have installed binaries gcc-4.7 and gcc-4.8.  We can 
 specify the alternate compiler with –DCMAKE_C_COMPILER=gcc-4.7, but we want 
 to go a step farther:
 one (believed important) advantage of gcc-4.7 is the option 
 -mtune=atom since that is are target system. We want to force this 
 option when using the newer compiler, but the older version of gcc doesn’t 
 accept it.

 Toolchain files are not an option, when you use a toolchain file cmake 
 sets CMAKE_CROSSCOMPILING meaning parts of our system that depend on 
 running on
 x86 will not run.  (it is up to a different team to make a build for 
 other processors – they are nowhere close to done but that variable is 
 used in a few places to disable things that my team needs).

 Here is what we come up with, which both feels icky, and seems like a 
 bad
 compromise:

 IF(4.8.0 STREQUAL ${CMAKE_CXX_COMPILER_VERSION} OR 4.8.1 STREQUAL 
 ${CMAKE_CXX_COMPILER_VERSION} OR 4.8 STREQUAL ${USE_GCC_VERSION})
   SET(CMAKE_CXX_COMPILER g++-4.8)
 SET(CMAKE_C_COMPILER gcc-4.8)
   SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -g -std=c++11)
 SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wno-unused-local-typedefs
 CACHE STRING  FORCE)
 ELSEIF(4.7.1 STREQUAL ${CMAKE_CXX_COMPILER_VERSION} OR 4.7.2 
 STREQUAL ${CMAKE_CXX_COMPILER_VERSION} OR 4.7 STREQUAL ${USE_GCC_VERSION})
   SET(CMAKE_CXX_COMPILER g++-4.7)
   SET(CMAKE_C_COMPILER gcc-4.7)
 ENDIF(4.8.0 STREQUAL ${CMAKE_CXX_COMPILER_VERSION} OR 4.8.1 
 STREQUAL ${CMAKE_CXX_COMPILER_VERSION} OR 4.8 STREQUAL 
 ${USE_GCC_VERSION})


As for me coding any compiler options into CMake files is an urgly idea.
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

[CMake] Alternate compiler specific options - how to specify?

[Miller Henry]

We are using cmake 2.8.11 for out project.

Our local compiler is gcc-4.4.3.  There is desire to use a newer compiler, but 
we are not yet ready to commit to anything yet.  In the mean time we have 
installed binaries gcc-4.7 and gcc-4.8.  We can specify the alternate compiler 
with -DCMAKE_C_COMPILER=gcc-4.7, but we want to go a step farther:  one 
(believed important) advantage of gcc-4.7 is the option -mtune=atom since that 
is are target system. We want to force this option when using the newer 
compiler, but the older version of gcc doesn't accept it.

Toolchain files are not an option, when you use a toolchain file cmake sets 
CMAKE_CROSSCOMPILING meaning parts of our system that depend on running on x86 
will not run.  (it is up to a different team to make a build for other 
processors - they are nowhere close to done but that variable is used in a few 
places to disable things that my team needs).

Here is what we come up with, which both feels icky, and seems like a bad 
compromise:

IF(4.8.0 STREQUAL ${CMAKE_CXX_COMPILER_VERSION} OR 4.8.1 STREQUAL 
${CMAKE_CXX_COMPILER_VERSION} OR 4.8 STREQUAL ${USE_GCC_VERSION})
SET(CMAKE_CXX_COMPILER g++-4.8)
SET(CMAKE_C_COMPILER gcc-4.8)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -g -std=c++11)
SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wno-unused-local-typedefs CACHE 
STRING  FORCE)
 ELSEIF(4.7.1 STREQUAL ${CMAKE_CXX_COMPILER_VERSION} OR 4.7.2 STREQUAL 
${CMAKE_CXX_COMPILER_VERSION} OR 4.7 STREQUAL ${USE_GCC_VERSION})
SET(CMAKE_CXX_COMPILER g++-4.7)
SET(CMAKE_C_COMPILER gcc-4.7)
ENDIF(4.8.0 STREQUAL ${CMAKE_CXX_COMPILER_VERSION} OR 4.8.1 STREQUAL 
${CMAKE_CXX_COMPILER_VERSION} OR 4.8 STREQUAL ${USE_GCC_VERSION})

The advantage of this is you can't accidentally use gcc-4.4 and g++-4.8 - we 
force them in sync. You can also set USE_GCC_VERSION on the command line and it 
takes both gcc and g++, instead of having to set both CMAKE_C_COMPILER and 
CMAKE_CXX_COMPILER (and the line to remember is shorter).  If you do this will 
work (until we upgrade gcc, but I can solve that)

What is the right thing to do - and why is it right?


--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] CMakeModules repository at GitHub?

[Miller Henry]

Nice theory, but I have to deal with the real world where many projects don't 
provide a project config .cmake script. They see no reason to: they don't build 
with cmake, other downstreams don't build with cmake.  It seems to them that 
they are supporting one system, and there are hundreds. I do not see this 
changing anytime soon.

Until the day comes when all projects provide their configuration in a format 
cmake can read: we are forced to create find_package modules for things we want 
to use. A way to share this work is highly desired.  As a user of cmake I've 
seen many poor find_foo modules that only barely work because in our build 
environment, and won't work when we upgrade our OS.  Having a place to collect 
find_foo modules for projects that don't place nice allows people to actually 
handle all the little things that can change between system, and thus gives us 
a second best that works fairly well.

I'm not sure how we will ever get all packages to play nice. It pretty much 
requires that all other build systems can create and read the configuration 
files as well.  Hacking autotools to provide and use .cmake files if they exist 
would be a good start on unix/linux (good luck!).  I have no clue how you will 
get visual studio to support anything like this.  I don't even know what we are 
asking for to make this work on Macs.  (I probably forgot some weird system 
that cmake also supports)

-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of 
David Cole
Sent: Thursday, March 28, 2013 11:25 AM
To: mate...@loskot.net; cmake@cmake.org
Subject: Re: [CMake] CMakeModules repository at GitHub?

CMake needs no new Find modules.

All projects should provide a project config file .cmake script 
readable by CMake's find_package, and installed in a location where CMake can 
find it, so that a CMake find module is completely unnecessary.

For other types of module improvements, I think becoming a CMake developer and 
participating in the active development of CMake itself is a much more useful 
thing than having a separate repository for stuff like this.

This is just my opinion, and I would love to hear what others think. 
But you'll be hard-pressed to convince me that a find module inside CMake 
itself is better than a config file installed with a project's install tree.


David C.


-Original Message-
From: Mateusz Loskot mate...@loskot.net
To: cmake cmake@cmake.org
Sent: Thu, Mar 28, 2013 8:44 am
Subject: [CMake] CMakeModules repository at GitHub?


Hi,

To CMake maintainers,
what do you think about creating new repository at

https://github.com/Kitware/CMakeModules

as incubator for contributed CMake modules?

Here is outline of the process I'm thinking of:

1. I have developed new module for find_package 2. I submit pull request adding 
this new module to CMakeModules
- this is effectively act of request for comments and review 3. The module 
undergoes cycle of community-based review-improve-review iterations 4. The 
module collects +1 votes 5. Once some sort of critical mass of +1 has been 
received, the module is added to CMakeModules repo 6. The newly added module 
gets stamp CMake Approved

Next, users can report bugs, submit improvements through pull requests or even 
issues marking module is out of date and requires maintenance.
GitHub is a tiptop venue for such thing.

IMO, CMake modules have suffered of the issues of fragmentation and 
distribution, and it's time to apply Stop Rolling Your Own [1] approach, and 
perhaps stream all those precious efforts into one sink.

[1] http://ithaca.arpinum.org/2013/01/02/git-prompt.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--

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
--

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

[CMake] Is there an easy way to time how long build parts take.

[Miller Henry]

Our build it taking a long time, (15+ minutes even when with a massive build 
farm to distribute compiles across), and the question keeps coming up: what is 
actually taking so long.  Is there an easy way to measure?

If there are some top 10 files we might be able to split them (reducing some 
includes).  If it is a link step we might be able to reduce dependencies. Maybe 
a couple unit tests (some frameworks give this information but not all)? I 
don't know how to get data so it is difficult to attack the problem.

We are using cmake 2.8.10.1  (a few random people have 2.8.11-rc1, results are 
encouraging: we intend to update everyone when it is released) on ubuntu lucid.


--

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

[CMake] swig - how do I set compile flags on the generated files?

[Miller Henry]

Our normal coding standards requires zero warnings with -wall -wextra  
(gcc/clang), but often the swig generated file has warnings.   We don't mind 
turning these warnings off for the generated file, but we still want to see 
them for other files in the project.  However I'm stumped on how to do this.

Currently I have

ADD_DEFINITIONS(-Wno-unused-parameter ...)

 which works but it disables the warning for non-generated files as well.

I understand the right way to do this is by:

Set_source_files_property(filename PROPERTIES COMPILE_FLAGS 
-Wno-unused-parameter  ...)

However I don't have filename.  Instead I have myInputfile.i, which gets turns 
into something like myInputFilePYTHON_wrap.cxx.  Of course I can generate this 
name, but that seems fragile: if cmake desides to change the file mangling in 
the future I need to change my algorithm.

So the question is either: is there are good way to get the generated filename, 
or is there a different way I should be doing this?


--

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

Re: [CMake] Query regarding header files in CMakeLists.txt

[Miller Henry]

On a practical matter though: if the file is not listed someplace, then your 
IDE may not pick it up.  Thus while it is legal to not list all files, it is a 
good idea to list them anyway.

-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of 
Brett Delle Grazie
Sent: Tuesday, September 18, 2012 4:35 PM
To: cmake@cmake.org
Subject: [CMake] Query regarding header files in CMakeLists.txt

Hi,

Is it necessary to specify header files in add_executable /
add_library entries in CMakeLists.txt?

i.e. does CMake automatically do dependency analysis making this unnecessary?

--

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

[CMake] speeding up FIND_PACKAGE(Qt4 ...)

[Miller Henry]

We have a cmake based project where cmake runtime is becoming a problem: 
everytime a CMakeLists.txt changes the build takes an extra 40-50 seconds.  Our 
main CMakeLists.txt contains a lot of ADD_SUBDIRECTORY (and little else).   
Most of the subdirectories then call FIND_PACKAGE(Qt4) with various required 
components.  We have found that by moving this call into the top cmake we can 
save around 20 seconds.  However there is objection to doing this because some 
executables don't need all the qt components.(In particular I object to 
linking QtTest into production code)

Is there a way to do the Find package once, and then find individual components 
for link and include purposes separately?  Is there a better way so solve this 
problem?


This is with cmake 2.8.7, but 2.8.8 is if anything slower (at most 1 second, 
I'm not sure if this is significant)

--

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