[Cmake-commits] CMake branch, master, updated. v3.9.0-437-gb17b6db

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  b17b6dbb8e57f159274deec9e458ab421bee09ff (commit)
  from  3a0ef7ac1a50383331f92a19926682d5c1f2682a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b17b6dbb8e57f159274deec9e458ab421bee09ff
commit b17b6dbb8e57f159274deec9e458ab421bee09ff
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Tue Aug 8 00:01:06 2017 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Tue Aug 8 00:01:06 2017 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 6ae436a..e8ea5ee 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 9)
-set(CMake_VERSION_PATCH 20170807)
+set(CMake_VERSION_PATCH 20170808)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[CMake] CMake 3.9.0 Windows zip file shows wrong version

[Adam Getchell]

Hi all,

The CMake 3.9.0 Windows zip file gives the wrong version. Here’s a snippet from 
my AppVeyor logs [1]:

set CMAKE_URL="https://cmake.org/files/v3.9/cmake-3.9.0-win64-x64.zip;
 
appveyor
 DownloadFile %CMAKE_URL% -FileName cmake.zip
 
Downloading
 cmake.zip (25,944,520 bytes)...100%
 7z 
x cmake.zip -oC:\projects\dev
 
 
7-Zip
 [64] 16.04 : Copyright (c) 1999-2016 Igor Pavlov : 2016-10-04
 
 
Scanning
 the drive for archives:
 1 
file, 25944520 bytes (25 MiB)
 
 
Extracting
 archive: cmake.zip
 --
 
Path 
= cmake.zip
 
Type 
= zip
 
Physical
 Size = 25944520
 
 
Everything
 is Ok
 
 
Folders:
 90
 
Files:
 4922
 
Size:
   66584952
 
Compressed:
 25944520
 set 
PATH=%PATH%;C:\projects\dev\cmake\bin
 
cmake
 --version
 
cmake
 version 3.8.2
 
 
CMake
 suite maintained and supported by Kitware (kitware.com/cmake).
 

[1] https://ci.appveyor.com/project/acgetchell/cdt-plusplus
-- 
Adam Getchell
https://keybase.io/adamgetchell

-- 

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 + Gradle for Android

[Jom O'Fisher]

1) There is a folder created for each ABI under the project module folder
(so unique per module per ABI)
2) Gradle doesn't specify language level though you can choose to specify
it yourself from the build.gradle. This doc does a pretty good job of
explaining which variables are set by Gradle:
https://developer.android.com/ndk/guides/cmake.html#variables.
Philosophically, we try to set as little as we can get away with. In
particular, the section titled "Understanding the CMake build command" lays
out exactly what we set. You can also see the folders we specify (one per
module per ABI)
3) Not sure I understand this.

The other document worth taking a look at (if you haven't already) is:
https://developer.android.com/studio/projects/add-native-code.html


On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey 
wrote:

> Thanks Jom
>
> Honestly, I prefer option 1 to work simply because that's how Google's
> officially supporting CMake. But it also has debugging which is the #1
> reason for me.
>
> However, I'd like to understand a lot more about how the integration
> really happens. For example, I have these questions:
>
> 1) How, internally, are CMake build directories managed? Do you
> generate 1 per unique android project? What about for each specific
> platform (x86, armeabi-v7a, etc)?
> 2) Last time I looked into CMake integration, things defined inside
> the CMake scripts were ignored because they are specified at the
> command line. Namely, all of those settings that are driven by the
> Gradle configuration (CXX language level was one in particular I
> think; I specify C++14 support via CMake, but I recall this being
> overridden from outside)?
> 3) How redundant is it to configure individual libraries via the
> gradle scripts? In my previous attempts, I wanted to define common
> stuff for CMake / native code at the root gradle or settings file, and
> only define the differences in the actual gradle build files for each
> corresponding Java target (like, defining the name of the native
> (shared library) target in Gradle, but the command line invocation, -D
> CMake settings, etc would all be common and defined at the root).
>
> The TLDR is, the closer we can stay to CMake's way of doing things and
> keep CMake-related settings self-contained to the CMake scripts
> themselves, the better. This also makes cross-platform easier (we
> build the native code in Windows, for example, so having settings
> specified in the gradle files do not carry over to other platforms.
> Namely, settings that are not platform specific like the C++ language
> level).
>
> If there's a detailed document / wiki I can read on the intrinsics of
> CMake integration in Gradle / Android Studio, I'd love to read it.
> Otherwise, I hope you won't mind if I pick your brain as questions
> come up. I think I'm going to try option 1 for now and see how it
> goes. It's just black box for me because unlike option 2, I have very
> little control over what happens after building the shared libraries,
> and to make up for that I need to really get a deep understanding of
> how it works so I can make sure I code my CMake scripts properly for
> not only Android, but my other platforms as well (non-Android
> platforms).
>
> Thanks again.
>
> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher  wrote:
> > Either option can work fine. Disclosure: I work on Android Studio and was
> > the one that added CMake support.
> >
> > Option (1) is the way it's designed to work and we're working toward
> getting
> > rid of the need for the CMake fork. I can't really say when that will
> happen
> > but if you can get away with an older CMake for now then I'd go this way.
> > As you mentioned, option (1) will allow you to view your source file
> > structure in Android Studio, edit files, and debug using the built-in
> > debugging support.
> >
> > To get option (2) to work, you can use jniDirs setting to tell Android
> > Gradle where to pick up your built .so files (see
> > https://stackoverflow.com/questions/21255125/how-can-i-
> add-so-files-to-an-android-library-project-using-gradle-0-7).
> > I'm not aware of any projects that use this approach but it should work
> in
> > principal.
> >
> > I hope this helps,
> > Jomo
> >
> >
> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey  >
> > wrote:
> >>
> >> Right now I have custom targets set to execute the "ant release"
> >> command after my native targets are built. Part of that command
> >> involves copying *.so files to the libs/armeabi-v7a directory so they
> >> get packaged in an APK.
> >>
> >> When switching to gradle, I have two options:
> >>
> >> 1. Gradle drives CMake: This means using Android Studio and being
> >> locked down to Google's fork of CMake which is a few major releases
> >> behind. I see that as a negative.
> >>
> >> 2. CMake drives Gradle: This would be the same or similar to what I'm
> >> already doing: The custom targets I have 

Re: [CMake] CMake + Gradle for Android

[Robert Dailey]

Thanks Jom

Honestly, I prefer option 1 to work simply because that's how Google's
officially supporting CMake. But it also has debugging which is the #1
reason for me.

However, I'd like to understand a lot more about how the integration
really happens. For example, I have these questions:

1) How, internally, are CMake build directories managed? Do you
generate 1 per unique android project? What about for each specific
platform (x86, armeabi-v7a, etc)?
2) Last time I looked into CMake integration, things defined inside
the CMake scripts were ignored because they are specified at the
command line. Namely, all of those settings that are driven by the
Gradle configuration (CXX language level was one in particular I
think; I specify C++14 support via CMake, but I recall this being
overridden from outside)?
3) How redundant is it to configure individual libraries via the
gradle scripts? In my previous attempts, I wanted to define common
stuff for CMake / native code at the root gradle or settings file, and
only define the differences in the actual gradle build files for each
corresponding Java target (like, defining the name of the native
(shared library) target in Gradle, but the command line invocation, -D
CMake settings, etc would all be common and defined at the root).

The TLDR is, the closer we can stay to CMake's way of doing things and
keep CMake-related settings self-contained to the CMake scripts
themselves, the better. This also makes cross-platform easier (we
build the native code in Windows, for example, so having settings
specified in the gradle files do not carry over to other platforms.
Namely, settings that are not platform specific like the C++ language
level).

If there's a detailed document / wiki I can read on the intrinsics of
CMake integration in Gradle / Android Studio, I'd love to read it.
Otherwise, I hope you won't mind if I pick your brain as questions
come up. I think I'm going to try option 1 for now and see how it
goes. It's just black box for me because unlike option 2, I have very
little control over what happens after building the shared libraries,
and to make up for that I need to really get a deep understanding of
how it works so I can make sure I code my CMake scripts properly for
not only Android, but my other platforms as well (non-Android
platforms).

Thanks again.

On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher  wrote:
> Either option can work fine. Disclosure: I work on Android Studio and was
> the one that added CMake support.
>
> Option (1) is the way it's designed to work and we're working toward getting
> rid of the need for the CMake fork. I can't really say when that will happen
> but if you can get away with an older CMake for now then I'd go this way.
> As you mentioned, option (1) will allow you to view your source file
> structure in Android Studio, edit files, and debug using the built-in
> debugging support.
>
> To get option (2) to work, you can use jniDirs setting to tell Android
> Gradle where to pick up your built .so files (see
> https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7).
> I'm not aware of any projects that use this approach but it should work in
> principal.
>
> I hope this helps,
> Jomo
>
>
> On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey 
> wrote:
>>
>> Right now I have custom targets set to execute the "ant release"
>> command after my native targets are built. Part of that command
>> involves copying *.so files to the libs/armeabi-v7a directory so they
>> get packaged in an APK.
>>
>> When switching to gradle, I have two options:
>>
>> 1. Gradle drives CMake: This means using Android Studio and being
>> locked down to Google's fork of CMake which is a few major releases
>> behind. I see that as a negative.
>>
>> 2. CMake drives Gradle: This would be the same or similar to what I'm
>> already doing: The custom targets I have would execute gradle as a
>> separate build step, instead of running ant commands. I'm not too
>> familiar with Gradle, so I'm not sure how you tell it where your
>> shared libraries are for the APK packaging steps.
>>
>> Which does everyone recommend? Is anyone using one of these setups
>> successfully? The downside to option 2 is probably no on-device native
>> debugging since Android Studio probably can't handle gradle projects
>> without any external CMake builds set up.
>>
>> Would like some general direction & advice before I move away from
>> ANT. Thanks in advance.
>> --
>>
>> 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: 

Re: [CMake] CMake + Gradle for Android

[Jom O'Fisher]

Either option can work fine. Disclosure: I work on Android Studio and was
the one that added CMake support.

Option (1) is the way it's designed to work and we're working toward
getting rid of the need for the CMake fork. I can't really say when that
will happen but if you can get away with an older CMake for now then I'd go
this way.
As you mentioned, option (1) will allow you to view your source file
structure in Android Studio, edit files, and debug using the built-in
debugging support.

To get option (2) to work, you can use jniDirs setting to tell Android
Gradle where to pick up your built .so files (see
https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7).
I'm not aware of any projects that use this approach but it should work in
principal.

I hope this helps,
Jomo


On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey 
wrote:

> Right now I have custom targets set to execute the "ant release"
> command after my native targets are built. Part of that command
> involves copying *.so files to the libs/armeabi-v7a directory so they
> get packaged in an APK.
>
> When switching to gradle, I have two options:
>
> 1. Gradle drives CMake: This means using Android Studio and being
> locked down to Google's fork of CMake which is a few major releases
> behind. I see that as a negative.
>
> 2. CMake drives Gradle: This would be the same or similar to what I'm
> already doing: The custom targets I have would execute gradle as a
> separate build step, instead of running ant commands. I'm not too
> familiar with Gradle, so I'm not sure how you tell it where your
> shared libraries are for the APK packaging steps.
>
> Which does everyone recommend? Is anyone using one of these setups
> successfully? The downside to option 2 is probably no on-device native
> debugging since Android Studio probably can't handle gradle projects
> without any external CMake builds set up.
>
> Would like some general direction & advice before I move away from
> ANT. Thanks in advance.
> --
>
> 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-developers] Linking Apple frameworks

[Eric Wing]

On 8/7/17, Brad King  wrote:
> On 08/05/2017 07:58 PM, Craig Scott wrote:
>> target_link_libraries(foo PRIVATE "-framework AppKit")
>>
>> Strangely, with the library quoted as above, the embedded space
>> is not escaped, leading to the (desirable but surprising) result
>
> Link flags starting in `-` are treated as a raw part of the command
> line.  That's how it evolved historically.
>
>> As extra context, a correct final linker command line can also be achieved
>> like this:
>>
>> find_library(APPKIT_LIB AppKit)
>> target_link_libraries(foo PRIVATE ${APPKIT_LIB})
>>
>> In this case, while APPKIT_LIB contains a full absolute path to the
>> framework, CMake manages to recognise it as a framework and shortens
>> the linker flags to just -framework AppKit.
>
> There is special case logic for this, but IMO it was a mistake.
> Ideally when find_library finds a framework library it should
> return the absolute path to the library file within the framework,
> e.g. `/path/to/foo.framework/foo`.  Then no special logic would
> be needed to recognize it and the library file can be passed
> directly on link lines.  All the Modules/Find*.cmake modules
> that provide imported targets have special logic to transform
> the find_library result in this way.  Perhaps we should fix this
> with a policy.
>
> Also the points raised in Eric Wing's response are valid concerns.
>
> -Brad

I think that would be a mistake because it seems that the only purpose
of this change would be so you could bypass CMake and try to directly
invoke some kind of command line invocation on the dynamic library
inside the .framework bundle. This seems to encourage the wrong kind
of behavior and there is almost no real world use case in the native
Apple world where you should ever do that (I can contrive a couple in
my head for iOS but they are esoteric cases.). In general, you should
be treating the framework bundle as a whole because all parts of it
are designed to be useful. The bundle assets like any .nib files and
the Info.plist are sometimes critical components of the framework. So
things like copying the whole framework and embedding them in the app
bundle are important things to do. And I mentioned the current problem
of codesigning an app bundle. But right now, getting the path to the
entire framework is more useful so you can at least manually do these
things with CMake. Changing that would only complicate this process in
that now you have to play guessing games on what the framework’s
internal layout looks like. (Mac and iOS differ, and there are
esoteric corner cases if you have to deal with a framework that ships
multiple versions.) (And you can imagine this kind of change will
break a ton of my scripts that currently do all this missing steps.)


But if you did decide to change this, I think it should only happen in
conjunction of solving the rest of the needed functionality for
dealing with frameworks, i.e. copying the entire framework bundle into
the app bundle, codesigning the framework in the app bundle, and using
the built in Xcode functionality for this with the Xcode generator.
Also making this a little easier to automatically setup in CMake would
be welcome, and could include things like setting the @rpath on the
frameworks and install_name on the app as part of the process (since
these things always go together with bundling the framework). And
possibly some mechanism that can handle create fat binaries for
deploying an iOS framework but including stripping the simulator
architectures for a release app.


A slight tangent, but kind of related example of the problem is
Android’s new AAR library bundle format. AAR is still horribly broken
and incomplete when it comes to the NDK side (and by looking at the
current rate of progress may never get fixed), but does solve some
serious problems for Android libraries in general so I’m starting to
find they are unfortunately the best solution despite the PITA they
are. AARs share some concepts of the .framework in that they are
container packages that contain a lot of different important
components beyond just the dynamic library stub your native code needs
to link to. Two of the most important features is that it can merge
the R.java resource system and the AndroidManifest.xml that the
library declares it needs to use into your final app. (The way Android
works, all this stuff must be put directly into your app and libraries
don’t officially get their own notion of these things. This makes
integrating/using any library a PITA on Android, so AAR finally starts
automating this process.) But of course the consequence is that once
again, we have an alien library format that CMake doesn’t know how to
deal with yet. I think CMake can eventually be taught, but it requires
that users not be making too many direct assumptions about the build
and linking process, and especially direct invocations of flags.

(And another slight tangent…I’m still working on the 

Re: [CMake] Advice on converting legacy project to modern CMake

[Alan W. Irwin]

On 2017-08-07 11:35- Björn Blissing wrote:


1. Which version if CMake should I target? I.e. Which version should

I require in my cmake_minimum_required() statement?

I would suggest either

cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)

or

cmake_minimum_required(VERSION 3.7.2 FATAL_ERROR)

depending on whether the Cygwin platform (currently only making
3.6.2 available) is important to your users or not.

Cygwin is important to PLplot so we recently adopted 3.6.2 as the
minimum version choice as the compromise between two goals:

(1) We wanted to maximize the version of policies
(which are set by cmake_minimum_required) since the latest
version of policies typically make a lot of sense to us
in terms of eliminating subtle build-system bugs.

(2) We wanted to minimize the minimum version to maximize the
percentage of our users who will have that minimum version or higher
available from the official binary CMake version that is supplied by
their software distribution.

3.6.2 currently satisfies goal (1) reasonably well because it is not too far
behind the latest version 3.9.0 in terms of policy.

3.6.2 also satisfies goal (2) reasonably well.  The major exception
here is the so-called Linux "enterprise-class" distributions who go
out of their way to **only** support old versions of Linux software
because their customers somehow feel more comfortable with that.  For
example, as far as I can tell from google searches, it looks like
RedHat Linux Enterprise versions still only support CMake-2.

Which leads to a question I have for the Kitware types here.  What
should I suggest to my Linux enterprise distribution users? Can they
simply download and use the latest Linux binary version of CMake that
is distributed by Kitware or are there library version
incompatibilities that make that option non-viable? Alternatively, if
such users want to build modern CMake for themselves can they do that
or do system library incompatibilities stop them in that case as well?

If we ignore the "enterprise-class" users, then Debian stable supports
3.7.2.  Debian tends to be a bit of a late adopter so as far as I know
every other non-enterprise Linux distribution and the various *BSD
distributions supports that version of CMake or higher. And I know
that is also true for MinGW-w64/MSYS2 and the Mac OS X distributions
(Homebrew, MacPorts, and Fink).  So I plan to bump the minimum version
we support to 3.7.2 as soon as Cygwin (currently only supporting
3.6.2) falls into line with the rest.

I haven't mentioned the Windows MSVC platform here yet which is also
important to us.  But those users are given no official choice of
CMake as a binary download so they likely take another viable choice
which is to download, install, and use a Kitware binary version of
CMake for Windows, and as far as I know all released versions of
CMake-3 (as well as CMake-2) are available that way.

In any case, for whatever minimum version of CMake you adopt, you
should test your build system for that version as well as at least the
latest CMake version.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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 + Gradle for Android

[Robert Dailey]

Right now I have custom targets set to execute the "ant release"
command after my native targets are built. Part of that command
involves copying *.so files to the libs/armeabi-v7a directory so they
get packaged in an APK.

When switching to gradle, I have two options:

1. Gradle drives CMake: This means using Android Studio and being
locked down to Google's fork of CMake which is a few major releases
behind. I see that as a negative.

2. CMake drives Gradle: This would be the same or similar to what I'm
already doing: The custom targets I have would execute gradle as a
separate build step, instead of running ant commands. I'm not too
familiar with Gradle, so I'm not sure how you tell it where your
shared libraries are for the APK packaging steps.

Which does everyone recommend? Is anyone using one of these setups
successfully? The downside to option 2 is probably no on-device native
debugging since Android Studio probably can't handle gradle projects
without any external CMake builds set up.

Would like some general direction & advice before I move away from
ANT. Thanks in advance.
-- 

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] with 3.9 my testprj breaks: mylib_autogen/include: No such file or directory

[Brad King]

On 08/07/2017 09:01 AM, Steffen Dettmer wrote:
> this cmake version does not compile my test project anymore
> (v.3.8.2: OK; v3.9.0: FAIL). There is an include path to
> $buildir/$subproject/mylib_autogen/include as -I for g++, but
> this directory does not exist and I get:
> 
>   cc1plus: error [...] No such file or directory.
> 
> If I manually create this include directory it compiles.

Please open an issue for this and provide a sample project
showing the problem.

Thanks,
-Brad
-- 

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] with cmake-3.9 my testprj breaks, I need to add "add_executable(Qt4::rcc IMPORTED)"

[Robert Maynard]

Did this work pre CMake 3.9?

On Mon, Aug 7, 2017 at 8:49 AM, Steffen Dettmer
 wrote:
> Hi,
>
> I have a cmake test project that builds a "hello world" with our
> cross toolchain. There are selfmade TOOLCHAINFILES for the
> targets. They define QT variables like:
>
>   set(BT_QT_4_7_3_PATH.../taget/Qt-4.7.3)
>   set(QT_BINARY_DIR${BT_QT_4_7_3_PATH}/bin)
>   set(QT_LIBRARY_DIR   ${BT_QT_4_7_3_PATH}/lib)
>   set(QT_MOC_EXECUTABLE${QT_BINARY_DIR}/moc)
>
> and so on. I tested a fix for [1] with master branch and then
> also v3.9.0, but my project suddenly gets errors:
>
>   $ git clone $r/helloworld && cd helloworld &&
> mkdir target4 && cd target4 &&
> /local/users/sdettmer/work/cmake/b/bin/cmake \
>  -DCMAKE_TOOLCHAIN_FILE=$TC/$TARGET.cmake  ..
>   -- The C compiler identification is GNU 4.4.3
>   [...normal output...]
>   -- Configuring done
>   CMake Error: Qt4::rcc target not found hello_world
>   CMake Error: Qt4::rcc target not found mylib1
>   CMake Error: Qt4::rcc target not found mylib2
>   -- Generating done
>   -- Build files have been written to: /local/sdettmer/work/helloworld/target4
>
> The "CMake Error:" lines are new. Please note, that I don't use QT rcc at all.
>
> I noticed that I can work around this by adding:
>
>   set(QT_RCC_EXECUTABLE ${QT_BINARY_DIR}/rcc)
>   if (NOT TARGET Qt4::rcc)
> add_executable(Qt4::rcc IMPORTED)
>   endif()
>
> to my TOOLCHAINFILE, but I don't understand why. moc, for
> example, needs no such thing, but rcc does, but this one is not
> even used.
>
> The message seems to come from C++ part, could it be that some QT
> depenency slipped into the cmake (C++) code by accident?
>
> Also after the error it tells "Generating done". Does this mean
> the error actually is a warning I could ignore?
>
> Steffen
>
>
>
>
>
> [1] https://gitlab.kitware.com/cmake/cmake/issues/16920
> --
>
> 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] Coverage support

[Konstantin Tokarev]

  07.08.2017, 20:50, "Clément Gregoire" :This is mainly why I started this thread, I want to know the best way to do this without using those variables.CMAKE_lang_FLAGS is a pain as soon as someone wants to use add_subdirectory (be it to add an external project or your project being used in another) or a user wants to change the value. Those variables should really only be set by the toolchain file or from the command-line.There's ExternalProject for this purpose Other solutions were mentioned in my first mail, the easiest one being to add a new build type.The other option is to uses something like a special script that will set those variables before your Cmakelists.txt (ie a toolchain file).  Le lun. 7 août 2017 à 17:22, Konstantin Tokarev  a écrit : 07.08.2017, 17:24, "Clément Gregoire" :>> I usually stop reading Cmakelists.txt as soon as I see this set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0>> -fprofile-arcs -ftest-coverage") The pthread thing there is likely wrong anyway, and the -Wall is entirely optional. The other things are needed, otherwise gcov will not produce any useful output.>> I don't have an issue with the flags per se, but with the usage of set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern cmake scripts.How can one set global compiler flags without use of CMAKE_CXX_FLAGS or setting flags for each individual target?>>> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test>> target, which seems to be a difficult to scale on big projects No, you don't. It's entirely fine if you just run "make test" as I do in OSM2go.> From what I saw in the documentation of the script :>>> # Param _testrunner The name of the target which runs the tests>> It seems to call directly the command named _testrunner, which is somehow confirmed from the cmakelists :>>> # src/CMakelists.txt>> add_executable(tests ${TEST_FILES}) # Linking up all libraries target_link_libraries(tests complex) add_test(NAME example_test COMMAND tests)>> # CMakelists.txt>> setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage)> From this I deduce that you need to call setup_target_for_coverage for each different test executable.>> 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer :>> Am 2017-08-07 11:06, schrieb Clément Gregoire:>> I usually stop reading Cmakelists.txt as soon as I see this set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0>> -fprofile-arcs -ftest-coverage") The pthread thing there is likely wrong anyway, and the -Wall is entirely optional. The other things are needed, otherwise gcov will not produce any useful output. Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test>> target, which seems to be a difficult to scale on big projects No, you don't. It's entirely fine if you just run "make test" as I do in OSM2go. Eike>> -- 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-- Regards,Konstantin  -- Regards,Konstantin -- 

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] Coverage support

[Clément Gregoire]

This is mainly why I started this thread, I want to know the best way to do
this without using those variables.
CMAKE_lang_FLAGS is a pain as soon as someone wants to use add_subdirectory
(be it to add an external project or your project being used in another) or
a user wants to change the value. Those variables should really only be set
by the toolchain file or from the command-line.

Other solutions were mentioned in my first mail, the easiest one being to
add a new build type.
The other option is to uses something like a special script that will set
those variables before your Cmakelists.txt (ie a toolchain file).



Le lun. 7 août 2017 à 17:22, Konstantin Tokarev  a
écrit :

>
>
> 07.08.2017, 17:24, "Clément Gregoire" :
> >> I usually stop reading Cmakelists.txt as soon as I see this
> >>
> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
> >> -fprofile-arcs -ftest-coverage")
> >>
> >> The pthread thing there is likely wrong anyway, and the -Wall is
> entirely optional. The other things are needed, otherwise gcov will not
> produce any useful output.
> >
> > I don't have an issue with the flags per se, but with the usage of
> set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern
> cmake scripts.
>
> How can one set global compiler flags without use of CMAKE_CXX_FLAGS or
> setting flags for each individual target?
>
> >
> >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
> >> target, which seems to be a difficult to scale on big projects
> >>
> >> No, you don't. It's entirely fine if you just run "make test" as I do
> in OSM2go.
> > From what I saw in the documentation of the script :
> >
> >> # Param _testrunner The name of the target which runs the tests
> >
> > It seems to call directly the command named _testrunner, which is
> somehow confirmed from the cmakelists :
> >
> >> # src/CMakelists.txt
> >> add_executable(tests ${TEST_FILES})
> >>
> >> # Linking up all libraries
> >>
> >> target_link_libraries(tests complex)
> >>
> >> add_test(NAME example_test COMMAND tests)
> >> # CMakelists.txt
> >> setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage)
> > From this I deduce that you need to call setup_target_for_coverage for
> each different test executable.
> >
> > 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer :
> >> Am 2017-08-07 11:06, schrieb Clément Gregoire:
> >> I usually stop reading Cmakelists.txt as soon as I see this
> >>
> >> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
> >> -fprofile-arcs -ftest-coverage")
> >>
> >> The pthread thing there is likely wrong anyway, and the -Wall is
> entirely optional. The other things are needed, otherwise gcov will not
> produce any useful output.
> >>
> >> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
> >> target, which seems to be a difficult to scale on big projects
> >>
> >> No, you don't. It's entirely fine if you just run "make test" as I do
> in OSM2go.
> >>
> >> Eike
> >> --
> >>
> >> 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
>
>
> --
> Regards,
> Konstantin
>
-- 

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 

Re: [CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

[Robert Maynard]

It is great to hear that you have been able to resolve the compilation
issues with CMake, though it is very weird and worry some that only
formatting your machine would resolve the issue.

1) The error code you are getting (46-cudaErrorDevicesUnavailable )
generally means that another CUDA program is running and is either
holding an exclusive lock on the GPU or maybe the GPU is configured to
only run OpenGL or CUDA, and not both at the same time. My instinct is
to run 'c:\Program Files\NVIDIA Corporation\NVSMI>nvidia-smi -q' and
see if anything is using the GPU, but I don't remember if that ability
is offered only for Quadro/Tesla cards.

2) To setup and run the CMake CUDA tests you are missing 2 lines, which are:

set(ENV{PATH} "$ENV{PATH};C:/Program Files/NVIDIA GPU Computing
Toolkit/CUDA/v7.5/bin")
set(dashboard_cache "CMake_TEST_CUDA:BOOL=ON")

These lines should be placed before the
`include(${CTEST_SCRIPT_DIRECTORY}/cmake_common.cmake)`. For reference
see: https://open.cdash.org/viewNotes.php?buildid=5008534

Now to run the dashboard you would do something like the following.
This will build cmake, all the cmake tests, and upload the results:

ctest -S C:\projects\cmake_dev\Dashboards\CMakeScripts\bjd_dashboard.cmake -VV




On Sun, Aug 6, 2017 at 2:37 PM, Brian Davis  wrote:
>
> Upon:
>
> wiping Dell 7559 (yes the weirdness has gotten this bad), reinstalling from
> Dell Factory image
> upgrading system to Latest Win 10 (now not in developer mode anymore)
> Dell update to get latest drivers and other goobly bits
> Removing all Virus Scanners to keep this from possibly interfering
> Installing Visual Studio 2013 Community
> Installing CUDA 7.5 and packaged driver
> Imagining with Clonezilla for posterity sake in case... uhhh... when windows
> acts up again.
>
> These statements:
>
>>
>> Regarding 960M and CUDA  7.5/7.5, 8.0/7.5, and 7.7/9.0
>>
>> Answer is:
>>
>> 960M was likely released post CUDA  7.5 driver and possibly post 8.0.
>> Seems that architecture differences do not allow old drivers to work on
>> newer arch cards.   Once 9.0 driver was released... 7.5 run time worked with
>> 9.0 driver, but for some reason not 8.0.  Seems CUDA and Nvidia
>> Runtime/Drivers have a dirty little secret much like Java and the runtimes.
>>
>> At this point I cannot get CMake 3.2 or 3.9 to work with CUDA 7.5/9.0, VS
>> 13, on Win10Pro/Enterprise.  And from the state of doc it seems not worth my
>> effort to even try anymore.
>
>
> Are NOT correct.  The 7559 does work with CUDA 7.5 and runtime (all that is
> required is to wipe windows and start form scratch... no surprise there):
>
> C:\ProgramData\NVIDIA Corporation\CUDA
> Samples\v7.5\1_Utilities\deviceQuery\../../bin/win64/Debug/deviceQuery.exe
> Starting...
>
>
>  CUDA Device Query (Runtime API) version (CUDART static linking)
>
> Detected 1 CUDA Capable device(s)
>
> Device 0: "GeForce GTX 960M"
>   CUDA Driver Version / Runtime Version  7.5 / 7.5
>   CUDA Capability Major/Minor version number:5.0
>   Total amount of global memory: 4096 MBytes (4294967296
> bytes)
>   ( 5) Multiprocessors, (128) CUDA Cores/MP: 640 CUDA Cores
>   GPU Max Clock rate:1176 MHz (1.18 GHz)
>   Memory Clock rate: 2505 Mhz
>   Memory Bus Width:  128-bit
>   L2 Cache Size: 2097152 bytes
>   Maximum Texture Dimension Size (x,y,z) 1D=(65536), 2D=(65536,
> 65536), 3D=(4096, 4096, 4096)
>   Maximum Layered 1D Texture Size, (num) layers  1D=(16384), 2048 layers
>   Maximum Layered 2D Texture Size, (num) layers  2D=(16384, 16384), 2048
> layers
>   Total amount of constant memory:   65536 bytes
>   Total amount of shared memory per block:   49152 bytes
>   Total number of registers available per block: 65536
>   Warp size: 32
>   Maximum number of threads per multiprocessor:  2048
>   Maximum number of threads per block:   1024
>   Max dimension size of a thread block (x,y,z): (1024, 1024, 64)
>   Max dimension size of a grid size(x,y,z): (2147483647, 65535, 65535)
>   Maximum memory pitch:  2147483647 bytes
>   Texture alignment: 512 bytes
>   Concurrent copy and kernel execution:  Yes with 1 copy engine(s)
>   Run time limit on kernels: Yes
>   Integrated GPU sharing Host Memory:No
>   Support host page-locked memory mapping:   Yes
>   Alignment requirement for Surfaces:Yes
>   Device has ECC support:Disabled
>   CUDA Device Driver Mode (TCC or WDDM): WDDM (Windows Display
> Driver Model)
>   Device supports Unified Addressing (UVA):  Yes
>   Device PCI Domain ID / Bus ID / location ID:   0 / 2 / 0
>   Compute Mode:
>  < Default (multiple host threads can use ::cudaSetDevice() with device
> 

Re: [CMake] Coverage support

[Konstantin Tokarev]

07.08.2017, 17:24, "Clément Gregoire" :
>> I usually stop reading Cmakelists.txt as soon as I see this
>>
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
>> -fprofile-arcs -ftest-coverage")
>>
>> The pthread thing there is likely wrong anyway, and the -Wall is entirely 
>> optional. The other things are needed, otherwise gcov will not produce any 
>> useful output.
>
> I don't have an issue with the flags per se, but with the usage of 
> set(CMAKE_CXX_FLAGS). Setting flags like that should be banned from modern 
> cmake scripts.

How can one set global compiler flags without use of CMAKE_CXX_FLAGS or setting 
flags for each individual target?

>
>> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
>> target, which seems to be a difficult to scale on big projects
>>
>> No, you don't. It's entirely fine if you just run "make test" as I do in 
>> OSM2go.
> From what I saw in the documentation of the script :
>
>> # Param _testrunner The name of the target which runs the tests
>
> It seems to call directly the command named _testrunner, which is somehow 
> confirmed from the cmakelists :
>
>> # src/CMakelists.txt
>> add_executable(tests ${TEST_FILES})
>>
>> # Linking up all libraries
>>
>> target_link_libraries(tests complex)
>>
>> add_test(NAME example_test COMMAND tests)
>> # CMakelists.txt
>> setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage)
> From this I deduce that you need to call setup_target_for_coverage for each 
> different test executable.
>
> 2017-08-07 13:37 GMT+02:00 Rolf Eike Beer :
>> Am 2017-08-07 11:06, schrieb Clément Gregoire:
>> I usually stop reading Cmakelists.txt as soon as I see this
>>
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
>> -fprofile-arcs -ftest-coverage")
>>
>> The pthread thing there is likely wrong anyway, and the -Wall is entirely 
>> optional. The other things are needed, otherwise gcov will not produce any 
>> useful output.
>>
>> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
>> target, which seems to be a difficult to scale on big projects
>>
>> No, you don't. It's entirely fine if you just run "make test" as I do in 
>> OSM2go.
>>
>> Eike
>> --
>>
>> 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


-- 
Regards,
Konstantin
-- 

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] HOWTO cmake compatiblity?

[Steffen Dettmer]

On Mon, Aug 7, 2017 at 3:44 PM, Rolf Eike Beer  wrote:
> Steffen Dettmer wrote:
>> So far I think we need to install cmake into a versionized
>> directory and invoke it:
>>
>>   v1.0.0/bin/cmake -DTOOLCHAIN=v1.0.0/target1.cmake
>>
>> and maybe remove cmake from PATH to ensure a failure if
>> accidentally calling "cmake".
>>
>> What do you think?
>
> Having multiple parallel versions of CMake in different directories works.

Yes, it definetly works, I tested with 3.0.2 and 3.6.2.

My question is how it is intended to be used, what works best.

Steffen
-- 

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-commits] CMake branch, master, updated. v3.9.0-436-g3a0ef7a

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  3a0ef7ac1a50383331f92a19926682d5c1f2682a (commit)
   via  5150c3527df55f84e896177f6bbec0315d6c1349 (commit)
   via  ccc98b5cbe100d6de2be139289c0c5282199bdb3 (commit)
   via  a13716a5dc1277d46beebffe6304214c22cf6ae3 (commit)
   via  6d83757f2620413918f76de975cd38efa3157416 (commit)
   via  74a1b8ebdeaca81e0654a7e40f78c36cef265025 (commit)
   via  ddd6f0db1ea7e1cda13ce7f86361193548a6c47d (commit)
   via  e2c9cf12d12c23a0ef68801b8a9ac4b832ea88bc (commit)
   via  3a4840e0395133e0b28d5b1f424bf7365b5dd0e6 (commit)
  from  1f20aff2a69160c36002781ed91b6998fc4587ac (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3a0ef7ac1a50383331f92a19926682d5c1f2682a
commit 3a0ef7ac1a50383331f92a19926682d5c1f2682a
Merge: 1f20aff 5150c35
Author: Brad King 
AuthorDate: Mon Aug 7 14:34:45 2017 +
Commit: Kitware Robot 
CommitDate: Mon Aug 7 10:34:48 2017 -0400

Merge topic 'autogen-configs'

5150c352 Autogen: Add release notes for per-config include dir
ccc98b5c Autogen: Update documentation for per-config include dir
a13716a5 Autogen: Enable per-config support
6d83757f Autogen: Generate rcc wrapper file on demand
74a1b8eb Autogen: Fix configuration suffix initialization
ddd6f0db Autogen: Add per-config suffix to moc_predefs.h
e2c9cf12 Autogen: Remove per-config suffix for mocs_compilations.cpp
3a4840e0 Autogen: Make test per-config include directory compatible

Acked-by: Kitware Robot 
Merge-request: !1107


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5150c3527df55f84e896177f6bbec0315d6c1349
commit 5150c3527df55f84e896177f6bbec0315d6c1349
Author: Sebastian Holtermann 
AuthorDate: Sun Jul 23 16:38:59 2017 +0200
Commit: Sebastian Holtermann 
CommitDate: Sat Aug 5 15:06:16 2017 +0200

Autogen: Add release notes for per-config include dir

diff --git a/Help/release/dev/autogen-configs.rst 
b/Help/release/dev/autogen-configs.rst
new file mode 100644
index 000..7613c68
--- /dev/null
+++ b/Help/release/dev/autogen-configs.rst
@@ -0,0 +1,8 @@
+autogen-configs
+---
+
+* When using :prop_tgt:`AUTOMOC` or :prop_tgt:`AUTOUIC` with a
+  multi configuration generator (e.g. :generator:`Xcode`),
+  included ``*.moc``,  ``moc_*.cpp`` and ``ui_*.h`` files are generated in
+  ``/include_`` instead of
+  ``/include``.

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccc98b5cbe100d6de2be139289c0c5282199bdb3
commit ccc98b5cbe100d6de2be139289c0c5282199bdb3
Author: Sebastian Holtermann 
AuthorDate: Sun Jul 23 16:20:17 2017 +0200
Commit: Sebastian Holtermann 
CommitDate: Sat Aug 5 15:01:28 2017 +0200

Autogen: Update documentation for per-config include dir

diff --git a/Help/manual/cmake-qt.7.rst b/Help/manual/cmake-qt.7.rst
index 00d6e6e..b3b09d1 100644
--- a/Help/manual/cmake-qt.7.rst
+++ b/Help/manual/cmake-qt.7.rst
@@ -72,6 +72,9 @@ Included ``moc_*.cpp`` and ``*.moc`` files will be generated 
in the
 automatically added to the target's :prop_tgt:`INCLUDE_DIRECTORIES`.
 (This differs from CMake 3.7 and below; see their documentation for details.)
 
+* For multi configuration generators, the include directory is
+  ``/include_``.
+
 * See :prop_tgt:`AUTOGEN_BUILD_DIR`.
 
 Not included ``moc_.cpp`` files will be generated in custom
@@ -117,6 +120,9 @@ The generated generated ``ui_*.h`` files are placed in the
 automatically added to the target's :prop_tgt:`INCLUDE_DIRECTORIES`.
 (This differs from CMake 3.7 and below; see their documentation for details.)
 
+* For multi configuration generators, the include directory is
+  ``/include_``.
+
 * See :prop_tgt:`AUTOGEN_BUILD_DIR`.
 
 The :prop_tgt:`AUTOUIC` target property may be pre-set for all following
diff --git a/Help/prop_tgt/AUTOMOC.rst b/Help/prop_tgt/AUTOMOC.rst
index 0171d20..e70fe0d 100644
--- a/Help/prop_tgt/AUTOMOC.rst
+++ b/Help/prop_tgt/AUTOMOC.rst
@@ -20,6 +20,9 @@ source files at build time and invoke moc accordingly.
   This allows the compiler to find the included ``moc_.cpp`` file
   regardless of the location the original source.
 
+  * For multi configuration generators, the include directory is
+``/include_``.
+
   * See :prop_tgt:`AUTOGEN_BUILD_DIR`.
 
 * If an ``#include`` statement like ``#include ".moc"`` is found,
diff --git a/Help/prop_tgt/AUTOUIC.rst b/Help/prop_tgt/AUTOUIC.rst
index 6493bbc..2fc2167 100644
--- a/Help/prop_tgt/AUTOUIC.rst
+++ 

Re: [CMake] Coverage support

[Clément Gregoire]

>
> I usually stop reading Cmakelists.txt as soon as I see this
>
>
>
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
>
>
> -fprofile-arcs -ftest-coverage")
>
>
>
> The pthread thing there is likely wrong anyway, and the -Wall is entirely
> optional. The other things are needed, otherwise gcov will not produce any
> useful output.
>


I don't have an issue with the flags per se, but with the usage of
set(CMAKE_CXX_FLAGS).
Setting flags like that should be banned from modern cmake scripts.


Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
>
>
> target, which seems to be a difficult to scale on big projects
>
>
>
> No, you don't. It's entirely fine if you just run "make test" as I do in
> OSM2go.
>

>From what I saw in the documentation of the script :


# Param _testrunner The name of the target which runs the tests


It seems to call directly the command named _testrunner, which is somehow
confirmed from the cmakelists :



# src/CMakelists.txt
add_executable(tests ${TEST_FILES})
# Linking up all libraries
target_link_libraries(tests complex)

add_test(NAME example_test COMMAND tests)
# CMakelists.txt
setup_target_for_coverage(${PROJECT_NAME}_coverage tests coverage)


>From this I deduce that you need to call setup_target_for_coverage for each
different test executable.



2017-08-07 13:37 GMT+02:00 Rolf Eike Beer :

> Am 2017-08-07 11:06, schrieb Clément Gregoire:
>
>> I usually stop reading Cmakelists.txt as soon as I see this
>>
>> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
>> -fprofile-arcs -ftest-coverage")
>>
>
> The pthread thing there is likely wrong anyway, and the -Wall is entirely
> optional. The other things are needed, otherwise gcov will not produce any
> useful output.
>
> Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
>> target, which seems to be a difficult to scale on big projects
>>
>
> No, you don't. It's entirely fine if you just run "make test" as I do in
> OSM2go.
>
>
> Eike
> --
>
> 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/opensou
> rce/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] HOWTO cmake compatiblity?

[Rolf Eike Beer]

Steffen Dettmer wrote:

[…]


So far I think we need to install cmake into a versionized
directory and invoke it:

  v1.0.0/bin/cmake -DTOOLCHAIN=v1.0.0/target1.cmake

and maybe remove cmake from PATH to ensure a failure if
accidentally calling "cmake".

What do you think?


Having multiple parallel versions of CMake in different directories 
works.


Greetings,

Eike
--
--

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-developers] Linking Apple frameworks

[Brad King]

On 08/05/2017 07:58 PM, Craig Scott wrote:
> target_link_libraries(foo PRIVATE "-framework AppKit")
> 
> Strangely, with the library quoted as above, the embedded space
> is not escaped, leading to the (desirable but surprising) result

Link flags starting in `-` are treated as a raw part of the command
line.  That's how it evolved historically.

> As extra context, a correct final linker command line can also be achieved 
> like this:
> 
> find_library(APPKIT_LIB AppKit)
> target_link_libraries(foo PRIVATE ${APPKIT_LIB})
> 
> In this case, while APPKIT_LIB contains a full absolute path to the
> framework, CMake manages to recognise it as a framework and shortens
> the linker flags to just -framework AppKit.

There is special case logic for this, but IMO it was a mistake.
Ideally when find_library finds a framework library it should
return the absolute path to the library file within the framework,
e.g. `/path/to/foo.framework/foo`.  Then no special logic would
be needed to recognize it and the library file can be passed
directly on link lines.  All the Modules/Find*.cmake modules
that provide imported targets have special logic to transform
the find_library result in this way.  Perhaps we should fix this
with a policy.

Also the points raised in Eric Wing's response are valid concerns.

-Brad
-- 

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

[CMake] HOWTO cmake compatiblity?

[Steffen Dettmer]

Hi,

I like to learn how you use cmake in environments were
reproducibility is an issue.



Background:

We are used to simply install cmake in default $PATH, but I
noticed cmake is not backward-compatible. Of course this is not
surprising, it is really complex with many nice features and of
course things evolve, so this is fine.

As we are supposed to be reproducible (i.e. reproduce old
versions in future), we need a way to maintain compatiblity. So
far we use defined virtual machines, which have to be archived by
each change, and inside install our compiler toolchains in
versionized directories. So far this was simple because we just
put the needed paths into the TOOLCHAINFILE.cmake files (cmake
-DTOOLCHAIN=v1.0.0/target1.cmake -- which internally sets CC to
v1.0.0/gcc-1.2.3/bin/a-b-c-gcc etc). This only works if the
correct cmake version is called of course. To avoid depending on
users PATH (we made bad experiences in the past with that), we
like to have a dedicated way to call cmake.



First thoughs:

So far I think we need to install cmake into a versionized
directory and invoke it:

  v1.0.0/bin/cmake -DTOOLCHAIN=v1.0.0/target1.cmake

and maybe remove cmake from PATH to ensure a failure if
accidentally calling "cmake".

What do you think?

>From autotools I know that via alternatives there are things like
"autoconf-1.4" pointing to the appropriate autoconf version. This
seems to be more comfortable to use. Is something like this
possible with cmake?

At least we could install cmake in a versionized directory and
add an appropriate symbolic link into $PATH. What do you think?

cmake internally has mechanisms to find the correct "Modules"
etc, so multiple versions can be installed at the same time
easily. Is there some standard way to select between these multiple
versions?

Any thoughts appreciated,

Steffen
-- 

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] with 3.9 my testprj breaks: mylib_autogen/include: No such file or directory

[Steffen Dettmer]

Hi,

I made a fix for [1] and tested cmake master branch, but noticed
that this cmake version does not compile my test project anymore
(v.3.8.2: OK; v3.9.0: FAIL). There is an include path to
$buildir/$subproject/mylib_autogen/include as -I for g++, but
this directory does not exist and I get:

  cc1plus: error [...] No such file or directory.

If I manually create this include directory it compiles.

I guess it could be that the "mylib_autogen" directory (which is
created automatically) and its subdirectory "include" (which, at
least in my case, it not created automatically) are some new
feature. I guess, the *.moc files were moved into the autogen
diretories. In the autogen directory, I have only one file
"mocs_compilation.cpp" with the soley contents:

  /* This file is autogenerated, do not edit*/
  enum some_compilers { need_more_than_nothing };

which looks like a kind of dummy (it could be that this test lib
does not need any moc compilation).

We are using QT as described in [2].

Could it a bug that this include directory is not created in the
special case it is empty?

How to upgrade such projects to be compatible with cmake-3.9?

Steffen

[1] https://gitlab.kitware.com/cmake/cmake/issues/16920
[2] 
https://stackoverflow.com/questions/36570791/how-can-i-use-cmakes-automoc-feature-with-a-custom-qt-package
-- 

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] nagfor, Ninja, and Missing variable is: CMAKE_Fortran_PREPROCESS_SOURCE

[Josh Hykes]

Hello,

I was trying to build my Fortran project with nagfor using the Ninja
generator. I ran into the below error. I am using cmake version 3.9.0.

I found a discussion of a similar error at

http://public.kitware.com/pipermail/cmake/2016-December/064710.html

If I add the following line for the NAG compiler, then the error goes away:

set(CMAKE_Fortran_PREPROCESS_SOURCE
" -fpp-F 
-o ")

I thought I should mention this in case you wanted to add it to CMake.

-Josh


$ cmake ../test -GNinja -DCMAKE_BUILD_TYPE=DEBUG
-DCMAKE_Fortran_COMPILER=nagfor
-- The C compiler identification is GNU 4.5.1
-- The CXX compiler identification is GNU 4.5.1
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The Fortran compiler identification is NAG 6.1.6120
-- Detecting NAG Fortran directory
-- Detecting NAG Fortran directory -
/home/joshua/opt/nag/nagfor_6120/lib/NAG_Fortran
-- Check for working Fortran compiler:
/home/joshua/opt/nag/nagfor_6120/bin/nagfor
CMake Error: Error required internal CMake variable not set, cmake may not
be built correctly.
Missing variable is:
CMAKE_Fortran_PREPROCESS_SOURCE
CMake Error at
/home/joshua/opt/cmake/cmake-3.9.0-Linux-x86_64/share/cmake-3.9/Modules/CMakeTestFortranCompiler.cmake:30
(try_compile):
  Failed to generate test project build system.
Call Stack (most recent call first):
  CMakeLists.txt:5 (enable_language)


-- Configuring incomplete, errors occurred!
-- 

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] with cmake-3.9 my testprj breaks, I need to add "add_executable(Qt4::rcc IMPORTED)"

[Steffen Dettmer]

Hi,

I have a cmake test project that builds a "hello world" with our
cross toolchain. There are selfmade TOOLCHAINFILES for the
targets. They define QT variables like:

  set(BT_QT_4_7_3_PATH.../taget/Qt-4.7.3)
  set(QT_BINARY_DIR${BT_QT_4_7_3_PATH}/bin)
  set(QT_LIBRARY_DIR   ${BT_QT_4_7_3_PATH}/lib)
  set(QT_MOC_EXECUTABLE${QT_BINARY_DIR}/moc)

and so on. I tested a fix for [1] with master branch and then
also v3.9.0, but my project suddenly gets errors:

  $ git clone $r/helloworld && cd helloworld &&
mkdir target4 && cd target4 &&
/local/users/sdettmer/work/cmake/b/bin/cmake \
 -DCMAKE_TOOLCHAIN_FILE=$TC/$TARGET.cmake  ..
  -- The C compiler identification is GNU 4.4.3
  [...normal output...]
  -- Configuring done
  CMake Error: Qt4::rcc target not found hello_world
  CMake Error: Qt4::rcc target not found mylib1
  CMake Error: Qt4::rcc target not found mylib2
  -- Generating done
  -- Build files have been written to: /local/sdettmer/work/helloworld/target4

The "CMake Error:" lines are new. Please note, that I don't use QT rcc at all.

I noticed that I can work around this by adding:

  set(QT_RCC_EXECUTABLE ${QT_BINARY_DIR}/rcc)
  if (NOT TARGET Qt4::rcc)
add_executable(Qt4::rcc IMPORTED)
  endif()

to my TOOLCHAINFILE, but I don't understand why. moc, for
example, needs no such thing, but rcc does, but this one is not
even used.

The message seems to come from C++ part, could it be that some QT
depenency slipped into the cmake (C++) code by accident?

Also after the error it tells "Generating done". Does this mean
the error actually is a warning I could ignore?

Steffen





[1] https://gitlab.kitware.com/cmake/cmake/issues/16920
-- 

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] Advice on converting legacy project to modern CMake

[Rolf Eike Beer]

Am 2017-08-07 11:57, schrieb Björn Blissing:

Hi Eike,


3. Some of my legacy projects have all source in the same directory,
i.e. both source and header files are in the same directory. Others
have both private and public headers in the same directory. How do I
handle this with target_include_directories()? Preferably I would 
like

to avoid reorganizing the file structure.


If things are in the same directory you don't need
target_include_directories(), as the header files will be found anyway
if you use "" (probably also <>). If they are in a different directory
it doesn't matter if the private and public things are mixed, you need
to add that directory anyway.


Lets see if I understood what you are suggesting correctly:

Alternative 1: If both source and headers are in the same directory.
===
Solution: Omit the target_include_directories() statement completely
and just add the private and public header files in the add_library()
statement and the public headers in the install(FILES ...) statement.


Alternative 2: If source and headers are separated but both private
and public headers are included in the same directory.
===
Solution: Add the private and public header files in the add_library()
statement . Then add a target_include_directories() statement such as:
target_include_directories(anvil_lib PUBLIC
$
$
)

Then add the public headers in the install(FILES ...) statement.


Yes.


Is this correct? Follow up question: Since the directory include
contains both public and private headers should the
target_include_directories() be specified as PUBLIC or PRIVATE?


I would make it public: less code, and the private headers will simply 
not exist when installed.


Eike
--

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] Advice on converting legacy project to modern CMake

[Rolf Eike Beer]

Am 2017-08-07 11:35, schrieb Björn Blissing:

Hi,

I have some legacy projects which I intend to update to modern CMake.
The documentation is good but do not really cover "best practices". So
I have some questions which I hope some of you could help to answer:

1. Which version if CMake should I target? I.e. Which version should I
require in my cmake_minimum_required() statement?


If you want to have support for compile feature (i.e. automatically 
selecting C++11 if needed), then you should use at least 3.1. I 
personally don't see a reason to start lower anyway, if someone wants to 
build your new software, getting a new CMake shouldn't a problem anyway.



3. Some of my legacy projects have all source in the same directory,
i.e. both source and header files are in the same directory. Others
have both private and public headers in the same directory. How do I
handle this with target_include_directories()? Preferably I would like
to avoid reorganizing the file structure.


If things are in the same directory you don't need 
target_include_directories(), as the header files will be found anyway 
if you use "" (probably also <>). If they are in a different directory 
it doesn't matter if the private and public things are mixed, you need 
to add that directory anyway.


Greetings,

Eike
--
--

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] Coverage support

[Rolf Eike Beer]

Am 2017-08-07 11:06, schrieb Clément Gregoire:

I usually stop reading Cmakelists.txt as soon as I see this

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
-fprofile-arcs -ftest-coverage")


The pthread thing there is likely wrong anyway, and the -Wall is 
entirely optional. The other things are needed, otherwise gcov will not 
produce any useful output.


Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single 
test

target, which seems to be a difficult to scale on big projects


No, you don't. It's entirely fine if you just run "make test" as I do in 
OSM2go.


Eike
--

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] Advice on converting legacy project to modern CMake

[Björn Blissing]

Hi,

I have some legacy projects which I intend to update to modern CMake. The 
documentation is good but do not really cover "best practices". So I have some 
questions which I hope some of you could help to answer:

1. Which version if CMake should I target? I.e. Which version should I require 
in my cmake_minimum_required() statement?

2. What are some best practices when choosing a namespace for my library 
export? For example, lets say that I have a library which handles interfacing 
with a piece of fictional hardware, lets call this hardware "Anvil". My library 
and project is then aptly named "Anvil". But what to name the namespace?

3. Some of my legacy projects have all source in the same directory, i.e. both 
source and header files are in the same directory. Others have both private and 
public headers in the same directory. How do I handle this with 
target_include_directories()? Preferably I would like to avoid reorganizing the 
file structure.

Regards

Björn

-- 

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] Coverage support

[Clément Gregoire]

I usually stop reading Cmakelists.txt as soon as I see this

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -pedantic -pthread -g -O0
-fprofile-arcs -ftest-coverage")

Also you need to use the SETUP_TARGET_FOR_COVERAGE for every single test
target, which seems to be a difficult to scale on big projects

Le lun. 7 août 2017 à 12:50, Rolf Eike Beer  a écrit :

> Am 2017-08-07 09:57, schrieb Clément Gregoire:
> > Hi,
> > I'm a bit stuck when trying to add coverage reports to Cmake (gcov +
> > lcov)
> > as I can't figure out what is the best (idiomatic) way to do it.
> > So far here are the ways I know of :
> > - setting the CMAKE_LANG_FLAGS based on a boolean + scan all files /
> > run
> > gcov on it : would like to avoid this
> > - same but adding a new build type : seems to be way better but running
> > gcov would still be a pain
> > - same with a tool chain file for the flags : doesn't sound a good idea
> > since coverage should only be ran in debug
> > - some library to link with that propagates the flags : not possible
> > because link flags are not transient
> > - macro that adds the flags / does magic on a per target basis : many
> > scripts do this but seems to be a pain to maintain. Also I would rather
> > have all my test targets be set up automatically
> > - any of the above for flags and Ctest ctest_coverage but all I need
> > are
> > the gcov/lcov reports, not the coverage.xml for the dashboard
> > - using the command parameter of add_test
> > - something I missed?
> >
> > I want the setup to be easy and compatible with codecov.io, sadly all
> > the
> > script I found are bad, undocumented, or old and using bad practices.
>
> What's wrong with this one:
> https://github.com/codecov/example-cpp11-cmake ?
>
> I use it for both Codecov.io and CDash at the same time, see
> https://github.com/osm2go/osm2go/blob/master/.travis.yml
>
> Eike
> --
>
> 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] Coverage support

[Rolf Eike Beer]

Am 2017-08-07 09:57, schrieb Clément Gregoire:

Hi,
I'm a bit stuck when trying to add coverage reports to Cmake (gcov + 
lcov)

as I can't figure out what is the best (idiomatic) way to do it.
So far here are the ways I know of :
- setting the CMAKE_LANG_FLAGS based on a boolean + scan all files / 
run

gcov on it : would like to avoid this
- same but adding a new build type : seems to be way better but running
gcov would still be a pain
- same with a tool chain file for the flags : doesn't sound a good idea
since coverage should only be ran in debug
- some library to link with that propagates the flags : not possible
because link flags are not transient
- macro that adds the flags / does magic on a per target basis : many
scripts do this but seems to be a pain to maintain. Also I would rather
have all my test targets be set up automatically
- any of the above for flags and Ctest ctest_coverage but all I need 
are

the gcov/lcov reports, not the coverage.xml for the dashboard
- using the command parameter of add_test
- something I missed?

I want the setup to be easy and compatible with codecov.io, sadly all 
the

script I found are bad, undocumented, or old and using bad practices.


What's wrong with this one: 
https://github.com/codecov/example-cpp11-cmake ?


I use it for both Codecov.io and CDash at the same time, see 
https://github.com/osm2go/osm2go/blob/master/.travis.yml


Eike
--

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] Coverage support

[Clément Gregoire]

Hi,
I'm a bit stuck when trying to add coverage reports to Cmake (gcov + lcov)
as I can't figure out what is the best (idiomatic) way to do it.
So far here are the ways I know of :
- setting the CMAKE_LANG_FLAGS based on a boolean + scan all files / run
gcov on it : would like to avoid this
- same but adding a new build type : seems to be way better but running
gcov would still be a pain
- same with a tool chain file for the flags : doesn't sound a good idea
since coverage should only be ran in debug
- some library to link with that propagates the flags : not possible
because link flags are not transient
- macro that adds the flags / does magic on a per target basis : many
scripts do this but seems to be a pain to maintain. Also I would rather
have all my test targets be set up automatically
- any of the above for flags and Ctest ctest_coverage but all I need are
the gcov/lcov reports, not the coverage.xml for the dashboard
- using the command parameter of add_test
- something I missed?

I want the setup to be easy and compatible with codecov.io, sadly all the
script I found are bad, undocumented, or old and using bad practices.

Any help is welcome!

Thanks
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] C++ IDE

[Jean-Michaël Celerier]

QtCreator is nice.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sun, Aug 6, 2017 at 10:57 PM, Rolf Eike Beer  wrote:

> Am Sonntag, 6. August 2017, 17:52:13 schrieb Ivam Pretti:
> > Can you recomend an IDE to code in C/C++?
>
> KDevelop.
> --
>
> 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-developers
>
-- 

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

[CMake] Yet another CMake 3.9 CUDA issue

[Mueller-Roemer, Johannes Sebastian]

Hi,

after solving a different issue (lack of .NET 3.5 Framework causing the CUDA 
MSBuild component to not work, discussion thread "Visual Studio with CUDA does 
not work in 3.9") and getting good results (parallel CUDA builds, yay!), I now 
wanted to try CMake 3.9 on a different machine, but no success :(

The machine is running Windows Server 2012 R2 with Visual Studio 2015 (2012 is 
installed as well). The CUDA SDK is installed in versions 7.5 and 8.0. .Net 3.5 
is installed as well. However, the following error is reported:

CMake Error at 
E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCompilerId.cmake:247 
(message):
  No CUDA toolset found.
Call Stack (most recent call first):
  E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCompilerId.cmake:31 
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  
E:/BuildTools/cmake/share/cmake-3.9/Modules/CMakeDetermineCUDACompiler.cmake:73 
(CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "C:/Users/buildbot/Desktop/test/build/CMakeFiles/CMakeOutput.log".

The CMakeOutput.log is also not very informative and only contains:
The system is: Windows - 6.3.9600 - AMD64

Regards
Johannes Mueller-Roemer
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