From franck.houssen at inria.fr  Thu Feb  1 04:46:04 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Thu, 1 Feb 2018 10:46:04 +0100 (CET)
Subject: [CMake] How to get RPATH option (-Wl, -rpath,
 /path/to/local/lib) ?
In-Reply-To: <611765536.25823387.1517391591763.JavaMail.zimbra@inria.fr>
References: <611765536.25823387.1517391591763.JavaMail.zimbra@inria.fr>
Message-ID: <1000898038.174101.1517478364200.JavaMail.zimbra@inria.fr>

OK, so I believe I just need to write "-Wl,rpath" in my templates of pc/cmake files !... 

Franck 

----- Mail original -----

> De: "Franck Houssen" <franck.houssen at inria.fr>
> ?: "CMake Mail List" <cmake at cmake.org>
> Envoy?: Mercredi 31 Janvier 2018 10:39:51
> Objet: [CMake] How to get RPATH option (-Wl,-rpath,/path/to/local/lib) ?

> How to get RPATH option (-Wl,-rpath,/path/to/local/lib) ?

> I would like to create a *.pc/cmake file for users to find a library I
> provide. As there is possibly a LOT of dependencies (libraries) I may not
> even be able to list, the most simple way to do that is to use RPATH. I know
> that for gcc, RPATH is set with "-Wl,-rpath". But what about others
> compilers (pgi, icc) ? This option could not be the same.

> Is it possible to "grab" the correct RPATH option (-Wl,-rpath) according to
> the compiler ? Something like a CMAKE_RPATH_OPTIONS to substitute in a
> *.pc/cmake.in template file ? (to create a *.pc/cmake file in the install
> directory using configure_file)

> Franck

> --

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180201/beb2cd88/attachment-0001.html>

From calebwherry at gmail.com  Thu Feb  1 13:29:42 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Thu, 1 Feb 2018 13:29:42 -0500
Subject: [CMake] How to add files to Visual Studio 'Utility' project
Message-ID: <CAJxY6Xog0vmOV4YenP24rUsz3Df8o6XiFhtfQsVK9paPr07ieQ@mail.gmail.com>

Hello!

I am having trouble with a generated VS project that I hope is either a bug
or has an easy fix...

When using UseJava, the add_jar function, and Visual Studio 2015, a VS
'Utility' project is created. I then want to add additional non-compiled
files to this project so I try to use target_sources but get his error:

"target_sources called with non-compilable target type"

In VS, I can easily add files to the project without issue. But I cannot
seem to add any additional files to this created 'Utility' project through
CMake.

I do this in other projects by using target_sources and setting the
HEADER_FILE_ONLY and WRAP_EXCLUDE properties to make sure the project
doesn't do anything with them and it works fine. Just can't do it for these
Utility projects.

My use case here is that the add_jar command doesn't actually add the java
source files to the project. I want to use VS as a code editor in this case
because it builds the jar. However, without them in the project, I have to
go outside of VS to edit them (and thus outside of my VS perforce control).

Thoughts? Maybe I am adding them incorrectly?

-Caleb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180201/b10a463b/attachment.html>

From mellery451 at gmail.com  Thu Feb  1 13:49:34 2018
From: mellery451 at gmail.com (Michael Ellery)
Date: Thu, 1 Feb 2018 10:49:34 -0800
Subject: [CMake] CMake + mdvc + --build + jenkins
Message-ID: <D0D354CA-7510-4ABB-AB38-3C1DB4FC43B0@gmail.com>

I know this is a long-shot, but I?m wondering if anyone has encountered this scenario:

CMake (3.10) being used to generate a project for Visual Studio 15 (the current latest)

the build is running on a windows machine under a jenkins slave process

The generation step runs fine

I then run cmake in build mode, and the build basically completes (based on the fact that I see the executable produced).  BUT the child MSBuild processes never exit and thus the build is stuck (cmake is still waiting?)

I?ve tried running the jenkins slave process in a console window (foreground) just to eliminate any service/service account issues, but it makes no difference.

More important, if I instead invoke MSBuild directly rather than use ?cmake ?build . ???, the process behaves fine and runs to completion.

This experiment makes me think something is odd about how cmake spawns the MSBuild process - perhaps some child event or signal is not being handled?

In any event, I?m not blocked by this since I can simply run MSBUILD directly in the build script, but I wondered if this is a known issue or if others have encountered it.

Also, I?ll note that I?m passing /nr:false to msbuild in both cases because that is common recommendation for running msbuild under CI.

-Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://cmake.org/pipermail/cmake/attachments/20180201/931df46a/attachment.sig>

From calebwherry at gmail.com  Thu Feb  1 14:38:10 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Thu, 1 Feb 2018 14:38:10 -0500
Subject: [CMake] CMake + mdvc + --build + jenkins
In-Reply-To: <D0D354CA-7510-4ABB-AB38-3C1DB4FC43B0@gmail.com>
References: <D0D354CA-7510-4ABB-AB38-3C1DB4FC43B0@gmail.com>
Message-ID: <CAJxY6XqYiH-+DPGe-mvxDaNgkbUetJrK0w9FjsZVb1nvV1R=Vg@mail.gmail.com>

(forgot to reply all)

I have a pretty similar setup but do not use the cmake --build since I
selectively build projects based the jenkins build type (CI, nightly,
research ,etc).

I'll see if I can kick off a test and use the --build option, I've thought
about doing that in the past but never tested. Will let you know if I see a
similar issue as you are seeing.

FWIW, I also set /nr:false so our setups are pretty close. I also build
Java and .NET wrappers in the same solution and sometimes have issues with
the .NET processes not ending when a build is done. I haven't investigated
those thoroughly though. So it is very possible something is screwed up
somewhere on either side.

-Caleb


On Thu, Feb 1, 2018 at 1:49 PM, Michael Ellery <mellery451 at gmail.com> wrote:

> I know this is a long-shot, but I?m wondering if anyone has encountered
> this scenario:
>
> CMake (3.10) being used to generate a project for Visual Studio 15 (the
> current latest)
>
> the build is running on a windows machine under a jenkins slave process
>
> The generation step runs fine
>
> I then run cmake in build mode, and the build basically completes (based
> on the fact that I see the executable produced).  BUT the child MSBuild
> processes never exit and thus the build is stuck (cmake is still waiting?)
>
> I?ve tried running the jenkins slave process in a console window
> (foreground) just to eliminate any service/service account issues, but it
> makes no difference.
>
> More important, if I instead invoke MSBuild directly rather than use
> ?cmake ?build . ???, the process behaves fine and runs to completion.
>
> This experiment makes me think something is odd about how cmake spawns the
> MSBuild process - perhaps some child event or signal is not being handled?
>
> In any event, I?m not blocked by this since I can simply run MSBUILD
> directly in the build script, but I wondered if this is a known issue or if
> others have encountered it.
>
> Also, I?ll note that I?m passing /nr:false to msbuild in both cases
> because that is common recommendation for running msbuild under CI.
>
> -Mike
>
>
> --
>
> 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
>
>


-- 
J. Caleb Wherry
*Scientific Software Engineer*

<http://www.calebwherry.com>
http://www.calebwherry.com
+1 (615) 708-5651
calebwherry at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180201/a3f279c9/attachment.html>

From dave.demarle at kitware.com  Thu Feb  1 15:16:26 2018
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 1 Feb 2018 15:16:26 -0500
Subject: [CMake] announce: free VTK,
 ParaView and CMake training at Kitware New York next month
Message-ID: <CANjZAi-SCAiSTySZTjU-e1Q5JOma+7RaN3Eo=H5vQaUsHVXFcA@mail.gmail.com>

Hi folks,

Kitware is going to present three free, one day training courses next month
at our Albany NY headquarters. The outline for each day follows.

March 13'th "Introductory and applied VTK"

morning:

Dave DeMarle / Lisa Avila - "A hands on introduction to VTK"

afternoon:

Aashish Chaudhary - "VTK and Geosciences"

Berk Geveci - "Flow Visualization"

Ken Martin - "Realistic Rendering"

Sankesh Jhaveri - ?A workflow for Medical Visualization?

March 14'th "Introductory and applied ParaView"

morning:

Dan Lipsa / Utkarsh Ayachit - "A hands on introduction to ParaView"

afternoon:

Andy Bauer - "CFD analysis"

T.J. Corona - "Simulation Debugging"

Utkarsh Ayachit - "Quantitative Analysis"

Bob O'Bara - "Point Cloud Processing"

March 15'th "CMake and Friends"
all day: w/ Bill Hoffman

To reserve a seat for the course, please fill out this google form and
we'll get back to you to confirm your reservation.

https://goo.gl/forms/M3WmJcV9W6qKTK8x2

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180201/305227e8/attachment-0001.html>

From cyril.boucher94260 at gmail.com  Thu Feb  1 15:57:16 2018
From: cyril.boucher94260 at gmail.com (Cyril Boucher)
Date: Thu, 1 Feb 2018 21:57:16 +0100
Subject: [CMake] Adding a reference to Windows Media Player library using
 CMake + CSharp support
Message-ID: <CALYSiH4t=c9+wXe-3wfP4HZUCXt+ARBg4r30dcpcpqzxGdaZOQ@mail.gmail.com>

Hi all,

I am trying to use CMake and the CSharp support for a small project of mine
but I cannot seem to find a way to add a reference to the Windows Media
Player library. One of the reason for that is that I need to link my
project to wmp.dll which then needs to generate Interop.WMPLib.dll and a
reference needs to be added with its path pointing to the latter library.

Adding wmp.dll to my project is as simple as a target_link_libraries call
but this does not seem to trigger the whole generation and add reference
sort of process.

Has anyone ever had an experience with adding such libraries? Is there
support for these scenarios?

Thanks!
Cyril Boucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180201/31d105fd/attachment.html>

From irwin at beluga.phys.uvic.ca  Thu Feb  1 15:49:59 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 1 Feb 2018 12:49:59 -0800 (PST)
Subject: [CMake] announce: free VTK,
 ParaView and CMake training at Kitware New York next month
In-Reply-To: <CANjZAi-SCAiSTySZTjU-e1Q5JOma+7RaN3Eo=H5vQaUsHVXFcA@mail.gmail.com>
References: <CANjZAi-SCAiSTySZTjU-e1Q5JOma+7RaN3Eo=H5vQaUsHVXFcA@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1802011240570.1805@enira.zlyna.ubzr>

On 2018-02-01 15:16-0500 David E DeMarle wrote:

> Kitware is going to present three free, one day training courses next month
> at our Albany NY headquarters. The outline for each day follows.

For those of who would prefer not to make such a long trip but who are
extremely interested in those training courses, would you be willing
to record a video of those training sessions and make that video
freely accessible on the web?

I (and presumably many others here since this is the CMake mailing
list after all) would be particularly interested in watching the last-day session

> March 15'th "CMake and Friends"
> all day: w/ Bill Hoffman

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
__________________________

From kris.f.thielemans at gmail.com  Fri Feb  2 02:06:12 2018
From: kris.f.thielemans at gmail.com (Kris Thielemans)
Date: Fri, 2 Feb 2018 07:06:12 -0000
Subject: [CMake] How to get RPATH option (-Wl, -rpath,
 /path/to/local/lib) ?
In-Reply-To: <1000898038.174101.1517478364200.JavaMail.zimbra@inria.fr>
References: <611765536.25823387.1517391591763.JavaMail.zimbra@inria.fr>
 <1000898038.174101.1517478364200.JavaMail.zimbra@inria.fr>
Message-ID: <011a01d39bf4$4fa81f60$eef85e20$@gmail.com>

Hi

There a wiki page covering this

https://cmake.org/Wiki/CMake_RPATH_handling

 

I find it a bit confusing (and the example code for the ?full RPATH? option
seems to set CMAKE_INSTALL_RPATH twice), but it should help. 

 

It might be outdated for OSX as El Capitan introduced extra security
requirements such that the recommendations on the wiki no longer seem to
work. You can see some of our struggles with this here

https://github.com/CCPPETMR/SIRF/pull/79

We seem to have found a solution using CMAKE_INSTALL_NAME_DIR but any other
help with that appreciated.

 

Kris

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Franck Houssen
Sent: 01 February 2018 09:46
To: CMake Mail List <cmake at cmake.org>
Subject: Re: [CMake] How to get RPATH option (-Wl, -rpath,
/path/to/local/lib) ?

 

OK, so I believe I just need to write "-Wl,rpath" in my templates of
pc/cmake files !...

 

Franck

 

 

  _____  

De: "Franck Houssen" <franck.houssen at inria.fr
<mailto:franck.houssen at inria.fr> >
?: "CMake Mail List" <cmake at cmake.org <mailto:cmake at cmake.org> >
Envoy?: Mercredi 31 Janvier 2018 10:39:51
Objet: [CMake] How to get RPATH option (-Wl,-rpath,/path/to/local/lib) ?

 

How to get RPATH option (-Wl,-rpath,/path/to/local/lib) ?

 

I would like to create a *.pc/cmake file for users to find a library I
provide. As there is possibly a LOT of dependencies (libraries) I may not
even be able to list, the most simple way to do that is to use RPATH. I know
that for gcc, RPATH is set with "-Wl,-rpath". But what about others
compilers (pgi, icc) ? This option could not be the same.

 

Is it possible to "grab" the correct RPATH option (-Wl,-rpath) according to
the compiler ? Something like a CMAKE_RPATH_OPTIONS to substitute in a
*.pc/cmake.in template file ? (to create a *.pc/cmake file in the install
directory using configure_file)

 

Franck


-- 

 

Powered by www.kitware.com <http://www.kitware.com> 

 

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

 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180202/5b601676/attachment.html>

From marc.chevrier at sap.com  Fri Feb  2 03:35:49 2018
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Fri, 2 Feb 2018 08:35:49 +0000
Subject: [CMake] How to add files to Visual Studio 'Utility' project
In-Reply-To: <CAJxY6Xog0vmOV4YenP24rUsz3Df8o6XiFhtfQsVK9paPr07ieQ@mail.gmail.com>
References: <CAJxY6Xog0vmOV4YenP24rUsz3Df8o6XiFhtfQsVK9paPr07ieQ@mail.gmail.com>
Message-ID: <FCC5E577-B0CB-4A33-9A04-CAE6C32747D1@sap.com>

This approach is not possible for Java because the command add_jar is implemented using commands add_custom_command and add_custom_target. And command target_sources implies that the target was created by one the commands add_library or add_executable.


From: CMake <cmake-bounces at cmake.org> on behalf of "J. Caleb Wherry" <calebwherry at gmail.com>
Date: Thursday 1 February 2018 at 19:30
To: CMake ML <cmake at cmake.org>
Subject: [CMake] How to add files to Visual Studio 'Utility' project

Hello!

I am having trouble with a generated VS project that I hope is either a bug or has an easy fix...

When using UseJava, the add_jar function, and Visual Studio 2015, a VS 'Utility' project is created. I then want to add additional non-compiled files to this project so I try to use target_sources but get his error:

"target_sources called with non-compilable target type"

In VS, I can easily add files to the project without issue. But I cannot seem to add any additional files to this created 'Utility' project through CMake.

I do this in other projects by using target_sources and setting the HEADER_FILE_ONLY and WRAP_EXCLUDE properties to make sure the project doesn't do anything with them and it works fine. Just can't do it for these Utility projects.

My use case here is that the add_jar command doesn't actually add the java source files to the project. I want to use VS as a code editor in this case because it builds the jar. However, without them in the project, I have to go outside of VS to edit them (and thus outside of my VS perforce control).

Thoughts? Maybe I am adding them incorrectly?

-Caleb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180202/745e7774/attachment-0001.html>

From franck.houssen at inria.fr  Fri Feb  2 05:40:50 2018
From: franck.houssen at inria.fr (Franck Houssen)
Date: Fri, 2 Feb 2018 11:40:50 +0100 (CET)
Subject: [CMake] How to get RPATH option (-Wl, -rpath,
 /path/to/local/lib) ?
In-Reply-To: <011a01d39bf4$4fa81f60$eef85e20$@gmail.com>
References: <611765536.25823387.1517391591763.JavaMail.zimbra@inria.fr>
 <1000898038.174101.1517478364200.JavaMail.zimbra@inria.fr>
 <011a01d39bf4$4fa81f60$eef85e20$@gmail.com>
Message-ID: <30568321.910531.1517568050000.JavaMail.zimbra@inria.fr>

The wiki do not cover how to handle rpath when you need to provide a mylib.pc or mylib.cmake file in the install directory of your library: this is why I asked ! 

If you need to provide a pc file like this: 
>> more mylib.pc 
prefix=${CMAKE_INSTALL_PREFIX} 
exec_prefix=${prefix} 
includedir=${prefix}/include 
libdir=${exec_prefix}/lib 
Cflags: -I${includedir} 
Libs: -L${libdir} -lmylib 

The question is : how do you do when you need RPATH in the pc file ? 

Do you hard-code (this may not be portable) the rpath option : 
>> more mylib.pc 
prefix=${CMAKE_INSTALL_PREFIX} 
exec_prefix=${prefix} 
includedir=${prefix}/include 
libdir=${exec_prefix}/lib 
Cflags: -I${includedir} 
Libs: -Wl,-rpath, -L${libdir} -lmylib 

Or is there a specific variable to handle this ? Like for instance something like this 

>> more mylib.pc 
prefix=${CMAKE_INSTALL_PREFIX} 
exec_prefix=${prefix} 
includedir=${prefix}/include 
libdir=${exec_prefix}/lib 
Cflags: -I${includedir} 
Libs: ${CMAKE_RPATH_LINKER_OPTION}, -L${libdir} -lmylib 

----- Mail original -----

> De: "Kris Thielemans" <kris.f.thielemans at gmail.com>
> ?: "Franck Houssen" <franck.houssen at inria.fr>, "CMake Mail List"
> <cmake at cmake.org>
> Envoy?: Vendredi 2 F?vrier 2018 08:06:12
> Objet: RE: [CMake] How to get RPATH option (-Wl, -rpath, /path/to/local/lib)
> ?

> Hi

> There a wiki page covering this

> https://cmake.org/Wiki/CMake_RPATH_handling

> I find it a bit confusing (and the example code for the ?full RPATH? option
> seems to set CMAKE_INSTALL_RPATH twice), but it should help.

> It might be outdated for OSX as El Capitan introduced extra security
> requirements such that the recommendations on the wiki no longer seem to
> work. You can see some of our struggles with this here

> https://github.com/CCPPETMR/SIRF/pull/79

> We seem to have found a solution using CMAKE_INSTALL_NAME_DIR but any other
> help with that appreciated.

> Kris

> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Franck Houssen
> Sent: 01 February 2018 09:46
> To: CMake Mail List <cmake at cmake.org>
> Subject: Re: [CMake] How to get RPATH option (-Wl, -rpath,
> /path/to/local/lib) ?

> OK, so I believe I just need to write "-Wl,rpath" in my templates of pc/cmake
> files !...

> Franck

> ----- Mail original -----

> > De: "Franck Houssen" < franck.houssen at inria.fr >
> 
> > ?: "CMake Mail List" < cmake at cmake.org >
> 
> > Envoy?: Mercredi 31 Janvier 2018 10:39:51
> 
> > Objet: [CMake] How to get RPATH option (-Wl,-rpath,/path/to/local/lib) ?
> 

> > How to get RPATH option (-Wl,-rpath,/path/to/local/lib) ?
> 

> > I would like to create a *.pc/cmake file for users to find a library I
> > provide. As there is possibly a LOT of dependencies (libraries) I may not
> > even be able to list, the most simple way to do that is to use RPATH. I
> > know
> > that for gcc, RPATH is set with "-Wl,-rpath". But what about others
> > compilers (pgi, icc) ? This option could not be the same.
> 

> > Is it possible to "grab" the correct RPATH option (-Wl,-rpath) according to
> > the compiler ? Something like a CMAKE_RPATH_OPTIONS to substitute in a
> > *.pc/cmake.in template file ? (to create a *.pc/cmake file in the install
> > directory using configure_file)
> 

> > Franck
> 

> > --
> 

> > 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180202/fdabf6c6/attachment.html>

From calebwherry at gmail.com  Fri Feb  2 08:57:03 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Fri, 02 Feb 2018 13:57:03 +0000
Subject: [CMake] How to add files to Visual Studio 'Utility' project
In-Reply-To: <FCC5E577-B0CB-4A33-9A04-CAE6C32747D1@sap.com>
References: <CAJxY6Xog0vmOV4YenP24rUsz3Df8o6XiFhtfQsVK9paPr07ieQ@mail.gmail.com>
 <FCC5E577-B0CB-4A33-9A04-CAE6C32747D1@sap.com>
Message-ID: <CAJxY6XrP1_6bd-B-2t6T3SrWWnS5VpK5k5+s3jr76vT3Ot8YJg@mail.gmail.com>

Yes, I understand that. The error message is pretty clear.

My main question is really why is that the case? In VS, there is no
restriction to adding files to a utility project. So why does CMake have
this restriction?

I assume it is because it is generator specific and there isn?t a clean way
to implement add_custom_target across all of them. In that case I would
expect some special case handling for generators that do support it.

And it?s not like CMake can?t add files to that Utility project, because it
does: it adds the Java rules files. It just doesn?t allow the user the do
the same. It?s a restriction that doesn?t really make sense to me.

-Caleb

On Fri, Feb 2, 2018 at 3:35 AM CHEVRIER, Marc <marc.chevrier at sap.com> wrote:

> This approach is not possible for Java because the command add_jar is
> implemented using commands add_custom_command and add_custom_target. And
> command target_sources implies that the target was created by one the
> commands add_library or add_executable.
>
>
>
>
>
> *From: *CMake <cmake-bounces at cmake.org> on behalf of "J. Caleb Wherry" <
> calebwherry at gmail.com>
> *Date: *Thursday 1 February 2018 at 19:30
> *To: *CMake ML <cmake at cmake.org>
> *Subject: *[CMake] How to add files to Visual Studio 'Utility' project
>
>
>
> Hello!
>
>
>
> I am having trouble with a generated VS project that I hope is either a
> bug or has an easy fix...
>
>
>
> When using UseJava, the add_jar function, and Visual Studio 2015, a VS
> 'Utility' project is created. I then want to add additional non-compiled
> files to this project so I try to use target_sources but get his error:
>
>
>
> "target_sources called with non-compilable target type"
>
>
>
> In VS, I can easily add files to the project without issue. But I cannot
> seem to add any additional files to this created 'Utility' project through
> CMake.
>
>
>
> I do this in other projects by using target_sources and setting the
> HEADER_FILE_ONLY and WRAP_EXCLUDE properties to make sure the project
> doesn't do anything with them and it works fine. Just can't do it for these
> Utility projects.
>
>
>
> My use case here is that the add_jar command doesn't actually add the java
> source files to the project. I want to use VS as a code editor in this case
> because it builds the jar. However, without them in the project, I have to
> go outside of VS to edit them (and thus outside of my VS perforce control).
>
>
>
> Thoughts? Maybe I am adding them incorrectly?
>
>
>
> -Caleb
>
-- 
Sent from my iPhone 4s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180202/60164f66/attachment-0001.html>

From eric.noulard at gmail.com  Fri Feb  2 09:50:38 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Fri, 2 Feb 2018 15:50:38 +0100
Subject: [CMake] How to add files to Visual Studio 'Utility' project
In-Reply-To: <CAJxY6XrP1_6bd-B-2t6T3SrWWnS5VpK5k5+s3jr76vT3Ot8YJg@mail.gmail.com>
References: <CAJxY6Xog0vmOV4YenP24rUsz3Df8o6XiFhtfQsVK9paPr07ieQ@mail.gmail.com>
 <FCC5E577-B0CB-4A33-9A04-CAE6C32747D1@sap.com>
 <CAJxY6XrP1_6bd-B-2t6T3SrWWnS5VpK5k5+s3jr76vT3Ot8YJg@mail.gmail.com>
Message-ID: <CAPASGLpyoEqeVD8LU-gQY36P9vJ=szkXr-PYwicRmfRhUZQawQ@mail.gmail.com>

There is some history on that:

https://gitlab.kitware.com/cmake/cmake/issues/7835  linked to older
https://itk.org/Bug/view.php?id=7835

May be this is a plain feature request that should be properly written
based on history and current usage.
Typically I think that anyone would want to add any file to IDE project
display.


2018-02-02 14:57 GMT+01:00 J. Caleb Wherry <calebwherry at gmail.com>:

> Yes, I understand that. The error message is pretty clear.
>
> My main question is really why is that the case? In VS, there is no
> restriction to adding files to a utility project. So why does CMake have
> this restriction?
>
> I assume it is because it is generator specific and there isn?t a clean
> way to implement add_custom_target across all of them. In that case I would
> expect some special case handling for generators that do support it.
>
> And it?s not like CMake can?t add files to that Utility project, because
> it does: it adds the Java rules files. It just doesn?t allow the user the
> do the same. It?s a restriction that doesn?t really make sense to me.
>
> -Caleb
>
> On Fri, Feb 2, 2018 at 3:35 AM CHEVRIER, Marc <marc.chevrier at sap.com>
> wrote:
>
>> This approach is not possible for Java because the command add_jar is
>> implemented using commands add_custom_command and add_custom_target. And
>> command target_sources implies that the target was created by one the
>> commands add_library or add_executable.
>>
>>
>>
>>
>>
>> *From: *CMake <cmake-bounces at cmake.org> on behalf of "J. Caleb Wherry" <
>> calebwherry at gmail.com>
>> *Date: *Thursday 1 February 2018 at 19:30
>> *To: *CMake ML <cmake at cmake.org>
>> *Subject: *[CMake] How to add files to Visual Studio 'Utility' project
>>
>>
>>
>> Hello!
>>
>>
>>
>> I am having trouble with a generated VS project that I hope is either a
>> bug or has an easy fix...
>>
>>
>>
>> When using UseJava, the add_jar function, and Visual Studio 2015, a VS
>> 'Utility' project is created. I then want to add additional non-compiled
>> files to this project so I try to use target_sources but get his error:
>>
>>
>>
>> "target_sources called with non-compilable target type"
>>
>>
>>
>> In VS, I can easily add files to the project without issue. But I cannot
>> seem to add any additional files to this created 'Utility' project through
>> CMake.
>>
>>
>>
>> I do this in other projects by using target_sources and setting the
>> HEADER_FILE_ONLY and WRAP_EXCLUDE properties to make sure the project
>> doesn't do anything with them and it works fine. Just can't do it for these
>> Utility projects.
>>
>>
>>
>> My use case here is that the add_jar command doesn't actually add the
>> java source files to the project. I want to use VS as a code editor in this
>> case because it builds the jar. However, without them in the project, I
>> have to go outside of VS to edit them (and thus outside of my VS perforce
>> control).
>>
>>
>>
>> Thoughts? Maybe I am adding them incorrectly?
>>
>>
>>
>> -Caleb
>>
> --
> Sent from my iPhone 4s
>
> --
>
> 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
>
>


-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180202/8cf91e54/attachment.html>

From calebwherry at gmail.com  Fri Feb  2 12:03:35 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Fri, 2 Feb 2018 12:03:35 -0500
Subject: [CMake] How to add files to Visual Studio 'Utility' project
In-Reply-To: <CAPASGLpyoEqeVD8LU-gQY36P9vJ=szkXr-PYwicRmfRhUZQawQ@mail.gmail.com>
References: <CAJxY6Xog0vmOV4YenP24rUsz3Df8o6XiFhtfQsVK9paPr07ieQ@mail.gmail.com>
 <FCC5E577-B0CB-4A33-9A04-CAE6C32747D1@sap.com>
 <CAJxY6XrP1_6bd-B-2t6T3SrWWnS5VpK5k5+s3jr76vT3Ot8YJg@mail.gmail.com>
 <CAPASGLpyoEqeVD8LU-gQY36P9vJ=szkXr-PYwicRmfRhUZQawQ@mail.gmail.com>
Message-ID: <CAJxY6Xo5Hpgpyexhbheh_VbngWqhV56aJOvm-K-MDFGQ1+qHeQ@mail.gmail.com>

Agreed. If I don't here anything else about this, I'll write up a feature
request.

On Fri, Feb 2, 2018 at 9:50 AM, Eric Noulard <eric.noulard at gmail.com> wrote:

> There is some history on that:
>
> https://gitlab.kitware.com/cmake/cmake/issues/7835  linked to older
> https://itk.org/Bug/view.php?id=7835
>
> May be this is a plain feature request that should be properly written
> based on history and current usage.
> Typically I think that anyone would want to add any file to IDE project
> display.
>
>
> 2018-02-02 14:57 GMT+01:00 J. Caleb Wherry <calebwherry at gmail.com>:
>
>> Yes, I understand that. The error message is pretty clear.
>>
>> My main question is really why is that the case? In VS, there is no
>> restriction to adding files to a utility project. So why does CMake have
>> this restriction?
>>
>> I assume it is because it is generator specific and there isn?t a clean
>> way to implement add_custom_target across all of them. In that case I would
>> expect some special case handling for generators that do support it.
>>
>> And it?s not like CMake can?t add files to that Utility project, because
>> it does: it adds the Java rules files. It just doesn?t allow the user the
>> do the same. It?s a restriction that doesn?t really make sense to me.
>>
>> -Caleb
>>
>> On Fri, Feb 2, 2018 at 3:35 AM CHEVRIER, Marc <marc.chevrier at sap.com>
>> wrote:
>>
>>> This approach is not possible for Java because the command add_jar is
>>> implemented using commands add_custom_command and add_custom_target. And
>>> command target_sources implies that the target was created by one the
>>> commands add_library or add_executable.
>>>
>>>
>>>
>>>
>>>
>>> *From: *CMake <cmake-bounces at cmake.org> on behalf of "J. Caleb Wherry" <
>>> calebwherry at gmail.com>
>>> *Date: *Thursday 1 February 2018 at 19:30
>>> *To: *CMake ML <cmake at cmake.org>
>>> *Subject: *[CMake] How to add files to Visual Studio 'Utility' project
>>>
>>>
>>>
>>> Hello!
>>>
>>>
>>>
>>> I am having trouble with a generated VS project that I hope is either a
>>> bug or has an easy fix...
>>>
>>>
>>>
>>> When using UseJava, the add_jar function, and Visual Studio 2015, a VS
>>> 'Utility' project is created. I then want to add additional non-compiled
>>> files to this project so I try to use target_sources but get his error:
>>>
>>>
>>>
>>> "target_sources called with non-compilable target type"
>>>
>>>
>>>
>>> In VS, I can easily add files to the project without issue. But I cannot
>>> seem to add any additional files to this created 'Utility' project through
>>> CMake.
>>>
>>>
>>>
>>> I do this in other projects by using target_sources and setting the
>>> HEADER_FILE_ONLY and WRAP_EXCLUDE properties to make sure the project
>>> doesn't do anything with them and it works fine. Just can't do it for these
>>> Utility projects.
>>>
>>>
>>>
>>> My use case here is that the add_jar command doesn't actually add the
>>> java source files to the project. I want to use VS as a code editor in this
>>> case because it builds the jar. However, without them in the project, I
>>> have to go outside of VS to edit them (and thus outside of my VS perforce
>>> control).
>>>
>>>
>>>
>>> Thoughts? Maybe I am adding them incorrectly?
>>>
>>>
>>>
>>> -Caleb
>>>
>> --
>> Sent from my iPhone 4s
>>
>> --
>>
>> 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
>>
>>
>
>
> --
> Eric
>



-- 
J. Caleb Wherry
*Scientific Software Engineer*

<http://www.calebwherry.com>
http://www.calebwherry.com
+1 (615) 708-5651
calebwherry at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180202/2a5b5c5b/attachment.html>

From jbarrett at pivotal.io  Fri Feb  2 16:59:17 2018
From: jbarrett at pivotal.io (Jacob Barrett)
Date: Fri, 02 Feb 2018 21:59:17 +0000
Subject: [CMake] Referencing nuget packages in csharp csproj files
In-Reply-To: <7511d7a9b7374f1483cd873ee0c3915f@EXMBX22.SFP-Net.skyfillers.local>
References: <7511d7a9b7374f1483cd873ee0c3915f@EXMBX22.SFP-Net.skyfillers.local>
Message-ID: <CAA1wVxpFjMGmFzSUh_HmB6VNE5udGa=Nrb8S54LjYYGbZvyTYg@mail.gmail.com>

Joern,

We too have been trying to find better integration between CMake and NuGet.
What we have done is taken advantage of the packages.config file and the
nuget.exe command line too. We have a custom target that executes `nuget
restore` against the generated solution file. This by default places all
the nuget packages in a packages directory under the build directory. It
also updates all the references in the generate csproj files to the point
to the packages directory. It works pretty good and does a great job of
download dependencies when taking the sources to a new machine.

It would be nice though to have a way to specify the dependencies in the
CMake file and have it fetch and explode them like nuget does and generate
the correct csproj upfront.

Here is some snippets from our CMakeLists.txt:

find_program(NUGET nuget)
add_custom_target(nuget-restore
  COMMAND ${NUGET} restore ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.sln
)

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/packages.config
${CMAKE_CURRENT_BINARY_DIR}/packages.config COPYONLY)

set_target_properties( ${PROJECT_NAME} PROPERTIES
  VS_GLOBAL_ROOTNAMESPACE ${PROJECT_NAME}
  VS_GLOBAL_ProjectGuid "{f84e584d-a422-3021-a20c-cec777413cae}"
  VS_DOTNET_TARGET_FRAMEWORK_VERSION "v4.5.2"
  VS_DOTNET_REFERENCES
"System;System.Xml;System.Web;System.Configuration;System.Xml.Linq"
)

add_dependencies(${PROJECT_NAME} nuget-restore)

-Jake


On Tue, Jan 30, 2018 at 2:02 AM Joern Hauser <joern.hauser at sevencs.com>
wrote:

> Hello,
>
>
>
> we?re looking into generating our C# projects using CMAKE. We can generate
> working solution files, but we?re still struggling with dependencies. We
> would like to manage nuget packages via the nuget.exe command line tool.
> With the install or restore parameter this deems us a good approach for
> managing dependencies. However, CMAKE currently only supports the Reference
> tag in the csproj file. Without an additional HintPath subtag into the
> package?s folder the reference is not resolved. This HintPath points down
> the whole path to the DLL of the package, including version etc. So far I
> have not found a way how to extract this path from nuget.exe and I would
> not like having to guess it to fill the HintPath tag.
>
>
>
> Any ideas how to solve this issue?
>
>
>
> We found that using the new PackageReference tag (new since VS2017) would
> work fine without a HintPath and would offer complete configuration of
> dependencies via nuget.
>
>
>
> So we wondered if CMAKE could support this new PackageReference tag, too,
> like it does for the Reference tag by means of the VS_DOTNET_REFERENCES?
> Or is there any way how we could inject the XML into the generated csproj
> file ourselves from the project?s CMakeLists.txt? Looking into the CMAKE
> source code, I think supporting the PackageReference tag would basically
> require going along the lines of the VS_DOTNET_REFERENCES property
> handling. However, I don?t know if another property like this (e.g.
> VS_DOTNET_PACKAGEREFERENCES) would be appreciated by the CMAKE team or
> whether there are better solutions? If such a property were acceptable
> maybe we could even try to offer a patch for CMAKE.
>
>
>
> Thank you!
>
>
>
> Cheers,
>
> J?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:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180202/07a5d0e3/attachment-0001.html>

From david.vowles at adelaide.edu.au  Mon Feb  5 00:41:01 2018
From: david.vowles at adelaide.edu.au (David Vowles)
Date: Mon, 5 Feb 2018 05:41:01 +0000
Subject: [CMake] Support for fortran interoperability with C within CMake
Message-ID: <SY2PR01MB27964D5F81A0CEFF178FED6EDBFE0@SY2PR01MB2796.ausprd01.prod.outlook.com>

Hello,

As you may be aware recent Fortran standards have introduced the notion of standardised interoperability of Fortran with C. To enable practical implementation of standardised interoperability the Fortran standard has the notion of the Fortran compiler having a "companion C processor" - read compatible C compiler. Each Fortran implementation is free to choose which C is its companion or companions. The question therefore arises as to whether CMake is yet smart enough to correctly choose compatible combinations of C and Fortran compilers.

An example might be as follows.

A system has C compilers C1, C2 and C3 and Fortran compilers F1 and F2 installed. Compiler C1 is not interoperable with F1 or F2, C2 is interoperable with F1 but not F2 and C3 is interoperable with both F1 and F2. It would be highly desirable for CMake to:

(i)                Inform the user (e.g. by a fatal error) that if they choose C1 as their C compiler then there is no compatible Fortran compiler available on their system;

(ii)              If the user does not specify either a C or Fortran compiler that a compatible pair be chosen by CMake. In the example given it might be preferable (all other things being equal) for C3 to be chosen as the C compiler since it maximizes the number of Fortran compilers with which the software can be built.

Does CMake current offer any support in this area? Are there any plans to implement / extend such support?

Many thanks,
David.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180205/d66476ea/attachment.html>

From dave.demarle at kitware.com  Mon Feb  5 11:41:21 2018
From: dave.demarle at kitware.com (David E DeMarle)
Date: Mon, 5 Feb 2018 11:41:21 -0500
Subject: [CMake] announce: free VTK,
 ParaView and CMake training at Kitware New York next month
In-Reply-To: <alpine.DEB.2.11.1802011240570.1805@enira.zlyna.ubzr>
References: <CANjZAi-SCAiSTySZTjU-e1Q5JOma+7RaN3Eo=H5vQaUsHVXFcA@mail.gmail.com>
 <alpine.DEB.2.11.1802011240570.1805@enira.zlyna.ubzr>
Message-ID: <CANjZAi_16RMmTHANoEZd8kObnzFS7mp1i8-nT6YSL4MiMin6Ag@mail.gmail.com>

Hi Alan,

Unfortunately no, not for this run through. For this first run through of
the new material we want it to be local only. This way we can keep it
highly interactive (it is harder to assist everyone well in an online
group).

The VTK and ParaView slides at least will be posted online, I'm not
entirely certain yet, but I think the CMake slides will be too.
In the next run through we will very likely open it up and at least post
videos after the fact.

thanks


David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Feb 1, 2018 at 3:49 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
wrote:

> On 2018-02-01 15:16-0500 David E DeMarle wrote:
>
> Kitware is going to present three free, one day training courses next month
>> at our Albany NY headquarters. The outline for each day follows.
>>
>
> For those of who would prefer not to make such a long trip but who are
> extremely interested in those training courses, would you be willing
> to record a video of those training sessions and make that video
> freely accessible on the web?
>
> I (and presumably many others here since this is the CMake mailing
> list after all) would be particularly interested in watching the last-day
> session
>
> March 15'th "CMake and Friends"
>> all day: w/ Bill Hoffman
>>
>
> 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
> __________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180205/71b83763/attachment.html>

From bill.lorensen at gmail.com  Mon Feb  5 12:00:21 2018
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Mon, 5 Feb 2018 09:00:21 -0800
Subject: [CMake] announce: free VTK,
 ParaView and CMake training at Kitware New York next month
In-Reply-To: <CANjZAi_16RMmTHANoEZd8kObnzFS7mp1i8-nT6YSL4MiMin6Ag@mail.gmail.com>
References: <CANjZAi-SCAiSTySZTjU-e1Q5JOma+7RaN3Eo=H5vQaUsHVXFcA@mail.gmail.com>
 <alpine.DEB.2.11.1802011240570.1805@enira.zlyna.ubzr>
 <CANjZAi_16RMmTHANoEZd8kObnzFS7mp1i8-nT6YSL4MiMin6Ag@mail.gmail.com>
Message-ID: <CADZJ4hOTokGOMk7JkjDKPd=N-and_N4dOfk3BXdLGUa6-tP28A@mail.gmail.com>

Maybe add a short intro to the new VTKExamples?

On Feb 5, 2018 11:41 AM, "David E DeMarle" <dave.demarle at kitware.com> wrote:

> Hi Alan,
>
> Unfortunately no, not for this run through. For this first run through of
> the new material we want it to be local only. This way we can keep it
> highly interactive (it is harder to assist everyone well in an online
> group).
>
> The VTK and ParaView slides at least will be posted online, I'm not
> entirely certain yet, but I think the CMake slides will be too.
> In the next run through we will very likely open it up and at least post
> videos after the fact.
>
> thanks
>
>
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909 <(518)%20881-4909>
>
> On Thu, Feb 1, 2018 at 3:49 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
> wrote:
>
>> On 2018-02-01 15:16-0500 David E DeMarle wrote:
>>
>> Kitware is going to present three free, one day training courses next
>>> month
>>> at our Albany NY headquarters. The outline for each day follows.
>>>
>>
>> For those of who would prefer not to make such a long trip but who are
>> extremely interested in those training courses, would you be willing
>> to record a video of those training sessions and make that video
>> freely accessible on the web?
>>
>> I (and presumably many others here since this is the CMake mailing
>> list after all) would be particularly interested in watching the last-day
>> session
>>
>> March 15'th "CMake and Friends"
>>> all day: w/ Bill Hoffman
>>>
>>
>> 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:
> https://cmake.org/mailman/listinfo/cmake
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180205/765e2484/attachment.html>

From miroslav.kes at gmail.com  Mon Feb  5 12:00:39 2018
From: miroslav.kes at gmail.com (=?UTF-8?Q?Miroslav_Ke=c5=a1?=)
Date: Mon, 5 Feb 2018 18:00:39 +0100
Subject: [CMake] WIN32 set even when cross compiling = build configuration
 error
Message-ID: <c1cb405a-c3e0-300b-8a51-a9676dedd75d@gmail.com>

Hi!

I'm using CMake to cross-compile C/C++ code for VxWorks targets. I have a platform file for VxWorks and toolchain files for the target boards.
The setup works fine with CMake 3.5 and older but it didn't work with 3.6 or newer. I was getting errors like

CMake Error at C:/Program Files/CMake/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:569 (string):
? string begin index: 1 is out of range 0 - 0
Call Stack (most recent call first):
? C:/Program Files/CMake/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:37 (CMAKE_DETERMINE_COMPILER_ID_CHECK)
? C:/Program Files/CMake/share/cmake-3.10/Modules/CMakeDetermineCCompiler.cmake:112 (CMAKE_DETERMINE_COMPILER_ID)
? CMakeLists.txt:33 (project)

Now I wanted to upgrade to a newer version so I spent some time debugging the problem ...

My toolchain file defines:
?
set( CMAKE_SYSTEM_NAME VxWorks )
set( CMAKE_SYSTEM_VERSION 6.9 )
set( CMAKE_SYSTEM_PROCESSOR arm )

which should be sufficient to tell CMake that the target platform is not Windows (where the CMake is run).
But the place in CMakeDetermineCompilerId.cmake where the error occurs looks like:

??? # Detect the exact architecture from the PE header.
??? if(WIN32)
????? # The offset to the PE signature is stored at 0x3c.
????? file(READ ${file} peoffsethex LIMIT 1 OFFSET 60 HEX)
????? string(SUBSTRING "${peoffsethex}" 0 1 peoffsethex1)
????? string(SUBSTRING "${peoffsethex}" 1 1 peoffsethex2)?? <- this is where the error above occurs
?????
????? ...
??? endif()

If I add a debug print of WIN32 before the project() command and run the CMake command line for my build with the --debug-output argument, I can see that:
1. the WIN32 is set to true before the project() command
2. the WIN32 is still set to true when it is tested in the CMakeDetermineCompilerId.cmake causing the error
3. and later finally unset in CMakeSystemSpecificInformation.cmake (line 17) but it is too late.

The reason why it worked in 3.5 and earlier is not in the CMakeDetermineCompilerId.cmake but in (more tolerant) checking of? string(SUBSTRING ...) range arguments.

I was able to work around that problem explicitly resetting the WIN32 variable in my toolchain file.

But I think it is a bug in CMake and the WIN32 variable should be unset when the CMAKE_SYSTEM_NAME is redefined for cross compilation.

Regards.

Mira


From niels_dekker_address_until_2024 at xs4all.nl  Mon Feb  5 17:13:20 2018
From: niels_dekker_address_until_2024 at xs4all.nl (Niels Dekker)
Date: Mon, 5 Feb 2018 23:13:20 +0100
Subject: [CMake] Link Time Code Generation (LTGC) by default,
 for Release configurations of Visual Studio projects?
In-Reply-To: <3dc85ea5a558f6e98a6b1106ac350d6e@xs4all.nl>
References: <d181a5231af0ec0d144f98b2ccad0671@xs4all.nl>
 <CA+u+m-L88tHW3Zw5xV5X-ecSp0yXp0VQx3pHkPdzSUCWDC=8AQ@mail.gmail.com>
 <8D981219EEA621479C112DA9BDC39A8E8B912663@EXMBS1.ad.igd.fraunhofer.de>
 <3dc85ea5a558f6e98a6b1106ac350d6e@xs4all.nl>
Message-ID: <133f661b-b743-585d-4259-8a5d98beb205@xs4all.nl>

Update: I just submitted the issue to 
https://gitlab.kitware.com/cmake/cmake/issues/17720

Kind regards, Niels

-------- Previous Message --------
Subject: Re: [CMake] Link Time Code Generation (LTGC) by default, for 
Release configurations of Visual Studio projects?
Date: Fri, 26 Jan 2018 17:04:52 +0100
From: Niels Dekker

Thank you for your encouraging replies, Johannes and Cristian.

In the meantime I created "default" Visual C++ projects on Visual 
Studio 2008, Visual Studio 2010, Visual Studio 2013, Visual Studio 
2015 and Visual Studio 2017 (from within the IDE, without using 
CMake). It appears that each of these Visual Studio versions hast Link 
Time Code Generation by default, for Release configurations.

I don't have access to a machine with Visual Studio 2005. Can someone 
tell me whether this version also has Link Time Code Generation by 
default, for Release configurations?

Kind regards, Niels


On 2018-01-25 14:54, Mueller-Roemer, Johannes Sebastian wrote:
> 
> This would be a great feature! Currently I override my release flags by setting CMAKE_<LANG>_FLAGS_RELEASE_INIT and CMAKE_<TYPE>_LINKER_FLAGS_RELEASE_INIT in a CMAKE_USER_MAKE_RULES_OVERRIDE script. Direct support for /GL and /LTCG in CMake would be great. Fewer target specifics to worry about?
> 
> 
> From: CMake On Behalf Of Cristian Adam
> Sent: Wednesday, January 24, 2018 21:42
> To: Niels Dekker 
> Cc: cmake
> Subject: Re: [CMake] Link Time Code Generation (LTGC) by default, for Release configurations of Visual Studio projects?
> 
> Hi,
> 
> I had a quick check to see if CMake 3.10 for which compilers it has support for Interprocedural Optimization (IPO, or LTCG as known on Visual C++).
> 
> Modules/Compiler had only for GNU, Clang and PGI the following:
> 
> set(_CMAKE_${lang}_IPO_MAY_BE_SUPPORTED_BY_COMPILER YES)
> 
>  
> 
> QNX with QCC didn't have it set to YES even though nowdays QNX comes with GCC 5.4.0 on QNX 7.0, which should be just fine.
> 
> It would be nice if CMake would have support for IPO on Visual C++.
> 
> The steps would be to set the right variables into Modules/Compiler/MSVC-CXX.cmake, change the CheckIPOSupported module, change some flags in some places,update tests, documentation, and so on.
> 
> Shouldn't be hard to add this feature.
> 
> Cheers,
> 
> Cristian.
> 
> On Wed, Jan 24, 2018 at 9:06 PM, Niels Dekker wrote:
> 
>     When a Visual C++ project is created within Visual Studio (by File menu, New, Project...), it has Link Time Code Generation (LTGC) by default, for its Release configurations: Compiler option /GL and linker option /LTCG. However, when the Visual C++ project is generated by CMake, it does not have LTGC, by default. LTCG looks like a very useful feature to me. I think it's worth enabling the feature by default, for Release configurations. What do you think?
> 
> 
>     Some details:
> 
>     I created a "dummy" Visual C++ project in Visual Studio 2017 (Version 15.5.4), by File menu, New, Project..., and I also generated one by CMake (version 3.10.2), using a very minimal CMakeLists.txt
> 
>     The Visual C++ project created by Visual Studio 2017 has the following compile options, by default, for Release (x64):
> 
>     /permissive- /GS /GL /W3 /Gy /Zc:wchar_t /Zi /Gm- /O2 /sdl /Fd"x64\Release\vc141.pdb" /Zc:inline /fp:precise /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /Gd /Oi /MD /Fa"x64\Release\" /EHsc /nologo /Fo"x64\Release\" /Fp"x64\Release\MyVS2015Project.pch" /diagnostics:classic
> 
>     And the following linker options:
> 
>     /OUT:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.exe" /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG:FULL /MACHINE:X64 /OPT:REF /PGD:"F:\X\Src\MyProject\MyVS2015Project\x64\Release\MyVS2015Project.pgd" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Release\MyVS2015Project.exe.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
> 
>     The vcxproj file created by Visual Studio has "<WholeProgramOptimization>true</WholeProgramOptimization>" for its Release configurations.
> 
> 
>     The Visual C++ project generated by CMake (Generator: Visual Studio 15 2017 Win64) has the following compile options, for its Release configuration:
> 
>     /GS /TP /W3 /Zc:wchar_t /Gm- /O2 /Ob2 /Fd"MyExecutable.dir\Release\vc141.pdb" /Zc:inline /fp:precise /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "CMAKE_INTDIR=\"Release\"" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /GR /Gd /MD /Fa"Release/" /EHsc /nologo /Fo"MyExecutable.dir\Release\" /Fp"MyExecutable.dir\Release\MyExecutable.pch" /diagnostics:classic
> 
>     And the following linker options:
> 
>     /OUT:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.exe" /MANIFEST /NXCOMPAT /PDB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.pdb" /DYNAMICBASE "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib" /IMPLIB:"F:/X/Bin/vc141-64/MyProject/Release/MyExecutable.lib" /MACHINE:X64 /INCREMENTAL:NO /PGD:"F:\X\Bin\vc141-64\MyProject\Release\MyExecutable.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"MyExecutable.dir\Release\MyExecutable.exe.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /TLBID:1
> 
>     The vcxproj file generated by CMake does not have a "<WholeProgramOptimization>" tag.
> 
> 
>     I hope you can consider adding LTCG to Release configurations of Visual C++ projects generated by CMake, by default.
> 
> 
>     Kind regards, Niels

-- 
Niels Dekker
Scientific programmer
LKEB, Leiden University Medical Center

-- 
Niels Dekker
Scientific programmer at LKEB, Leiden University Medical Center

From julien.jomier at kitware.com  Tue Feb  6 02:39:03 2018
From: julien.jomier at kitware.com (Julien Jomier)
Date: Tue, 6 Feb 2018 08:39:03 +0100
Subject: [CMake] [ANN] CMake Training Course in Singapore - March 27-28
In-Reply-To: <2d50072b-a62a-a58a-19a2-dd2747a38b39@kitware.com>
References: <2d50072b-a62a-a58a-19a2-dd2747a38b39@kitware.com>
Message-ID: <8f00f380-bba3-4436-c368-4d97dfb7cdb6@kitware.com>

Kitware will be holding a CMake training course on March 27 and 28, 2018 
in Singapore. This two-days course will cover the best practice for 
CMake, CTest, CPack and CDash as well as advanced features of the tool

Please visit our website for more information and registration details:

     https://training.kitware.fr/browse/182

Note that the course will be taught in English. If you have any
questions, please contact us at training at kitware.fr or email me directly.

We are looking forward to seeing you in Singapore,
Julien
-- 
Kitware SAS
26 rue Louis Gu?rin
69100 Villeurbanne, France
http://www.kitware.eu

From geogin at gmail.com  Tue Feb  6 05:15:49 2018
From: geogin at gmail.com (Geogin Varghese)
Date: Tue, 6 Feb 2018 11:15:49 +0100
Subject: [CMake] Removing Transitively Inherited Properties
Message-ID: <CAC4=85KSSjCqbqo_BpNO_uhc9Axs0OknCqqvwra=-z1=5a2SSQ@mail.gmail.com>

What is the recommended way of removing transitively inherited
attributes for a target.

Example:
target_link_libraries(A PRIVATE B)
target_compile_options(B PUBLIC -Werror)

How should the -Werror option be removed from target A.

From jeanmichael.celerier at gmail.com  Tue Feb  6 05:21:36 2018
From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=)
Date: Tue, 6 Feb 2018 11:21:36 +0100
Subject: [CMake] Removing Transitively Inherited Properties
In-Reply-To: <CAC4=85KSSjCqbqo_BpNO_uhc9Axs0OknCqqvwra=-z1=5a2SSQ@mail.gmail.com>
References: <CAC4=85KSSjCqbqo_BpNO_uhc9Axs0OknCqqvwra=-z1=5a2SSQ@mail.gmail.com>
Message-ID: <CAE1uMrX-_JZ1vaH2YpCpYeVN9QMP+zPME8mHmcanY39h=VGLaw@mail.gmail.com>

For stuff like this one you could add -Wno-error afterwards to A's
compile_options.



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

On Tue, Feb 6, 2018 at 11:15 AM, Geogin Varghese <geogin at gmail.com> wrote:

> What is the recommended way of removing transitively inherited
> attributes for a target.
>
> Example:
> target_link_libraries(A PRIVATE B)
> target_compile_options(B PUBLIC -Werror)
>
> How should the -Werror option be removed from target A.
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180206/aaa85144/attachment.html>

From sergey.nikulov at gmail.com  Tue Feb  6 05:47:50 2018
From: sergey.nikulov at gmail.com (Sergei Nikulov)
Date: Tue, 6 Feb 2018 13:47:50 +0300
Subject: [CMake] Removing Transitively Inherited Properties
In-Reply-To: <CAC4=85KSSjCqbqo_BpNO_uhc9Axs0OknCqqvwra=-z1=5a2SSQ@mail.gmail.com>
References: <CAC4=85KSSjCqbqo_BpNO_uhc9Axs0OknCqqvwra=-z1=5a2SSQ@mail.gmail.com>
Message-ID: <CAE7Ac0DeP3qXQYRCqL7SjvTAsX53jiDQ-Cu09eDCLBTpK=WwPg@mail.gmail.com>

2018-02-06 13:15 GMT+03:00 Geogin Varghese <geogin at gmail.com>:
> What is the recommended way of removing transitively inherited
> attributes for a target.
>
> Example:
> target_link_libraries(A PRIVATE B)
> target_compile_options(B PUBLIC -Werror)
>

Shouldn't it be PRIVATE for B?
E.g.  target_compile_options(B PRIVATE -Werror)

https://cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements

"
Each of the commands has a PRIVATE, PUBLIC and INTERFACE mode. The
PRIVATE mode populates only the non-INTERFACE_ variant of the target
property and the INTERFACE mode populates only the INTERFACE_
variants. The PUBLIC mode populates both variants of the respective
target property.
"


> How should the -Werror option be removed from target A.
> --
>
> 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



-- 
Best Regards,
Sergei Nikulov

From bill.hoffman at kitware.com  Tue Feb  6 11:48:05 2018
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Tue, 6 Feb 2018 11:48:05 -0500
Subject: [CMake] Free CMake course at Kitware Headquarters March 13-15,
 2018 at Kitware's Clifton Park, NY, USA
Message-ID: <cde80b74-3ef0-b704-c1bf-dc6d0c2eadc9@kitware.com>

Kitware is offering a free course on VTK/ParaView/CMake March 13-15, 
2018 at Kitware's Clifton Park, NY, USA.  The signup can be found here:

https://docs.google.com/forms/d/e/1FAIpQLSeee7oTBzapITmark0dIX0E86zEyyPmh-LEbecz2zm_822WFw/viewform

Hope to meet some of you in person.

-Bill

From cristian.adam at gmail.com  Wed Feb  7 07:27:28 2018
From: cristian.adam at gmail.com (Cristian Adam)
Date: Wed, 7 Feb 2018 13:27:28 +0100
Subject: [CMake] cmake_format
Message-ID: <CA+u+m-LsZT1BaLO8MK9odNBnFwpGZOiG7Nq9J8Abj28Z2QL7cA@mail.gmail.com>

Hi,

I don't remember seeing this tool advertised on the CMake mailing lists:

https://github.com/cheshirekow/cmake_format/tree/master/cmake_format

*cmake-format can format your listfiles nicely so that they don't look like
crap.*

Cheers,
Cristian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180207/e5dd2caf/attachment.html>

From ben.boeckel at kitware.com  Wed Feb  7 08:30:25 2018
From: ben.boeckel at kitware.com (Ben Boeckel)
Date: Wed, 7 Feb 2018 08:30:25 -0500
Subject: [CMake] [cmake-developers] cmake_format
In-Reply-To: <CA+u+m-LsZT1BaLO8MK9odNBnFwpGZOiG7Nq9J8Abj28Z2QL7cA@mail.gmail.com>
References: <CA+u+m-LsZT1BaLO8MK9odNBnFwpGZOiG7Nq9J8Abj28Z2QL7cA@mail.gmail.com>
Message-ID: <20180207133025.GA7097@megas.kitware.com>

On Wed, Feb 07, 2018 at 13:27:28 +0100, Cristian Adam wrote:
> I don't remember seeing this tool advertised on the CMake mailing lists:
> 
> https://github.com/cheshirekow/cmake_format/tree/master/cmake_format

Cool! I have some feature requests, but I'll add them over there :) .

--Ben

From saadrustam at gmail.com  Wed Feb  7 12:51:48 2018
From: saadrustam at gmail.com (Saad Khattak)
Date: Wed, 07 Feb 2018 17:51:48 +0000
Subject: [CMake] Update and build child projects if a parent (dependency) is
 updated
Message-ID: <CAEM70sO3CR0EC3mChjULOto0Nk708qvorEWM2CLnmNUmEXm1qw@mail.gmail.com>

Hi,

I have a lot of projects with many dependencies. Support ProjE depends on
ProjD which in turn depends on ProjB and ProjC where ProjB depends on ProjA.

If ProjA, is updated, I would like some way to trigger the generate/build
(or just build, assuming the projects are already generated) ProjB, ProjD
and ProjE (not ProjC as it did not depend on ProjA).

I realize this is not possible without ProjA somehow knowing about its
dependent projects. And so I don't mind if it's a new master project or
super build. What I would like however is for CMake to generate this master
project for me (as it already knows the dependency hierarchy). Then, it'll
just be a matter of building this 'superbuild' which in turn detects that
ProjA has been updated, and updates/builds all its dependents.

I can do this manually by ExternalProject_Add, but that is just error prone
and not at all automated. If the projects go into the double or triple
digit range, you can see why manually preparing the superbuild project is
not a good solution.

Thanks,
Saad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180207/fb6426fe/attachment.html>

From ashaduri at gmail.com  Wed Feb  7 13:25:28 2018
From: ashaduri at gmail.com (Alexander Shaduri)
Date: Wed, 07 Feb 2018 22:25:28 +0400
Subject: [CMake] CPack + WIX + vcredist, is it possible?
Message-ID: <1518027928.3372.10.camel@gmail.com>

Hello,

Is it possible to use CPack with WIX (Windows Installer) generator and
run vcredist_*.exe at install time?

Some considerations:

* WIX cannot run two installers at once so something called Burn has to
be used. I'm not sure whether CPack can do it, I cannot find any
relevant documentation.

* MSM (merge modules) are usually suggested instead of vcredist, but
they are discouraged by MS and there is no UCRT MSM which is needed by
programs compiled with VS2017, so vcredist has to be used.

* I don't want to use local dll deployment since it's discouraged by
MS, plus I don't think it's a good solution for various reasons.

Thanks,
Alexander


From craig.scott at crascit.com  Wed Feb  7 16:53:19 2018
From: craig.scott at crascit.com (Craig Scott)
Date: Wed, 07 Feb 2018 21:53:19 +0000
Subject: [CMake] Update and build child projects if a parent
 (dependency) is updated
In-Reply-To: <CAEM70sO3CR0EC3mChjULOto0Nk708qvorEWM2CLnmNUmEXm1qw@mail.gmail.com>
References: <CAEM70sO3CR0EC3mChjULOto0Nk708qvorEWM2CLnmNUmEXm1qw@mail.gmail.com>
Message-ID: <CA+dygYmtuaGmjFW_piLF0ya9gMxhh0n6BcTZdbOpHJc+Dyfkzw@mail.gmail.com>

On Thu, 8 Feb 2018 at 4:52 am, Saad Khattak <saadrustam at gmail.com> wrote:

> Hi,
>
> I have a lot of projects with many dependencies. Support ProjE depends on
> ProjD which in turn depends on ProjB and ProjC where ProjB depends on ProjA.
>
> If ProjA, is updated, I would like some way to trigger the generate/build
> (or just build, assuming the projects are already generated) ProjB, ProjD
> and ProjE (not ProjC as it did not depend on ProjA).
>
> I realize this is not possible without ProjA somehow knowing about its
> dependent projects. And so I don't mind if it's a new master project or
> super build. What I would like however is for CMake to generate this master
> project for me (as it already knows the dependency hierarchy). Then, it'll
> just be a matter of building this 'superbuild' which in turn detects that
> ProjA has been updated, and updates/builds all its dependents.
>
> I can do this manually by ExternalProject_Add, but that is just error
> prone and not at all automated. If the projects go into the double or
> triple digit range, you can see why manually preparing the superbuild
> project is not a good solution.
>

An alternative to the superbuild approach is the new FetchContent module
that has been added in the upcoming 3.11 release. You can see the docs for
it here:

https://cmake.org/cmake/help/git-master/module/FetchContent.html

It may be more convenient for the situation you describe. There?s even a
somewhat similar example in those docs for inter project dependencies along
the lines of your case.



> --
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180207/25d464c7/attachment.html>

From hot486two at gmail.com  Wed Feb  7 20:42:13 2018
From: hot486two at gmail.com (jaeho jo)
Date: Thu, 8 Feb 2018 10:42:13 +0900
Subject: [CMake] Question about eclipse
Message-ID: <CAAhJeqbyAZ5m6H_-8f7GR0OMFPxMG3ZH8yme9OkfLXWzeUpgTg@mail.gmail.com>

Hi! I have a Question aboue eclipse.

I have a one C project in eclipse.

I have built this project only using eclipse so far.

I want to build thid C project using cmake

  Should I write the CMakeLists.txt file myself?? or Is there a way to set
CMake build environment automatically?

I can find many way to import existing cmake project to eclipse.

But, I can't find how to set cmake build configuration about existing
eclipse C project easily

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180208/d950d145/attachment.html>

From nicolas at babelouest.org  Thu Feb  8 09:47:09 2018
From: nicolas at babelouest.org (Nicolas Mora)
Date: Thu, 8 Feb 2018 09:47:09 -0500
Subject: [CMake] CMake tar.gz package does not include all installed files
Message-ID: <b36004e2-cc8e-e031-b543-b9619a6128b3@babelouest.org>

Hello,

I use a CMakeLists.txt script to build an application which works pretty 
well so far, except for the tar.gz package build.

In the install procedure, I copy the application executable, the config 
files and, SysV init and SystemD service files, and an entire directory.

In the make install and in the .deb file generated, all those files are 
correctly installed. But the .tar.gz package only has the executable and 
the config file, not the rest.

Can anyone help me point out where my mistake is?

The script is available here:
https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt

The install commands that are missing in the .tar.gz package are the 
following:
https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L211
https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L212
https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L213

And the .tar.gz package generator commands are here:
https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L252

Thanks in advance

From eric.noulard at gmail.com  Thu Feb  8 11:10:16 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Thu, 8 Feb 2018 17:10:16 +0100
Subject: [CMake] CMake tar.gz package does not include all installed
 files
In-Reply-To: <b36004e2-cc8e-e031-b543-b9619a6128b3@babelouest.org>
References: <b36004e2-cc8e-e031-b543-b9619a6128b3@babelouest.org>
Message-ID: <CAPASGLqeHi8JrP1YgmyorHC2LbSV1ViMPXqX79NCqdb2PXTTTw@mail.gmail.com>

Hi Nicolas,

AFAIK
CPack Archive generators (ZIP, TGZ, etc...) cannot properly handle
ABSOLUTE_INSTALL path.
The 3 install statements:

install(FILES glewlwyd.service DESTINATION
${CMAKE_INSTALL_PREFIX}/lib/systemd/system COMPONENT config)
install(FILES glewlwyd-init DESTINATION ${CMAKE_INSTALL_PREFIX}/etc/init.d/
RENAME glewlwyd COMPONENT config)
install(DIRECTORY webapp/ DESTINATION
${CMAKE_INSTALL_PREFIX}/share/glewlwyd/webapp/ COMPONENT runtime)

Use a DESTINATION which is absolute. Thus the issue with archive generator.

CPackDeb and CPackRPM do handle absolute install path "transparently"
because they internally set CPACK_SET_DESTDIR.

Have a look at
cmake --help-variable CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
and
cmake --help-variable CPACK_SET_DESTDIR



2018-02-08 15:47 GMT+01:00 Nicolas Mora <nicolas at babelouest.org>:

> Hello,
>
> I use a CMakeLists.txt script to build an application which works pretty
> well so far, except for the tar.gz package build.
>
> In the install procedure, I copy the application executable, the config
> files and, SysV init and SystemD service files, and an entire directory.
>
> In the make install and in the .deb file generated, all those files are
> correctly installed. But the .tar.gz package only has the executable and
> the config file, not the rest.
>
> Can anyone help me point out where my mistake is?
>
> The script is available here:
> https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt
>
> The install commands that are missing in the .tar.gz package are the
> following:
> https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L211
> https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L212
> https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L213
>
> And the .tar.gz package generator commands are here:
> https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L252
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>



-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180208/8fe3184e/attachment-0001.html>

From denisacostaq at gmail.com  Thu Feb  8 11:24:58 2018
From: denisacostaq at gmail.com (Alvaro Denis)
Date: Thu, 8 Feb 2018 11:24:58 -0500
Subject: [CMake] CTest - AddressSanitizer - Suppressing Reports in External
 Libraries - Issue
Message-ID: <CAJU5dMf5rwLX9M1o+p7hJhFfaS_8AO8NWQd5j+thBAWarR+xYQ@mail.gmail.com>

Hello,
I have a problem with a CMake project,
here(https://stackoverflow.com/questions/48689620/suppressing-reports-in-external-libraries-ignored-in-a-cmake-project)
full description, the project as an attachment, can someone help me to
know what I am missing?
Regards



-- 





Ing. Alvaro Denis Acosta
[image: https://]about.me/denisacostaq
<https://about.me/denisacostaq?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>


[image: --]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sanitazer.tar.gz
Type: application/x-gzip
Size: 1963 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20180208/0c2baf67/attachment.bin>

From ashaduri at gmail.com  Thu Feb  8 11:44:41 2018
From: ashaduri at gmail.com (Alexander Shaduri)
Date: Thu, 08 Feb 2018 20:44:41 +0400
Subject: [CMake] Don't show components page in NSIS installer (CPack)
Message-ID: <1518108281.3395.15.camel@gmail.com>

Hi,

I need to install only certain components, but avoid showing
the components page in cpack-generated NSIS installer.

I have:

# Only install the main program and vcredist.
set(CPACK_COMPONENTS_ALL core vcredist)

set(CMAKE_INSTALL_SYSTEM_RUNTIME_COMPONENT "system_dlls")

# This installs dlls as "system_dlls" component and sets *MSVC* variables
include(InstallRequiredSystemLibraries)

install(PROGRAMS "${MSVC_REDIST_DIR}/vcredist_${CMAKE_MSVC_ARCH}.exe"
	COMPONENT vcredist)

The main problem is that InstallRequiredSystemLibraries unconditionally
installs the dlls which should not be installed in case of NSIS.
However, I need to include it because it provides the vcredist
location.

So, using?CPACK_COMPONENTS_ALL, I avoid installing "system_dlls"
component. However, NSIS installer shows a "Components" page which
should not be shown. So, is there any way to disable it?
So far I've only found?CPACK_MONOLITHIC_INSTALL, but it causes
all the components to install.

Thanks,
Alexander


From denisacostaq at gmail.com  Thu Feb  8 11:50:52 2018
From: denisacostaq at gmail.com (Alvaro Denis)
Date: Thu, 8 Feb 2018 11:50:52 -0500
Subject: [CMake] Dynamic Analysis with Clang - Suppressing Reports in
 External Libraries Ignored in a CMake project
Message-ID: <CAJU5dMeCa_NyX-FwqO_7nX9UQTcgO3zjsZjRTfjCADjxy7VTyQ@mail.gmail.com>

Hello,
I have a problem with a CMake project,
here(https://stackoverflow.com/questions/48689620/suppressing-reports-in-external-libraries-ignored-in-a-cmake-project)
full description, the project as an attachment, can someone help me to
know what I am missing?
Regards



-- 





Ing. Alvaro Denis Acosta
[image: https://]about.me/denisacostaq
<https://about.me/denisacostaq?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>


[image: --]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Sanitazer.tar.gz
Type: application/x-gzip
Size: 1963 bytes
Desc: not available
URL: <https://cmake.org/pipermail/cmake/attachments/20180208/30a0db55/attachment.bin>

From Arjen.Markus at deltares.nl  Thu Feb  8 14:33:42 2018
From: Arjen.Markus at deltares.nl (Arjen Markus)
Date: Thu, 8 Feb 2018 19:33:42 +0000
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
Message-ID: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>

Hello,



In the PLplot project we are looking for a way to combine the MinGW-w64/MSYS2 platform (or Cygwin) with the NAG Fortran compiler. The reason for this is that both MinGW-w64/MSYS2 and Cygwin come with a nice repository of libraries, some of which we can use in the context of PLplot. The NAG Fortran compiler is a very nice, strict, compiler that is available for both Windows and Linux (and possibly other platforms as well). I know in principle how to combine NAG Fortran with the GCC tools, so this part of the combination is not the problem.



The problem is rather this:

If I start a console with MinGW-w64/MSYS2 or Cygwin I get an environment where all the libraries that I want can be found, but that environment is identified by CMake as "MinGW" or "Cygwin", so that the NAG Fortran specific settings are ignored.



(I store them in a file MinGW-NAG-Fortran.cmake, in analogy with all the other such files - a file Windows-NAG-Fortran.cmake does do the job for the "bare" Windows platform.)



The NAG Fortran compiler is selected, just like I want, instead of the gfortran compiler, as I define FC to be "nagfor" and I have expanded the PATH to include all the stuff for NAG Fortran.



But the crucial part is that CMake uses the settings for the GNU compilers.



So: Is it possible to instruct CMake to use the NAG-Fortran specific settings and if so, how do I do that?



Regards,



Arjen



DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180208/39894f5c/attachment.html>

From nicolas at babelouest.org  Thu Feb  8 14:39:27 2018
From: nicolas at babelouest.org (Nicolas Mora)
Date: Thu, 8 Feb 2018 14:39:27 -0500
Subject: [CMake] CMake tar.gz package does not include all installed
 files
In-Reply-To: <CAPASGLqeHi8JrP1YgmyorHC2LbSV1ViMPXqX79NCqdb2PXTTTw@mail.gmail.com>
References: <b36004e2-cc8e-e031-b543-b9619a6128b3@babelouest.org>
 <CAPASGLqeHi8JrP1YgmyorHC2LbSV1ViMPXqX79NCqdb2PXTTTw@mail.gmail.com>
Message-ID: <c53db603-d707-6293-1199-fbe0db27c8fa@babelouest.org>

That was the root problem indeed!

I cleaned the code and fixed the path with ${CMAKE_INSTALL_DATAROOTDIR}:

install(FILES ${CMAKE_CURRENT_BINARY_DIR}/glewlwyd
         DESTINATION ${CMAKE_INSTALL_BINDIR})
install(FILES glewlwyd.conf.sample
         DESTINATION ${CMAKE_INSTALL_SYSCONFDIR}/glewlwyd RENAME 
glewlwyd.conf COMPONENT config)
install(DIRECTORY webapp/
         DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/glewlwyd/webapp/ 
COMPONENT runtime)

Thanks a lot for the help!

Le 2018-02-08 ? 11:10, Eric Noulard a ?crit?:
> Hi Nicolas,
> 
> AFAIK
> CPack Archive generators (ZIP, TGZ, etc...) cannot properly handle 
> ABSOLUTE_INSTALL path.
> The 3 install statements:
> 
> install(FILES glewlwyd.service DESTINATION 
> ${CMAKE_INSTALL_PREFIX}/lib/systemd/system COMPONENT config)
> install(FILES glewlwyd-init DESTINATION 
> ${CMAKE_INSTALL_PREFIX}/etc/init.d/ RENAME glewlwyd COMPONENT config)
> install(DIRECTORY webapp/ DESTINATION 
> ${CMAKE_INSTALL_PREFIX}/share/glewlwyd/webapp/ COMPONENT runtime)
> 
> Use a DESTINATION which is absolute. Thus the issue with archive generator.
> 
> CPackDeb and CPackRPM do handle absolute install path "transparently" 
> because they internally set?CPACK_SET_DESTDIR.
> 
> Have a look at
> cmake --help-variable CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
> and
> cmake --help-variable CPACK_SET_DESTDIR
> 
> 
> 
> 2018-02-08 15:47 GMT+01:00 Nicolas Mora <nicolas at babelouest.org 
> <mailto:nicolas at babelouest.org>>:
> 
>     Hello,
> 
>     I use a CMakeLists.txt script to build an application which works
>     pretty well so far, except for the tar.gz package build.
> 
>     In the install procedure, I copy the application executable, the
>     config files and, SysV init and SystemD service files, and an entire
>     directory.
> 
>     In the make install and in the .deb file generated, all those files
>     are correctly installed. But the .tar.gz package only has the
>     executable and the config file, not the rest.
> 
>     Can anyone help me point out where my mistake is?
> 
>     The script is available here:
>     https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt
>     <https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt>
> 
>     The install commands that are missing in the .tar.gz package are the
>     following:
>     https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L211 <https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L211>
>     https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L212 <https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L212>
>     https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L213 <https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L213>
> 
>     And the .tar.gz package generator commands are here:
>     https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L252 <https://github.com/babelouest/glewlwyd/blob/cmake/CMakeLists.txt#L252>
> 
>     Thanks in advance
>     -- 
> 
>     Powered by www.kitware.com <http://www.kitware.com>
> 
>     Please keep messages on-topic and check the CMake FAQ at:
>     http://www.cmake.org/Wiki/CMake_FAQ
>     <http://www.cmake.org/Wiki/CMake_FAQ>
> 
>     Kitware offers various services to support the CMake community. For
>     more information on each offering, please visit:
> 
>     CMake Support: http://cmake.org/cmake/help/support.html
>     <http://cmake.org/cmake/help/support.html>
>     CMake Consulting: http://cmake.org/cmake/help/consulting.html
>     <http://cmake.org/cmake/help/consulting.html>
>     CMake Training Courses: http://cmake.org/cmake/help/training.html
>     <http://cmake.org/cmake/help/training.html>
> 
>     Visit other Kitware open-source projects at
>     http://www.kitware.com/opensource/opensource.html
>     <http://www.kitware.com/opensource/opensource.html>
> 
>     Follow this link to subscribe/unsubscribe:
>     https://cmake.org/mailman/listinfo/cmake
>     <https://cmake.org/mailman/listinfo/cmake>
> 
> 
> 
> 
> -- 
> Eric

From irwin at beluga.phys.uvic.ca  Thu Feb  8 16:58:59 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Thu, 8 Feb 2018 13:58:59 -0800 (PST)
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
Message-ID: <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>

On 2018-02-08 19:33-0000 Arjen Markus wrote:

> So: Is it possible to instruct CMake to use the NAG-Fortran specific
settings [for the Cygwin and MinGW-w64/MSYS2 platforms] and if so, how do I do that?

Hi Arjen:

I think you should be guided by what goes on for gfortran. For that
compiler, the relevant Platform files are called
CYGWIN-GNU-Fortran.cmake and Windows-GNU-Fortran.cmake Platform files
for the Cygwin, and MinGW-w64/MSYS2 platforms.  Furthermore, in all
the existing nagfor cases (Linux and Darwin), you derive the
nagfor-related name from the gfortran related name by replacing
GNU-Fortran by NAG-Fortran. Therefore, I suggest you try the names
CYGWIN-NAG-Fortran.cmake and Windows-NAG-Fortran.cmake for the two
separate Platform files you are trying to create for the Cygwin and
MinGW-w64/MSYS2 platforms.

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
__________________________

From Arjen.Markus at deltares.nl  Fri Feb  9 02:36:02 2018
From: Arjen.Markus at deltares.nl (Arjen Markus)
Date: Fri, 9 Feb 2018 07:36:02 +0000
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
Message-ID: <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>

Hi Alan,

> -----Original Message-----
> From: Alan W. Irwin [mailto:irwin at beluga.phys.uvic.ca]
> Sent: Thursday, February 08, 2018 10:59 PM
> To: Arjen Markus
> Cc: cmake at cmake.org
> Subject: Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
> combine?
>
> On 2018-02-08 19:33-0000 Arjen Markus wrote:
>
> > So: Is it possible to instruct CMake to use the NAG-Fortran specific
> settings [for the Cygwin and MinGW-w64/MSYS2 platforms] and if so, how do I do
> that?
>
> Hi Arjen:
>
> I think you should be guided by what goes on for gfortran. For that compiler, the
> relevant Platform files are called CYGWIN-GNU-Fortran.cmake and Windows-
> GNU-Fortran.cmake Platform files for the Cygwin, and MinGW-w64/MSYS2
> platforms.  Furthermore, in all the existing nagfor cases (Linux and Darwin), you
> derive the nagfor-related name from the gfortran related name by replacing GNU-
> Fortran by NAG-Fortran. Therefore, I suggest you try the names CYGWIN-NAG-
> Fortran.cmake and Windows-NAG-Fortran.cmake for the two separate Platform
> files you are trying to create for the Cygwin and
> MinGW-w64/MSYS2 platforms.
>
I have a Platform file "Windows-NAG-Fortran.cmake" and that is used correctly if I start the NAG Fortran environment (using the MinGW Makefiles generator), but if I try the same with MinGWw-w64/MSYS2, this file is clearly ignored - I see the compiler fail on a typical GCC flag for creating shared libraries (the Platform file I added takes care of that in the NAG Fortran environment and therefore the build succeeds).

My guess is that the environment is determined in an early stage and then GNU/GCC has already been selected. But not all is lost - I realised that I may be able to get around this by expanding the PATH with the MinGW-w64/MSYS2 specific directories. I have not tried that yet.

Though I am still interested in other solutions ;).

Regards,

Arjen





DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180209/7e19c772/attachment-0001.html>

From amiblit at gmail.com  Fri Feb  9 03:52:30 2018
From: amiblit at gmail.com (AmigaBlitter)
Date: Fri, 9 Feb 2018 01:52:30 -0700 (MST)
Subject: [CMake] Problem compiling commander-genius (cross compiling)
Message-ID: <1518166350717-0.post@n2.nabble.com>


Hello everyone,

i'm new to this forum.

I'm trying to port Commander-Genius
(https://github.com/gerstrong/Commander-Genius) to an exotic platform -
AmigaOS 4.1 PPC.

I created a toolchain file to specify what compiler i'm using as follow:

ToolChain files
# this one is important
SET(CMAKE_SYSTEM_NAME AmigaOS)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)

# specify the cross compiler
SET(CMAKE_C_COMPILER  
/usr/local/amiga/adtools-ppc-uwin64-20170623-404/bin/ppc-amigaos-gcc)
SET(CMAKE_CXX_COMPILER
/usr/local/amiga/adtools-ppc-uwin64-20170623-404/bin/ppc-amigaos-g++)

# where is the target environment
SET(CMAKE_FIND_ROOT_PATH  /usr/local/amiga/adtools-ppc-uwin64-20170623-404)

# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Issuing cmake -DCMAKE_TOOLCHAIN_FILE=./Toolchain-ppc-amigaos.cmake
-DUSE_SDL2=yes

Compilations starts, but at the end i get some messages as follow:
usr/bin/ld: /SDK/local/newlib/lib/libSDL2.so: Relocations in generic ELF
(EM: 20)

Could someone give me an hint?

Kind regards




--
Sent from: http://cmake.3232098.n2.nabble.com/

From irwin at beluga.phys.uvic.ca  Fri Feb  9 05:26:30 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Fri, 9 Feb 2018 02:26:30 -0800 (PST)
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
Message-ID: <alpine.DEB.2.11.1802090149340.1805@enira.zlyna.ubzr>

On 2018-02-09 07:36-0000 Arjen Markus wrote:

> Hi Alan,
>
>> -----Original Message-----
>> From: Alan W. Irwin [mailto:irwin at beluga.phys.uvic.ca]
>> Sent: Thursday, February 08, 2018 10:59 PM
>> To: Arjen Markus
>> Cc: cmake at cmake.org
>> Subject: Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
>> combine?
>>
>> On 2018-02-08 19:33-0000 Arjen Markus wrote:
>>
>>> So: Is it possible to instruct CMake to use the NAG-Fortran specific
>> settings [for the Cygwin and MinGW-w64/MSYS2 platforms] and if so, how do I do
>> that?
>>
>> Hi Arjen:
>>
>> I think you should be guided by what goes on for gfortran. For that compiler, the
>> relevant Platform files are called CYGWIN-GNU-Fortran.cmake and Windows-
>> GNU-Fortran.cmake Platform files for the Cygwin, and MinGW-w64/MSYS2
>> platforms.  Furthermore, in all the existing nagfor cases (Linux and Darwin), you
>> derive the nagfor-related name from the gfortran related name by replacing GNU-
>> Fortran by NAG-Fortran. Therefore, I suggest you try the names CYGWIN-NAG-
>> Fortran.cmake and Windows-NAG-Fortran.cmake for the two separate Platform
>> files you are trying to create for the Cygwin and
>> MinGW-w64/MSYS2 platforms.
>>
> I have a Platform file "Windows-NAG-Fortran.cmake" and that is used
correctly if I start the NAG Fortran environment (using the MinGW
Makefiles generator), but if I try the same with MinGWw-w64/MSYS2,
this file is clearly ignored - I see the compiler fail on a typical
GCC flag for creating shared libraries (the Platform file I added
takes care of that in the NAG Fortran environment and therefore the
build succeeds).

Hi Arjen:

Is the issue that you used the "Unix Makefiles" generator rather than
the "MSYS Makefiles" generator for the MinGW-w64/MSYS2 test?  I
believe you have found both generators work pretty well for this
platform, but in order to use your "Windows-NAG-Fortran.cmake" platform
file, you may find that the "MSYS Makefiles" generator is the one you
*must* use.

If you report back that experiment doesn't work, then we need a
knowledgable CMake developer to chime in here to let you know exactly
what Platform filename is correct for the nagfor compiler on the
MinGW-w64/MSYS2 platform for either/both the "Unix Makefiles" and
"MSYS Makefiles" generators.

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
__________________________

From Arjen.Markus at deltares.nl  Fri Feb  9 05:29:31 2018
From: Arjen.Markus at deltares.nl (Arjen Markus)
Date: Fri, 9 Feb 2018 10:29:31 +0000
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <alpine.DEB.2.11.1802090149340.1805@enira.zlyna.ubzr>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802090149340.1805@enira.zlyna.ubzr>
Message-ID: <8CF085736108634681FD03EC36E6A0729DA37F87@V-EXC-C02.DIRECTORY.INTRA>

Hi Alan,



> -----Original Message-----
> From: Alan W. Irwin [mailto:irwin at beluga.phys.uvic.ca]
> Sent: Friday, February 09, 2018 11:27 AM
> To: Arjen Markus
>
> Is the issue that you used the "Unix Makefiles" generator rather than the "MSYS
> Makefiles" generator for the MinGW-w64/MSYS2 test?  I believe you have found
> both generators work pretty well for this platform, but in order to use your
> "Windows-NAG-Fortran.cmake" platform file, you may find that the "MSYS
> Makefiles" generator is the one you
> *must* use.
>
Hm, you may be right - I will try that today (left-over from a previous attempt :)).

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180209/57fc5b31/attachment.html>

From Arjen.Markus at deltares.nl  Fri Feb  9 05:44:31 2018
From: Arjen.Markus at deltares.nl (Arjen Markus)
Date: Fri, 9 Feb 2018 10:44:31 +0000
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <8CF085736108634681FD03EC36E6A0729DA37F87@V-EXC-C02.DIRECTORY.INTRA>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802090149340.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37F87@V-EXC-C02.DIRECTORY.INTRA>
Message-ID: <8CF085736108634681FD03EC36E6A0729DA37FC2@V-EXC-C02.DIRECTORY.INTRA>

Hi Alan,



The result is the same or very much the same.



Regards,



Arjen

From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Arjen Markus
Sent: Friday, February 09, 2018 11:30 AM
To: Alan W. Irwin
Cc: cmake at cmake.org
Subject: Re: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to combine?


>
Hm, you may be right - I will try that today (left-over from a previous attempt :)).

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180209/7f301a77/attachment.html>

From irwin at beluga.phys.uvic.ca  Fri Feb  9 12:24:52 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Fri, 9 Feb 2018 09:24:52 -0800 (PST)
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <8CF085736108634681FD03EC36E6A0729DA37FC2@V-EXC-C02.DIRECTORY.INTRA>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802090149340.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37F87@V-EXC-C02.DIRECTORY.INTRA>
 <8CF085736108634681FD03EC36E6A0729DA37FC2@V-EXC-C02.DIRECTORY.INTRA>
Message-ID: <alpine.DEB.2.11.1802090914390.1805@enira.zlyna.ubzr>

On 2018-02-09 10:44-0000 Arjen Markus wrote:

> Hi Alan,
>
>
>
> The result is the same or very much the same.

OK.  Time for more knowledgable people to weigh in here about what
Platform filenames to use for the combination of nagfor and
MinGW-w64/MSYS2 for the "Unix Makefiles" and "MSYS Makefiles"
generators.

Meanwhile, can you test whether the Platform filename I suggested for
the nagfor Cygwin case with "Unix Makefiles" generator is correct?

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
__________________________

From hintonda at gmail.com  Fri Feb  9 23:51:04 2018
From: hintonda at gmail.com (Don Hinton)
Date: Fri, 9 Feb 2018 20:51:04 -0800
Subject: [CMake] Problem compiling commander-genius (cross compiling)
In-Reply-To: <1518166350717-0.post@n2.nabble.com>
References: <1518166350717-0.post@n2.nabble.com>
Message-ID: <CAL2T-v68r5zA5JbrQnoyJWH0aNAqc+bB0rv4vwxCf5tK4HB03A@mail.gmail.com>

On Fri, Feb 9, 2018 at 12:52 AM, AmigaBlitter <amiblit at gmail.com> wrote:

>
> Hello everyone,
>
> i'm new to this forum.
>
> I'm trying to port Commander-Genius
> (https://github.com/gerstrong/Commander-Genius) to an exotic platform -
> AmigaOS 4.1 PPC.
>
> I created a toolchain file to specify what compiler i'm using as follow:
>
> ToolChain files
> # this one is important
> SET(CMAKE_SYSTEM_NAME AmigaOS)
> #this one not so much
> SET(CMAKE_SYSTEM_VERSION 1)
>
> # specify the cross compiler
> SET(CMAKE_C_COMPILER
> /usr/local/amiga/adtools-ppc-uwin64-20170623-404/bin/ppc-amigaos-gcc)
> SET(CMAKE_CXX_COMPILER
> /usr/local/amiga/adtools-ppc-uwin64-20170623-404/bin/ppc-amigaos-g++)
>
> # where is the target environment
> SET(CMAKE_FIND_ROOT_PATH  /usr/local/amiga/adtools-ppc-
> uwin64-20170623-404)
>

Try setting CMAKE_SYSROOT instead of CMAKE_FIND_ROOT_PATH.  The find_*()
functions check CMAKE_SYSROOT first if set, and cmake will also pass
"--sysroot=${CMAKE_SYSROOT}" for you.  With clang, I also set
CMAKE_<lang>_COMPILER_TARGET for each language I need, e.g., C, CXX, and
ASM, but that's probably not necessary with gcc.

hth...
don


>
> # search for programs in the build host directories
> SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> # for libraries and headers in the target directories
> SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>
> Issuing cmake -DCMAKE_TOOLCHAIN_FILE=./Toolchain-ppc-amigaos.cmake
> -DUSE_SDL2=yes
>
> Compilations starts, but at the end i get some messages as follow:
> usr/bin/ld: /SDK/local/newlib/lib/libSDL2.so: Relocations in generic ELF
> (EM: 20)
>
> Could someone give me an hint?
>
> Kind regards
>
>
>
>
> --
> Sent from: http://cmake.3232098.n2.nabble.com/
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180209/c33447ae/attachment.html>

From mojca at macports.org  Sat Feb 10 02:04:04 2018
From: mojca at macports.org (Mojca Miklavec)
Date: Sat, 10 Feb 2018 08:04:04 +0100
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <alpine.DEB.2.11.1802090914390.1805@enira.zlyna.ubzr>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802090149340.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37F87@V-EXC-C02.DIRECTORY.INTRA>
 <8CF085736108634681FD03EC36E6A0729DA37FC2@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802090914390.1805@enira.zlyna.ubzr>
Message-ID: <CALBOmsYWAZX7ztkbiVYLe62QR=K2jy5Op1N1fk7AcVyJCLrnXA@mail.gmail.com>

On 9 February 2018 at 18:24, Alan W. Irwin wrote:
> On 2018-02-09 10:44-0000 Arjen Markus wrote:
>
>> Hi Alan,
>>
>> The result is the same or very much the same.
>
> OK.  Time for more knowledgable people to weigh in here about what
> Platform filenames to use for the combination of nagfor and
> MinGW-w64/MSYS2 for the "Unix Makefiles" and "MSYS Makefiles"
> generators.
>
> Meanwhile, can you test whether the Platform filename I suggested for
> the nagfor Cygwin case with "Unix Makefiles" generator is correct?
>
> Alan

I wonder if this is in any way related to
    https://cmake.org/Bug/view.php?id=14252

We had numerous problems with Fortran flags simply inheriting settings
from CFLAGS under assumption that the Fortran compiler must be "the
same" as C complier and probably understand the same flags.

Our most burning issue was resolved once GCC's Fortran stopped
complaining about "-arch", but the underlying problem in CMake was
probably never resolved. We were also not able to prevent the use of
Fortran in case it was detected on the system. This must be a
consequence of very few people still using Fortran and thus the
interest was not as high as fixing bugs for C/C++ compilers.

Mojca

From fifteenknots505 at gmail.com  Sat Feb 10 08:39:17 2018
From: fifteenknots505 at gmail.com (Martin Weber)
Date: Sat, 10 Feb 2018 14:39:17 +0100
Subject: [CMake] Question about eclipse
In-Reply-To: <CAAhJeqbyAZ5m6H_-8f7GR0OMFPxMG3ZH8yme9OkfLXWzeUpgTg@mail.gmail.com>
References: <CAAhJeqbyAZ5m6H_-8f7GR0OMFPxMG3ZH8yme9OkfLXWzeUpgTg@mail.gmail.com>
Message-ID: <4340395.DGFgj4hD56@linux>

On Donnerstag, 8. Februar 2018 02:42:13 CET jaeho jo wrote:
> Hi! I have a Question aboue eclipse.
> 
> I have a one C project in eclipse.
> 
> I have built this project only using eclipse so far.
> 
> I want to build thid C project using cmake
> 
>   Should I write the CMakeLists.txt file myself?? or Is there a way to set
> CMake build environment automatically?

You will have to do so. There is no generator for CMakeLists.txt in CDT.

> I can find many way to import existing cmake project to eclipse.
> 
> But, I can't find how to set cmake build configuration about existing
> eclipse C project easily

I wrote a plugin that works with normal C/C++ projects and invokes cmake for 
you. You will find it in the Eclipse Marketplace (cmake4eclipse).

As a start, you may check out the sample projects in <https://github.com/
15knots/cmake4eclipse-sample-projects.git>

Martin

-- 
Cd wrttn wtht vwls s mch trsr.



From amiblit at gmail.com  Sat Feb 10 12:53:22 2018
From: amiblit at gmail.com (AmigaBlitter)
Date: Sat, 10 Feb 2018 10:53:22 -0700 (MST)
Subject: [CMake] Problem compiling commander-genius (cross compiling)
In-Reply-To: <CAL2T-v68r5zA5JbrQnoyJWH0aNAqc+bB0rv4vwxCf5tK4HB03A@mail.gmail.com>
References: <1518166350717-0.post@n2.nabble.com>
 <CAL2T-v68r5zA5JbrQnoyJWH0aNAqc+bB0rv4vwxCf5tK4HB03A@mail.gmail.com>
Message-ID: <1518285202681-0.post@n2.nabble.com>

Thank you for the reply.

I tried using CMAKE_SYSROOT but i get this:

amidev at AMIGAONE:~/Software/Development/Commander-Genius$ cmake
-DCMAKE_TOOLCHAIN_FILE=amiga-toolchain.cmake -DUSE_SDL2=yes
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:6 (Project):
  The CMAKE_C_COMPILER:

    /usr/local/amiga/bin/ppc-amigaos-gcc.exe

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path
to
  the compiler, or to the compiler name if it is in the PATH.


CMake Error at CMakeLists.txt:6 (Project):
  The CMAKE_CXX_COMPILER:

    /usr/local/amiga/bin/ppc-amigaos-g++.exe

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full
path
  to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!

Moreover, don't know what's happened, but i'm sure that i haven't changed
anything since yesterday and, if previously compilation started till 90%,
now doesn't start at all.

Kind regards
Davide



--
Sent from: http://cmake.3232098.n2.nabble.com/

From eri0onpm at gmail.com  Sat Feb 10 14:02:19 2018
From: eri0onpm at gmail.com (Erico P)
Date: Sat, 10 Feb 2018 17:02:19 -0200
Subject: [CMake] Trying to build a software for Android that uses CMake
Message-ID: <CANT=srohpVuaDjCCJWa1LS5F-=VEeNmcZJqeNLpw9NCi-kTRJg@mail.gmail.com>

Hello,

I am trying to build the Adventure Game Studio engine for Android. It
depends on allegro-4.4.2.

Unfortunately, Allegro-4.4.2 is failing with errors for me:

    CMake Error at CMakeLists.txt:962 (get_target_property):
    get_target_property() called with non-existent target "allegrogl".


    CMake Error at CMakeLists.txt:962 (get_target_property):
    get_target_property() called with non-existent target "loadpng".


    CMake Error at CMakeLists.txt:962 (get_target_property):
    get_target_property() called with non-existent target "logg".


    CMake Error: The following variables are used in this project, but they
are set to NOTFOUND.
    Please set them or make sure they are set and tested correctly in the
CMake files:
    RT_LIBRARY
    linked by target "allegro" in directory
/home/erico/git/ags/Android/buildlibs/armeabi-v7a/allegro-4.4.2


I think the problem is CMake is not find these libraries, and I am not sure
what the variable RT_LIBRARY means.

I detailed what I did below:

http://www.adventuregamestudio.co.uk/forums/index.php?topic=44768.msg636580835#new

Getting the master branch of AGS to build for Android would be amazing. I
know the current branch won't actually work (we are missing some functions
in AGS part to work correctly), but right now I just want to build the
libraries and Allegro 4.4.2 is an important part of this process.

I am just looking if someone has seem these errors before or have a clue on
what is needed to do.

Thank you.

Regards,

?rico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180210/e7aa85e2/attachment.html>

From irwin at beluga.phys.uvic.ca  Sun Feb 11 04:26:00 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 11 Feb 2018 01:26:00 -0800 (PST)
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <CALBOmsYWAZX7ztkbiVYLe62QR=K2jy5Op1N1fk7AcVyJCLrnXA@mail.gmail.com>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802090149340.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37F87@V-EXC-C02.DIRECTORY.INTRA>
 <8CF085736108634681FD03EC36E6A0729DA37FC2@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802090914390.1805@enira.zlyna.ubzr>
 <CALBOmsYWAZX7ztkbiVYLe62QR=K2jy5Op1N1fk7AcVyJCLrnXA@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1802100920180.1805@enira.zlyna.ubzr>

On 2018-02-10 08:04+0100 Mojca Miklavec wrote:

> On 9 February 2018 at 18:24, Alan W. Irwin wrote:
>> On 2018-02-09 10:44-0000 Arjen Markus wrote:
>>
>>> Hi Alan,
>>>
>>> The result is the same or very much the same.
>>
>> OK.  Time for more knowledgable people to weigh in here about what
>> Platform filenames to use for the combination of nagfor and
>> MinGW-w64/MSYS2 for the "Unix Makefiles" and "MSYS Makefiles"
>> generators.
>>
>> Meanwhile, can you test whether the Platform filename I suggested for
>> the nagfor Cygwin case with "Unix Makefiles" generator is correct?
>>
>> Alan
>
> I wonder if this is in any way related to
>    https://cmake.org/Bug/view.php?id=14252

Hi Mojca:

Just to clarify there has been a change in the CMake bugtracker.  You
reference the old bug tracker entry where all issues there were
automatically closed and moved to the new bug tracker
<https://gitlab.kitware.com/cmake/cmake/issues/14252>. However, that
is an almost completely vacuous entry (except for title) in the new
bug tracker although it does declare the issue is still open. As far
as I can tell from that old discussion, Brad King found the hard-coded
source of your problem in the CMake code with -arch, but there is no
reference to a fix either in the old tracker or new one so I assume
that fix has not been implemented yet.

Furthermore, although there is a superficial resemblance I am pretty
sure from the description this hard-coded issue is quite specific to
certain compiler options, and does not refer to ignoring all nagfor
compiler options as Arjen has apparently observed. So I think the
source of Arjen's problem likely is that he is using the incorrect
Platform filenames for the various nagfor Windows cases that have been
discussed, and we need advice from a CMake language support expert to
help us figure out what those Platform filenames should be.

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
__________________________

From mario at emmenlauer.de  Sun Feb 11 09:13:14 2018
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Sun, 11 Feb 2018 15:13:14 +0100
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
Message-ID: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>


I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well,
but just recently I started to have problems with CMAKE_PREFIX_PATH.
Its possible that the problems have been there forever, but I now just
found them due to a better use of CI systems.

The problem is that cmake is not finding package configuration files
correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library
XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake
and XXXTargets.cmake (i.e. for Qt, VTK and others).

But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake
in Unix path style. It does work when I specify the package configuration
directory in Windows style! This makes things quite confusing, because many
find_xxx() commands for headers and libraries work with Unix paths. So now
I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but
add WINDESTDIR\lib\cmake for the package configuration files (*).

Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2
here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone
can comment?

All the best,

    Mario Emmenlauer


(*) UNIXDESTDIR is a shorthand of a path in Unix style, like /d/soft/
    WINDESTDIR is a shorthand of a path in Windows style, like D:\soft\


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 M?nchen                          http://www.biodataanalysis.de/

From irwin at beluga.phys.uvic.ca  Sun Feb 11 17:11:11 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 11 Feb 2018 14:11:11 -0800 (PST)
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
Message-ID: <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>

On 2018-02-11 15:13+0100 Mario Emmenlauer wrote:

>
> I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well,
> but just recently I started to have problems with CMAKE_PREFIX_PATH.
> Its possible that the problems have been there forever, but I now just
> found them due to a better use of CI systems.
>
> The problem is that cmake is not finding package configuration files
> correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library
> XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake
> and XXXTargets.cmake (i.e. for Qt, VTK and others).
>
> But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake
> in Unix path style. It does work when I specify the package configuration
> directory in Windows style! This makes things quite confusing, because many
> find_xxx() commands for headers and libraries work with Unix paths. So now
> I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but
> add WINDESTDIR\lib\cmake for the package configuration files (*).
>
> Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2
> here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone
> can comment?

Hi Mario:

>From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
what you said above it appears you are using the "native Windows"
cmake version from the mingw64 repository rather than the POSIX-style
cmake package you can install from the msys2 repository.  I am pretty
sure the native version would not do well with non-native POSIX-style
paths so I am not surprised by your results.  Anyhow, I suggest you
experiment with native versus POSIX cmake packages in both CMD and
bash (from msys2) environments to establish what the different results
are in those four cases for native Windows and POSIX paths.

Note I have no access to MinGW-w64/MSYS2 myself, but I do pay close
attention to this platform because it is the best Windows platform for
PLplot according to a fellow PLplot developer who does have a lot of
practical experience with this platform.

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
__________________________

From mario at emmenlauer.de  Mon Feb 12 03:32:01 2018
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Mon, 12 Feb 2018 09:32:01 +0100
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
 <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
Message-ID: <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>


Dear Alan,

thanks for your reply! Below more:

On 11.02.2018 23:11, Alan W. Irwin wrote:
> On 2018-02-11 15:13+0100 Mario Emmenlauer wrote:
> 
>>
>> I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well,
>> but just recently I started to have problems with CMAKE_PREFIX_PATH.
>> Its possible that the problems have been there forever, but I now just
>> found them due to a better use of CI systems.
>>
>> The problem is that cmake is not finding package configuration files
>> correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library
>> XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake
>> and XXXTargets.cmake (i.e. for Qt, VTK and others).
>>
>> But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake
>> in Unix path style. It does work when I specify the package configuration
>> directory in Windows style! This makes things quite confusing, because many
>> find_xxx() commands for headers and libraries work with Unix paths. So now
>> I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but
>> add WINDESTDIR\lib\cmake for the package configuration files (*).
>>
>> Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2
>> here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone
>> can comment?
> 
> Hi Mario:
> 
> From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
> what you said above it appears you are using the "native Windows"
> cmake version from the mingw64 repository rather than the POSIX-style
> cmake package you can install from the msys2 repository.? I am pretty

Hmm, I don't think I have a native Windows cmake installed. I installed
mingw-w64-*-cmake from pacman, and I do not find any other cmake.exe in
PATH or on the hard disk. At least when I do:

#> find /c/ /d/ -name cmake.exe 2>/dev/zero
/d/msys2/bda/mingw32/bin/cmake.exe
/d/msys2/bda/mingw64/bin/cmake.exe

I find only the native MSYS2 mingw-w64-x86_64-cmake / mingw-w64-xi686-cmake.

All the best,

   Mario



> sure the native version would not do well with non-native POSIX-style
> paths so I am not surprised by your results.? Anyhow, I suggest you
> experiment with native versus POSIX cmake packages in both CMD and
> bash (from msys2) environments to establish what the different results
> are in those four cases for native Windows and POSIX paths.
> 
> Note I have no access to MinGW-w64/MSYS2 myself, but I do pay close
> attention to this platform because it is the best Windows platform for
> PLplot according to a fellow PLplot developer who does have a lot of
> practical experience with this platform.
> 
> 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
> __________________________
> 



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 M?nchen                          http://www.biodataanalysis.de/

From marc.chevrier at sap.com  Mon Feb 12 03:40:52 2018
From: marc.chevrier at sap.com (CHEVRIER, Marc)
Date: Mon, 12 Feb 2018 08:40:52 +0000
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
 <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
 <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
Message-ID: <166FE741-4E05-460F-BA60-372AB4113ADD@sap.com>

Be aware that MSYS2 environment is a "dual" environment:
* Unix like environment. Executables are in <MSYS2_ROOT>/usr/bin
* Windows like (i.e. understand windows paths but with slashes rather than back-slashes). Executables are in <MSYS2_ROOT>/ mingw(64|32)/bin.

So, if you want a pure unix like usage, you have to install package 'msys/cmake'.
If you use tool in mingw(32|64)/bin (package 'mingw32/mingw-w64-i686-cmake' or ' mingw64/mingw-w64-x86_64-cmake'), use windows paths (ex: C:/DESTDIR/lib/cmake).


?On 12/02/2018 09:32, "CMake on behalf of Mario Emmenlauer" <cmake-bounces at cmake.org on behalf of mario at emmenlauer.de> wrote:

    
    Dear Alan,
    
    thanks for your reply! Below more:
    
    On 11.02.2018 23:11, Alan W. Irwin wrote:
    > On 2018-02-11 15:13+0100 Mario Emmenlauer wrote:
    > 
    >>
    >> I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well,
    >> but just recently I started to have problems with CMAKE_PREFIX_PATH.
    >> Its possible that the problems have been there forever, but I now just
    >> found them due to a better use of CI systems.
    >>
    >> The problem is that cmake is not finding package configuration files
    >> correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library
    >> XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake
    >> and XXXTargets.cmake (i.e. for Qt, VTK and others).
    >>
    >> But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake
    >> in Unix path style. It does work when I specify the package configuration
    >> directory in Windows style! This makes things quite confusing, because many
    >> find_xxx() commands for headers and libraries work with Unix paths. So now
    >> I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but
    >> add WINDESTDIR\lib\cmake for the package configuration files (*).
    >>
    >> Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2
    >> here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone
    >> can comment?
    > 
    > Hi Mario:
    > 
    > From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
    > what you said above it appears you are using the "native Windows"
    > cmake version from the mingw64 repository rather than the POSIX-style
    > cmake package you can install from the msys2 repository.  I am pretty
    
    Hmm, I don't think I have a native Windows cmake installed. I installed
    mingw-w64-*-cmake from pacman, and I do not find any other cmake.exe in
    PATH or on the hard disk. At least when I do:
    
    #> find /c/ /d/ -name cmake.exe 2>/dev/zero
    /d/msys2/bda/mingw32/bin/cmake.exe
    /d/msys2/bda/mingw64/bin/cmake.exe
    
    I find only the native MSYS2 mingw-w64-x86_64-cmake / mingw-w64-xi686-cmake.
    
    All the best,
    
       Mario
    
    
    
    > sure the native version would not do well with non-native POSIX-style
    > paths so I am not surprised by your results.  Anyhow, I suggest you
    > experiment with native versus POSIX cmake packages in both CMD and
    > bash (from msys2) environments to establish what the different results
    > are in those four cases for native Windows and POSIX paths.
    > 
    > Note I have no access to MinGW-w64/MSYS2 myself, but I do pay close
    > attention to this platform because it is the best Windows platform for
    > PLplot according to a fellow PLplot developer who does have a lot of
    > practical experience with this platform.
    > 
    > 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
    > __________________________
    > 
    
    
    
    Viele Gruesse,
    
        Mario Emmenlauer
    
    
    --
    BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
    Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
    D-81669 M?nchen                          http://www.biodataanalysis.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:
    https://cmake.org/mailman/listinfo/cmake
    


From mario at emmenlauer.de  Mon Feb 12 04:15:47 2018
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Mon, 12 Feb 2018 10:15:47 +0100
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <166FE741-4E05-460F-BA60-372AB4113ADD@sap.com>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
 <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
 <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
 <166FE741-4E05-460F-BA60-372AB4113ADD@sap.com>
Message-ID: <952610f1-7445-a349-457c-dc2d9c905617@emmenlauer.de>


Hi Marc,

On 12.02.2018 09:40, CHEVRIER, Marc wrote:
> Be aware that MSYS2 environment is a "dual" environment:
> * Unix like environment. Executables are in <MSYS2_ROOT>/usr/bin
> * Windows like (i.e. understand windows paths but with slashes rather than back-slashes). Executables are in <MSYS2_ROOT>/ mingw(64|32)/bin.
> 
> So, if you want a pure unix like usage, you have to install package 'msys/cmake'.
> If you use tool in mingw(32|64)/bin (package 'mingw32/mingw-w64-i686-cmake' or ' mingw64/mingw-w64-x86_64-cmake'), use windows paths (ex: C:/DESTDIR/lib/cmake).

This is an interesting thought! I see that many tools from mingw(32|64)/bin
accept both path styles, and about 90% of my build system uses pure Unix
style. This is the first time I encounter a problem. Its at least interesting
that cmake seems slightly inconsistent here: it accepts Unix style for
CMAKE_PREFIX_PATH when using find_xxx(), but no Unix style for detecting
package configuration files.

I see now that the problem is more likely on my side. But on the other hand,
it would be cool if cmake could consistently accept Unix style on MSYS2/MinGW
platforms. Would it be worthwhile to make this a cmake issue?

All the best,

   Mario



> 
> ?On 12/02/2018 09:32, "CMake on behalf of Mario Emmenlauer" <cmake-bounces at cmake.org on behalf of mario at emmenlauer.de> wrote:
> 
>     
>     Dear Alan,
>     
>     thanks for your reply! Below more:
>     
>     On 11.02.2018 23:11, Alan W. Irwin wrote:
>     > On 2018-02-11 15:13+0100 Mario Emmenlauer wrote:
>     > 
>     >>
>     >> I use mingw-w64-x86_64-cmake 3.10.2 on MSYS2. Generally it works well,
>     >> but just recently I started to have problems with CMAKE_PREFIX_PATH.
>     >> Its possible that the problems have been there forever, but I now just
>     >> found them due to a better use of CI systems.
>     >>
>     >> The problem is that cmake is not finding package configuration files
>     >> correctly. I have such files in DESTDIR/lib/cmake, i.e. for a library
>     >> XXX there are typically files XXXConfig.cmake, XXXConfigVersion.cmake
>     >> and XXXTargets.cmake (i.e. for Qt, VTK and others).
>     >>
>     >> But they are not found when I specify CMAKE_PREFIX_PATH=DESTDIR/lib/cmake
>     >> in Unix path style. It does work when I specify the package configuration
>     >> directory in Windows style! This makes things quite confusing, because many
>     >> find_xxx() commands for headers and libraries work with Unix paths. So now
>     >> I need to use CMAKE_PREFIX_PATH=UNIXDESTDIR for the normal find_xxx(), but
>     >> add WINDESTDIR\lib\cmake for the package configuration files (*).
>     >>
>     >> Is this an MSYS2 issue or a standard cmake issue? I reported it with MSYS2
>     >> here https://github.com/Alexpux/MINGW-packages/issues/3337 in case someone
>     >> can comment?
>     > 
>     > Hi Mario:
>     > 
>     > From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
>     > what you said above it appears you are using the "native Windows"
>     > cmake version from the mingw64 repository rather than the POSIX-style
>     > cmake package you can install from the msys2 repository.  I am pretty
>     
>     Hmm, I don't think I have a native Windows cmake installed. I installed
>     mingw-w64-*-cmake from pacman, and I do not find any other cmake.exe in
>     PATH or on the hard disk. At least when I do:
>     
>     #> find /c/ /d/ -name cmake.exe 2>/dev/zero
>     /d/msys2/bda/mingw32/bin/cmake.exe
>     /d/msys2/bda/mingw64/bin/cmake.exe
>     
>     I find only the native MSYS2 mingw-w64-x86_64-cmake / mingw-w64-xi686-cmake.
>     
>     All the best,
>     
>        Mario
>     
>     
>     
>     > sure the native version would not do well with non-native POSIX-style
>     > paths so I am not surprised by your results.  Anyhow, I suggest you
>     > experiment with native versus POSIX cmake packages in both CMD and
>     > bash (from msys2) environments to establish what the different results
>     > are in those four cases for native Windows and POSIX paths.
>     > 
>     > Note I have no access to MinGW-w64/MSYS2 myself, but I do pay close
>     > attention to this platform because it is the best Windows platform for
>     > PLplot according to a fellow PLplot developer who does have a lot of
>     > practical experience with this platform.
>     > 
>     > 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
>     > __________________________
>     > 
>     
>     
>     
>     Viele Gruesse,
>     
>         Mario Emmenlauer
>     
>     
>     --
>     BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
>     Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
>     D-81669 M?nchen                          http://www.biodataanalysis.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:
>     https://cmake.org/mailman/listinfo/cmake
>     
> 



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 M?nchen                          http://www.biodataanalysis.de/

From irwin at beluga.phys.uvic.ca  Mon Feb 12 04:23:23 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Mon, 12 Feb 2018 01:23:23 -0800 (PST)
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
 <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
 <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
Message-ID: <alpine.DEB.2.11.1802120102350.27133@enira.zlyna.ubzr>

On 2018-02-12 09:32+0100 Mario Emmenlauer wrote:

[...]
>> Hi Mario:
>>
>> From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
>> what you said above it appears you are using the "native Windows"
>> cmake version from the mingw64 repository rather than the POSIX-style
>> cmake package you can install from the msys2 repository.? I am pretty
>
> Hmm, I don't think I have a native Windows cmake installed.

As Marc said in his post, be aware of the dual nature of this
platform. One side (the mingw64 repository) supplies native Windows
packages while the other (the msys2 repository) supplies a much
smaller number of Unix-like packages.  CMake packages happen to be in
both repositories!

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
__________________________

From mario at emmenlauer.de  Mon Feb 12 07:06:56 2018
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Mon, 12 Feb 2018 13:06:56 +0100
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <alpine.DEB.2.11.1802120102350.27133@enira.zlyna.ubzr>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
 <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
 <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
 <alpine.DEB.2.11.1802120102350.27133@enira.zlyna.ubzr>
Message-ID: <98adacdf-9123-5fdb-2b78-777cb65a9910@emmenlauer.de>


Hi,

ok I agree it might be cleaner to use Windows-style paths for all
cmake parameters on MSYS2. I changed my CI and everything works! :-)

But just as a side comment: It would be super cool if cmake would
support both styles for all parameters. The typical use on MSYS2 for
many commands is with Unix paths, and its great that cmake already
supports this so nicely. It really made things easier for me!

If its not a huge effort it would be great to have the same behaviour
also for the package configs.

Cheers and thanks,

   Mario




On 12.02.2018 10:23, Alan W. Irwin wrote:
> On 2018-02-12 09:32+0100 Mario Emmenlauer wrote:
> 
> [...]
>>> Hi Mario:
>>>
>>> From <https://github.com/msys2/msys2/wiki/MSYS2-introduction>, and
>>> what you said above it appears you are using the "native Windows"
>>> cmake version from the mingw64 repository rather than the POSIX-style
>>> cmake package you can install from the msys2 repository.? I am pretty
>>
>> Hmm, I don't think I have a native Windows cmake installed.
> 
> As Marc said in his post, be aware of the dual nature of this
> platform. One side (the mingw64 repository) supplies native Windows
> packages while the other (the msys2 repository) supplies a much
> smaller number of Unix-like packages.? CMake packages happen to be in
> both repositories!
> 
> 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
> __________________________
> 



Viele Gruesse,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 M?nchen                          http://www.biodataanalysis.de/

From irwin at beluga.phys.uvic.ca  Mon Feb 12 16:09:20 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Mon, 12 Feb 2018 13:09:20 -0800 (PST)
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <98adacdf-9123-5fdb-2b78-777cb65a9910@emmenlauer.de>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
 <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
 <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
 <alpine.DEB.2.11.1802120102350.27133@enira.zlyna.ubzr>
 <98adacdf-9123-5fdb-2b78-777cb65a9910@emmenlauer.de>
Message-ID: <alpine.DEB.2.11.1802121150170.10563@enira.zlyna.ubzr>

On 2018-02-12 13:06+0100 Mario Emmenlauer wrote:

>
> Hi,
>
> ok I agree it might be cleaner to use Windows-style paths for all
> cmake parameters on MSYS2. I changed my CI and everything works! :-)
>
> But just as a side comment: It would be super cool if cmake would
> support both styles for all parameters. The typical use on MSYS2 for
> many commands is with Unix paths, and its great that cmake already
> supports this so nicely. It really made things easier for me!
>
> If its not a huge effort it would be great to have the same behaviour
> also for the package configs.

I am glad you have found a satisfactory solution for your needs, but I
would like to respond to your further side comment about the broader
picture.

I am virtually positive from reading
<https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other
MinGW-w64/MSYS2 documentation that the conversion from POSIX to native
PATHs is done by the MSYS2 dll.  Also, MinGW-w64/MSYS2 applications
from the msys2 repository are linked against that dll while the
applications from the mingw64 repository are pure native, i.e., not
linked against that dll.  Thus, if that mental model is correct, here
are some predictions that flow from it.

* The cmake version from the msys2 repository will understand cache
variables expressed as POSIX PATHs, but the cmake version from the
mingw64 repository wont have that capability.

* bash.exe (only available on MinGW-w64/MSYS2 from the msys2
repository for obvious reasons) will understand the POSIX version of
environment variables that represent PATHs.

* The combination of mingw64 cmake and bash will work for your
POSIX PATH needs if you are careful to use the bash environment variable
form of CMAKE_PREFIX_PATH rather than the cache variable
form of CMAKE_PREFIX_PATH.

I invite you to read the MinGW-w64/MSYS2 documentation to satisfy
yourself concerning that mental model.  And I also hope you do some
experiments to see whether the above predictions are correct.

By the way, I don't have access to Microsoft Windows myself but since
the MinGW-w64/MSYS2 platform is so important for PLplot I have tried
to get access to it via Wine-staging version of Windows just to help
my fellow PLplot developers with testing of MinGW-w64/MSYS2.
Unfortunately, the combination of MinGW-w64/MSYS2 and Wine-staging
that apparently worked a while ago no longer works at all, see
<https://github.com/TeaCI/tea-ci/wiki/Msys2-on-Wine>.  If you follow
the link there, apparently there is a lot of continuing interest in
getting this wine-staging bug fixed.  But while waiting for that, I am
in the frustrating position of only being able to make theoretical
predictions based on mental models as above rather than trying
MinGW-w64/MSYS2 for myself! Anyhow, if you get a chance to test out
some of the above predictions, I would be most interested in your
results.

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
__________________________

From mario at emmenlauer.de  Mon Feb 12 17:06:49 2018
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Mon, 12 Feb 2018 23:06:49 +0100
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <alpine.DEB.2.11.1802121150170.10563@enira.zlyna.ubzr>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
 <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
 <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
 <alpine.DEB.2.11.1802120102350.27133@enira.zlyna.ubzr>
 <98adacdf-9123-5fdb-2b78-777cb65a9910@emmenlauer.de>
 <alpine.DEB.2.11.1802121150170.10563@enira.zlyna.ubzr>
Message-ID: <77c5f1e1-4054-3efe-6ee8-20ef02832181@emmenlauer.de>


Dear Alan,

On 12.02.2018 22:09, Alan W. Irwin wrote:
> On 2018-02-12 13:06+0100 Mario Emmenlauer wrote:
> 
>>
>> Hi,
>>
>> ok I agree it might be cleaner to use Windows-style paths for all
>> cmake parameters on MSYS2. I changed my CI and everything works! :-)
>>
>> But just as a side comment: It would be super cool if cmake would
>> support both styles for all parameters. The typical use on MSYS2 for
>> many commands is with Unix paths, and its great that cmake already
>> supports this so nicely. It really made things easier for me!
>>
>> If its not a huge effort it would be great to have the same behaviour
>> also for the package configs.
> 
> I am glad you have found a satisfactory solution for your needs, but I
> would like to respond to your further side comment about the broader
> picture.
> 
> I am virtually positive from reading
> <https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other
> MinGW-w64/MSYS2 documentation that the conversion from POSIX to native
> PATHs is done by the MSYS2 dll.? Also, MinGW-w64/MSYS2 applications
> from the msys2 repository are linked against that dll while the
> applications from the mingw64 repository are pure native, i.e., not
> linked against that dll.? Thus, if that mental model is correct, here
> are some predictions that flow from it.
> 
> * The cmake version from the msys2 repository will understand cache
> variables expressed as POSIX PATHs, but the cmake version from the
> mingw64 repository wont have that capability.

I am not sure if I follow until here, but very likely I just misunderstand
what you are saying. Please help shed some light! In my observation, I
have cmake installed from mingw64 repository, and I can successfully use
this cmake with a CMAKE_PREFIX_PATH in POSIX PATH notation, as long as I
find all my dependencies with find_xxx() commands (i.e. find_library() or
find_file() or the like). I also use this same cmake with a path to the
source directory specified as POSIX PATH.

So to be 150% sure we mean the same, the following works for me, where
/d/ corresponds to the D: drive of Windows:
    /mingw64/bin/cmake /d/tmp/sources \
        -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
    make && make install

Is that contradictory to your point above?

Cheers,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 M?nchen                          http://www.biodataanalysis.de/

From irwin at beluga.phys.uvic.ca  Mon Feb 12 19:08:49 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Mon, 12 Feb 2018 16:08:49 -0800 (PST)
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <77c5f1e1-4054-3efe-6ee8-20ef02832181@emmenlauer.de>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
 <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
 <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
 <alpine.DEB.2.11.1802120102350.27133@enira.zlyna.ubzr>
 <98adacdf-9123-5fdb-2b78-777cb65a9910@emmenlauer.de>
 <alpine.DEB.2.11.1802121150170.10563@enira.zlyna.ubzr>
 <77c5f1e1-4054-3efe-6ee8-20ef02832181@emmenlauer.de>
Message-ID: <alpine.DEB.2.11.1802121532070.10563@enira.zlyna.ubzr>

On 2018-02-12 23:06+0100 Mario Emmenlauer wrote:

> On 12.02.2018 22:09, Alan W. Irwin wrote:
[...]
>> I am virtually positive from reading
>> <https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other
>> MinGW-w64/MSYS2 documentation that the conversion from POSIX to native
>> PATHs is done by the MSYS2 dll.? Also, MinGW-w64/MSYS2 applications
>> from the msys2 repository are linked against that dll while the
>> applications from the mingw64 repository are pure native, i.e., not
>> linked against that dll.? Thus, if that mental model is correct, here
>> are some predictions that flow from it.
>>
>> * The cmake version from the msys2 repository will understand cache
>> variables expressed as POSIX PATHs, but the cmake version from the
>> mingw64 repository wont have that capability.
>
> I am not sure if I follow until here, but very likely I just misunderstand
> what you are saying. Please help shed some light!

I will try.  :-)

> In my observation, I
> have cmake installed from mingw64 repository, and I can successfully use
> this cmake with a CMAKE_PREFIX_PATH in POSIX PATH notation
> find all my dependencies with find_xxx() commands (i.e. find_library() or
> find_file() or the like). I also use this same cmake with a path to the
> source directory specified as POSIX PATH.
>
> So to be 150% sure we mean the same, the following works for me, where
> /d/ corresponds to the D: drive of Windows:
>    /mingw64/bin/cmake /d/tmp/sources \
>        -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
>    make && make install
>
> Is that contradictory to your point above?

It certainly contradicts one of my predictions.

Just to clarify, the environment variable form of the above command
would have been (assuming your command-line environment is bash.exe
from the msys2 repository of MinGW-w64/MSYS2)

export CMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries"
/mingw64/bin/cmake /d/tmp/sources && make && make install

But instead, of using that environment variable form of the
command you used the
-DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries"
cmake option which sets CMAKE_PREFIX_PATH as a cache variable.

And for that cache variable approach, my prediction was the mingw64
version of cmake would not work with the above POSIX form of
CMAKE_PREFIX_PATH, but your experience is it does work!  So that
contradiction to the prediction is indeed an interesting result.

Just to cover off one possibility, could you try the bash printenv
command to print out all your bash environment variables to make sure
you have not inadvertently set the environment variable form of
CMAKE_PREFIX_PATH?  Of course, if you confirm this way that
CMAKE_PREFIX_PATH is not set as an environment variable, then it is
pretty clear something is incorrect/incomplete about the above mental
model.

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
__________________________

From jm3689 at columbia.edu  Tue Feb 13 08:38:24 2018
From: jm3689 at columbia.edu (ThePhD)
Date: Tue, 13 Feb 2018 08:38:24 -0500
Subject: [CMake] Visual C++ Compile/Link Flags
Message-ID: <CANNiNqK3KUhauNeNdPDQm-PUqBntd-Jou9_Pb=g+_NBSwQRQXg@mail.gmail.com>

I have a project where I attempt to add linker flags to a Visual Studio
project using

     target_link_libraries(lib_target PRIVATE /OPT:NOREF)

But it seems like the `/` syntax automatically has CMake assuming that the
flag is a file, and it complains it cannot find the file. Is there any way
to have CMake recognize a passed-in linker flag using this syntax? As a
side note, is there perhaps a better way of passing in Linker flags that I
am not aware of? Documentation stated that using "target_link_libraries" is
preferred, and I did not find "target_link_options".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180213/5f12bf48/attachment.html>

From jan.svitok at gmail.com  Tue Feb 13 09:14:08 2018
From: jan.svitok at gmail.com (Jano Svitok)
Date: Tue, 13 Feb 2018 15:14:08 +0100
Subject: [CMake] Visual C++ Compile/Link Flags
In-Reply-To: <CANNiNqK3KUhauNeNdPDQm-PUqBntd-Jou9_Pb=g+_NBSwQRQXg@mail.gmail.com>
References: <CANNiNqK3KUhauNeNdPDQm-PUqBntd-Jou9_Pb=g+_NBSwQRQXg@mail.gmail.com>
Message-ID: <CAN2u-c5bU6jLcuRwkYJ18+VmB6nN6sKjEoNquxPkYjSGZf0qCg@mail.gmail.com>

On Tue, Feb 13, 2018 at 2:38 PM, ThePhD <jm3689 at columbia.edu> wrote:

> I have a project where I attempt to add linker flags to a Visual Studio
> project using
>
>      target_link_libraries(lib_target PRIVATE /OPT:NOREF)
>
> But it seems like the `/` syntax automatically has CMake assuming that the
> flag is a file, and it complains it cannot find the file. Is there any way
> to have CMake recognize a passed-in linker flag using this syntax? As a
> side note, is there perhaps a better way of passing in Linker flags that I
> am not aware of? Documentation stated that using "target_link_libraries" is
> preferred, and I did not find "target_link_options".
>

You can try this; I don't know if this is the preferred way to do it.

set_property( TARGET lib_target APPEND_STRING PROPERTY LINK_FLAGS "
/OPT:NOREF" )

Jano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180213/9b0228a9/attachment.html>

From mario at emmenlauer.de  Tue Feb 13 09:22:02 2018
From: mario at emmenlauer.de (Mario Emmenlauer)
Date: Tue, 13 Feb 2018 15:22:02 +0100
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <alpine.DEB.2.11.1802121532070.10563@enira.zlyna.ubzr>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
 <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
 <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
 <alpine.DEB.2.11.1802120102350.27133@enira.zlyna.ubzr>
 <98adacdf-9123-5fdb-2b78-777cb65a9910@emmenlauer.de>
 <alpine.DEB.2.11.1802121150170.10563@enira.zlyna.ubzr>
 <77c5f1e1-4054-3efe-6ee8-20ef02832181@emmenlauer.de>
 <alpine.DEB.2.11.1802121532070.10563@enira.zlyna.ubzr>
Message-ID: <dad7e4e6-ff7f-2376-1f90-dda8e670ed61@emmenlauer.de>

On 13.02.2018 01:08, Alan W. Irwin wrote:
> On 2018-02-12 23:06+0100 Mario Emmenlauer wrote:
> 
>> On 12.02.2018 22:09, Alan W. Irwin wrote:
> [...]
>>> I am virtually positive from reading
>>> <https://github.com/msys2/msys2/wiki/MSYS2-introduction> and other
>>> MinGW-w64/MSYS2 documentation that the conversion from POSIX to native
>>> PATHs is done by the MSYS2 dll.? Also, MinGW-w64/MSYS2 applications
>>> from the msys2 repository are linked against that dll while the
>>> applications from the mingw64 repository are pure native, i.e., not
>>> linked against that dll.? Thus, if that mental model is correct, here
>>> are some predictions that flow from it.
>>>
>>> * The cmake version from the msys2 repository will understand cache
>>> variables expressed as POSIX PATHs, but the cmake version from the
>>> mingw64 repository wont have that capability.
>>
>> I am not sure if I follow until here, but very likely I just misunderstand
>> what you are saying. Please help shed some light!
> 
> I will try.? :-)
> 
>> In my observation, I
>> have cmake installed from mingw64 repository, and I can successfully use
>> this cmake with a CMAKE_PREFIX_PATH in POSIX PATH notation
>> find all my dependencies with find_xxx() commands (i.e. find_library() or
>> find_file() or the like). I also use this same cmake with a path to the
>> source directory specified as POSIX PATH.
>>
>> So to be 150% sure we mean the same, the following works for me, where
>> /d/ corresponds to the D: drive of Windows:
>> ?? /mingw64/bin/cmake /d/tmp/sources \
>> ?????? -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
>> ?? make && make install
>>
>> Is that contradictory to your point above?
> 
> It certainly contradicts one of my predictions.
> 
> Just to clarify, the environment variable form of the above command
> would have been (assuming your command-line environment is bash.exe
> from the msys2 repository of MinGW-w64/MSYS2)
> 
> export CMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries"
> /mingw64/bin/cmake /d/tmp/sources && make && make install
> 
> But instead, of using that environment variable form of the
> command you used the
> -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries"
> cmake option which sets CMAKE_PREFIX_PATH as a cache variable.
> 
> And for that cache variable approach, my prediction was the mingw64
> version of cmake would not work with the above POSIX form of
> CMAKE_PREFIX_PATH, but your experience is it does work!? So that
> contradiction to the prediction is indeed an interesting result.
> 
> Just to cover off one possibility, could you try the bash printenv
> command to print out all your bash environment variables to make sure
> you have not inadvertently set the environment variable form of
> CMAKE_PREFIX_PATH?? Of course, if you confirm this way that
> CMAKE_PREFIX_PATH is not set as an environment variable, then it is
> pretty clear something is incorrect/incomplete about the above mental
> model.
I'm 99% certain that this variable is not defined, because I build
from a standard Cygwin shell started from a gitlab runner. But there
might be another piece of evidence that can help us further. When I
build as outlined above (here for reference):

    /mingw64/bin/cmake /d/tmp/sources \
        -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
    make && make install

then the find_xxx() commands will work, but the cmake package
configurations fail. To get them also to work, I can switch to
Windows path styles:

    /mingw64/bin/cmake /d/tmp/sources \
        -DCMAKE_PREFIX_PATH="D:\\dest\\thirdparty;D:\\dest\\binaries" && \
    make && make install

then *everything* will work. So this should clarify that my POSIX path
was not automatically translated before, otherwise both invocations
would be identical, and the cmake package configurations should still
fail.

PS: Note that the source directory is *still* in POSIX path notation :-)

So its my understanding that cmake does have quite ok support for
POSIX paths on Windows, except for the cmake package configurations.

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 M?nchen                          http://www.biodataanalysis.de/

From volker.enderlein at ifm-chemnitz.de  Tue Feb 13 09:11:42 2018
From: volker.enderlein at ifm-chemnitz.de (Volker Enderlein)
Date: Tue, 13 Feb 2018 15:11:42 +0100
Subject: [CMake] Visual C++ Compile/Link Flags
In-Reply-To: <CANNiNqK3KUhauNeNdPDQm-PUqBntd-Jou9_Pb=g+_NBSwQRQXg@mail.gmail.com>
References: <CANNiNqK3KUhauNeNdPDQm-PUqBntd-Jou9_Pb=g+_NBSwQRQXg@mail.gmail.com>
Message-ID: <d944e1d0-cf2c-8d46-60e1-05e2ca9ca943@ifm-chemnitz.de>


set_target_properties(target PROPERTIES LINK_FLAGS "/OPT:NOREF") should 
work.

Am 13/02/2018 um 14:38 schrieb ThePhD:
> I have a project where I attempt to add linker flags to a Visual 
> Studio project using
>
> ???? target_link_libraries(lib_target PRIVATE /OPT:NOREF)
>
> But it seems like the `/` syntax automatically has CMake assuming that 
> the flag is a file, and it complains it cannot find the file. Is there 
> any way to have CMake recognize a passed-in linker flag using this 
> syntax? As a side note, is there perhaps a better way of passing in 
> Linker flags that I am not aware of? Documentation stated that using 
> "target_link_libraries" is preferred, and I did not find 
> "target_link_options".
>
-- 


From brad.king at kitware.com  Tue Feb 13 12:32:27 2018
From: brad.king at kitware.com (Brad King)
Date: Tue, 13 Feb 2018 12:32:27 -0500
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
Message-ID: <5A83212B.8020301@kitware.com>

On 2/9/2018 2:36 AM, Arjen Markus wrote:
> From: Alan W. Irwin
>> I suggest you try the names CYGWIN-NAG-Fortran.cmake and
>> Windows-NAG-Fortran.cmake for the two separate Platform
>> files you are trying to create for the Cygwin and
>> MinGW-w64/MSYS2 platforms.

I think those names are correct.  However, the status of CMake
for MSYS2-native builds is unclear.  See below.

> I have a Platform file ?Windows-NAG-Fortran.cmake? and that is used
> correctly if I start the NAG Fortran environment (using the MinGW
> Makefiles generator)

Good.

> but if I try the same with MinGWw-w64/MSYS2, this file is clearly ignored

What is the value of CMAKE_SYSTEM_NAME that is detected?

Typically this should be "Windows" for a Windows-native CMake
and "CYGWIN" for a cygwin-built CMake that is linked against the
cygwin runtime library.

For MSYS2 what CMake are you running?  A Windows CMake or one
that came packaged by MSYS2?  Does the latter link against the
msys2 runtime library?

-Brad

From jm3689 at columbia.edu  Tue Feb 13 13:09:33 2018
From: jm3689 at columbia.edu (ThePhD)
Date: Tue, 13 Feb 2018 13:09:33 -0500
Subject: [CMake] Visual C++ Compile/Link Flags
In-Reply-To: <d944e1d0-cf2c-8d46-60e1-05e2ca9ca943@ifm-chemnitz.de>
References: <CANNiNqK3KUhauNeNdPDQm-PUqBntd-Jou9_Pb=g+_NBSwQRQXg@mail.gmail.com>
 <d944e1d0-cf2c-8d46-60e1-05e2ca9ca943@ifm-chemnitz.de>
Message-ID: <CANNiNqLUT5vtdTktgRngBH6tn6PhBj+5Y_rNHzq=oo=u3uKoTQ@mail.gmail.com>

Thank you, Jano Svitok and Volker Enderlein.

     I settled for using "set_target_properties( ... )", and to specify
multiple LINK_FLAGS I encapsulated both arguments I wanted to pass in a
single set of quotes (with a space between them). I suppose the
APPEND_STRING approach could also work well, if I wanted to add multiple.

I appreciate the help!

On Tue, Feb 13, 2018 at 9:11 AM, Volker Enderlein <
volker.enderlein at ifm-chemnitz.de> wrote:

>
> set_target_properties(target PROPERTIES LINK_FLAGS "/OPT:NOREF") should
> work.
>
>
> Am 13/02/2018 um 14:38 schrieb ThePhD:
>
>> I have a project where I attempt to add linker flags to a Visual Studio
>> project using
>>
>>      target_link_libraries(lib_target PRIVATE /OPT:NOREF)
>>
>> But it seems like the `/` syntax automatically has CMake assuming that
>> the flag is a file, and it complains it cannot find the file. Is there any
>> way to have CMake recognize a passed-in linker flag using this syntax? As a
>> side note, is there perhaps a better way of passing in Linker flags that I
>> am not aware of? Documentation stated that using "target_link_libraries" is
>> preferred, and I did not find "target_link_options".
>>
>> --
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180213/2274ffa5/attachment.html>

From irwin at beluga.phys.uvic.ca  Tue Feb 13 14:29:43 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Tue, 13 Feb 2018 11:29:43 -0800 (PST)
Subject: [CMake] MSYS2 broken CMAKE_PREFIX_PATH
In-Reply-To: <dad7e4e6-ff7f-2376-1f90-dda8e670ed61@emmenlauer.de>
References: <1f20239e-2f0e-af82-e1ed-94e55a404934@emmenlauer.de>
 <alpine.DEB.2.11.1802111329540.27133@enira.zlyna.ubzr>
 <b341f722-1227-6af8-861d-4c71048dad66@emmenlauer.de>
 <alpine.DEB.2.11.1802120102350.27133@enira.zlyna.ubzr>
 <98adacdf-9123-5fdb-2b78-777cb65a9910@emmenlauer.de>
 <alpine.DEB.2.11.1802121150170.10563@enira.zlyna.ubzr>
 <77c5f1e1-4054-3efe-6ee8-20ef02832181@emmenlauer.de>
 <alpine.DEB.2.11.1802121532070.10563@enira.zlyna.ubzr>
 <dad7e4e6-ff7f-2376-1f90-dda8e670ed61@emmenlauer.de>
Message-ID: <alpine.DEB.2.11.1802131113310.10563@enira.zlyna.ubzr>

On 2018-02-13 15:22+0100 Mario Emmenlauer wrote:

> I'm 99% certain that this variable [the CMAKE_PREFIX_PATH
environment variable] is not defined, because I build
> from a standard Cygwin shell started from a gitlab runner. But there
> might be another piece of evidence that can help us further. When I
> build as outlined above (here for reference):
>
>    /mingw64/bin/cmake /d/tmp/sources \
>        -DCMAKE_PREFIX_PATH="/d/dest/thirdparty;/d/dest/binaries" && \
>    make && make install
>
> then the find_xxx() commands will work, but the cmake package
> configurations fail. To get them also to work, I can switch to
> Windows path styles:
>
>    /mingw64/bin/cmake /d/tmp/sources \
>        -DCMAKE_PREFIX_PATH="D:\\dest\\thirdparty;D:\\dest\\binaries" && \
>    make && make install
>
> then *everything* will work. So this should clarify that my POSIX path
> was not automatically translated before, otherwise both invocations
> would be identical, and the cmake package configurations should still
> fail.
>
> PS: Note that the source directory is *still* in POSIX path notation :-)

Hi Mario:

My understanding is that POSIX-style CMAKE PATH variables must be
colon-delimited.  So what does your CMakeCache.txt file say about
CMAKE_PREFIX_PATH with the semicolon delimiter you used above in your
first (POSIX) variant, and just as an experiment what happens with
that cache file and also your results with that first version if you
change the semicolon to a colon, i.e.,

     /mingw64/bin/cmake /d/tmp/sources \
         -DCMAKE_PREFIX_PATH="/d/dest/thirdparty:/d/dest/binaries" && \
     make && make install

?

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
__________________________

From irwin at beluga.phys.uvic.ca  Tue Feb 13 14:50:25 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Tue, 13 Feb 2018 11:50:25 -0800 (PST)
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <5A83212B.8020301@kitware.com>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
 <5A83212B.8020301@kitware.com>
Message-ID: <alpine.DEB.2.11.1802131144130.10563@enira.zlyna.ubzr>

On 2018-02-13 12:32-0500 Brad King wrote:

> On 2/9/2018 2:36 AM, Arjen Markus wrote:
>> From: Alan W. Irwin
>>> I suggest you try the names CYGWIN-NAG-Fortran.cmake and
>>> Windows-NAG-Fortran.cmake for the two separate Platform
>>> files you are trying to create for the Cygwin and
>>> MinGW-w64/MSYS2 platforms.
>
> I think those names are correct.  However, the status of CMake
> for MSYS2-native builds is unclear.  See below.
>
>> I have a Platform file ?Windows-NAG-Fortran.cmake? and that is used
>> correctly if I start the NAG Fortran environment (using the MinGW
>> Makefiles generator)
>
> Good.
>
>> but if I try the same with MinGWw-w64/MSYS2, this file is clearly ignored
>
> What is the value of CMAKE_SYSTEM_NAME that is detected?
>
> Typically this should be "Windows" for a Windows-native CMake
> and "CYGWIN" for a cygwin-built CMake that is linked against the
> cygwin runtime library.
>
> For MSYS2 what CMake are you running?  A Windows CMake or one
> that came packaged by MSYS2?  Does the latter link against the
> msys2 runtime library?

While waiting for Arjen to respond from his European time zone to that
question, which cmake package for MinGW-w64/MSYS2 do you usually
recommend?  The cmake package from the mingw64 repository or the cmake
package from the msys2 repository?

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
__________________________

From brad.king at kitware.com  Tue Feb 13 14:56:03 2018
From: brad.king at kitware.com (Brad King)
Date: Tue, 13 Feb 2018 14:56:03 -0500
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <alpine.DEB.2.11.1802131144130.10563@enira.zlyna.ubzr>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
 <5A83212B.8020301@kitware.com>
 <alpine.DEB.2.11.1802131144130.10563@enira.zlyna.ubzr>
Message-ID: <5A8342D3.1080809@kitware.com>

On 2/13/2018 2:50 PM, Alan W. Irwin wrote:
> While waiting for Arjen to respond from his European time zone to that
> question, which cmake package for MinGW-w64/MSYS2 do you usually
> recommend?  The cmake package from the mingw64 repository or the cmake
> package from the msys2 repository?

I'm not familiar with either of those.  What does each report as
CMAKE_HOST_SYSTEM_NAME?

-Brad

From irwin at beluga.phys.uvic.ca  Tue Feb 13 17:55:06 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Tue, 13 Feb 2018 14:55:06 -0800 (PST)
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <5A8342D3.1080809@kitware.com>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
 <5A83212B.8020301@kitware.com>
 <alpine.DEB.2.11.1802131144130.10563@enira.zlyna.ubzr>
 <5A8342D3.1080809@kitware.com>
Message-ID: <alpine.DEB.2.11.1802131433410.10563@enira.zlyna.ubzr>

On 2018-02-13 14:56-0500 Brad King wrote:

> On 2/13/2018 2:50 PM, Alan W. Irwin wrote:
>> While waiting for Arjen to respond from his European time zone to that
>> question, which cmake package for MinGW-w64/MSYS2 do you usually
>> recommend?  The cmake package from the mingw64 repository or the cmake
>> package from the msys2 repository?
>
> I'm not familiar with either of those.  What does each report as
> CMAKE_HOST_SYSTEM_NAME?

In general, you get native packages from the mingw64 repository and
POSIX-aware packages from the msys2 repository for this dual-natured
platform, and cmake is one of those rare beasts that has a package
in each repo.

@Arjen: to answer Brad's questions you should modify our top-level
CMakeLists.txt to also report CMAKE_HOST_SYSTEM_NAME (just in case
that is not the same as CMAKE_SYSTEM_NAME which we already report
there).  I assume from the CMakeCache.txt file you included in your
August comprehensive test report for this platform that you are still
running $PREFIX/mingw64/bin/cmake.exe, i.e., the version of cmake from
the mingw64 repository.  So just configuring PLplot on that platform
should give you the mingw64 answer to Brad's questions.  And to get
the msys2 answer you will need to temporarily move
$PREFIX/mingw64/bin/cmake.exe out of the way, install the POSIX
version of cmake from the msys2 repo, and configure PLplot from
scratch again using the msys2 version of cmake.

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
__________________________

From smeenai at fb.com  Tue Feb 13 22:02:09 2018
From: smeenai at fb.com (Shoaib Meenai)
Date: Wed, 14 Feb 2018 03:02:09 +0000
Subject: [CMake] Visual C++ Compile/Link Flags
In-Reply-To: <CANNiNqLUT5vtdTktgRngBH6tn6PhBj+5Y_rNHzq=oo=u3uKoTQ@mail.gmail.com>
References: <CANNiNqK3KUhauNeNdPDQm-PUqBntd-Jou9_Pb=g+_NBSwQRQXg@mail.gmail.com>
 <d944e1d0-cf2c-8d46-60e1-05e2ca9ca943@ifm-chemnitz.de>
 <CANNiNqLUT5vtdTktgRngBH6tn6PhBj+5Y_rNHzq=oo=u3uKoTQ@mail.gmail.com>
Message-ID: <6009A406-B245-4BD2-9946-604A14002F79@fb.com>

Visual Studio's linker (and compiler, for that matter) also accept flags that start with dashes instead of slashes (e.g. you can do -opt:noref instead of /opt:noref).

From: CMake <cmake-bounces at cmake.org> on behalf of ThePhD <jm3689 at columbia.edu>
Date: Tuesday, February 13, 2018 at 1:10 PM
To: "cmake at cmake.org" <cmake at cmake.org>
Subject: Re: [CMake] Visual C++ Compile/Link Flags

Thank you, Jano Svitok and Volker Enderlein.
     I settled for using "set_target_properties( ... )", and to specify multiple LINK_FLAGS I encapsulated both arguments I wanted to pass in a single set of quotes (with a space between them). I suppose the APPEND_STRING approach could also work well, if I wanted to add multiple.

I appreciate the help!

On Tue, Feb 13, 2018 at 9:11 AM, Volker Enderlein <volker.enderlein at ifm-chemnitz.de<mailto:volker.enderlein at ifm-chemnitz.de>> wrote:

set_target_properties(target PROPERTIES LINK_FLAGS "/OPT:NOREF") should work.


Am 13/02/2018 um 14:38 schrieb ThePhD:
I have a project where I attempt to add linker flags to a Visual Studio project using

     target_link_libraries(lib_target PRIVATE /OPT:NOREF)

But it seems like the `/` syntax automatically has CMake assuming that the flag is a file, and it complains it cannot find the file. Is there any way to have CMake recognize a passed-in linker flag using this syntax? As a side note, is there perhaps a better way of passing in Linker flags that I am not aware of? Documentation stated that using "target_link_libraries" is preferred, and I did not find "target_link_options".
--

--

Powered by www.kitware.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=TuF6_dXoirMgs8pxfwOLK76T87AEraphOyvzaCdHZDA&s=H8XZFlDlKPXDJs6Txl7iKXVMfqMldGD1SOfjhCgMNyc&e=>

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=TuF6_dXoirMgs8pxfwOLK76T87AEraphOyvzaCdHZDA&s=V3vhi-FAUPQb9zCOzs1Swgy5y6eYcLq5cbmbZYqiwTM&e=>

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=TuF6_dXoirMgs8pxfwOLK76T87AEraphOyvzaCdHZDA&s=EyOfGRsbaZJy5-cWrLYXm1PHaZFXQndTGdI1LHiETMc&e=>
CMake Consulting: http://cmake.org/cmake/help/consulting.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=TuF6_dXoirMgs8pxfwOLK76T87AEraphOyvzaCdHZDA&s=gRunwWAHwI2E_hwYQuKRN9zyZc24IcA19T6gjJsv9ck&e=>
CMake Training Courses: http://cmake.org/cmake/help/training.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=TuF6_dXoirMgs8pxfwOLK76T87AEraphOyvzaCdHZDA&s=BnZouoLQlKBiCjmNJXqVDrGqG0J54OFJJc6ldsN1rBY&e=>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=TuF6_dXoirMgs8pxfwOLK76T87AEraphOyvzaCdHZDA&s=SM1OvUqw0STN8RIdtrtd6NPzl-ct4kDSVpCqvL_aXAM&e=>

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake<https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=TuF6_dXoirMgs8pxfwOLK76T87AEraphOyvzaCdHZDA&s=s1Qwtnjz3QEPaTSNIgF2f2q1AopU7YrCX0MmXaP5X0Q&e=>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180214/5bb7e0f4/attachment.html>

From julien.jomier at kitware.com  Wed Feb 14 02:32:57 2018
From: julien.jomier at kitware.com (Julien Jomier)
Date: Wed, 14 Feb 2018 08:32:57 +0100
Subject: [CMake] [ANN] CMake Training Course in France - March 12
Message-ID: <e3c06bb6-c4af-a83c-819d-d70b2d033389@kitware.com>

Kitware will be holding a CMake training course on March 12, 2018 in 
Lyon, France. This one-day course will cover the best practice for 
CMake, CTest, CPack and CDash.

Please visit our website for more information and registration details:

     https://training.kitware.fr/browse/170

Note that the course will be taught in English. If you have any
questions, please contact us at training at kitware.fr or email me directly.

We are looking forward to seeing you in Lyon,
Julien
-- 
Kitware SAS
26 rue Louis Gu?rin
69100 Villeurbanne, France
http://www.kitware.eu

From Arjen.Markus at deltares.nl  Wed Feb 14 03:16:36 2018
From: Arjen.Markus at deltares.nl (Arjen Markus)
Date: Wed, 14 Feb 2018 08:16:36 +0000
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <alpine.DEB.2.11.1802131433410.10563@enira.zlyna.ubzr>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
 <5A83212B.8020301@kitware.com>
 <alpine.DEB.2.11.1802131144130.10563@enira.zlyna.ubzr>
 <5A8342D3.1080809@kitware.com>
 <alpine.DEB.2.11.1802131433410.10563@enira.zlyna.ubzr>
Message-ID: <8CF085736108634681FD03EC36E6A0729DA3BB4E@V-EXC-C02.DIRECTORY.INTRA>

Hi Brad, Alan,



See below.

> -----Original Message-----
> From: Alan W. Irwin [mailto:irwin at beluga.phys.uvic.ca]
> Sent: Tuesday, February 13, 2018 11:55 PM
>
> In general, you get native packages from the mingw64 repository and POSIX-aware
> packages from the msys2 repository for this dual-natured platform, and cmake is
> one of those rare beasts that has a package in each repo.
>
Yes, I have both - one in $PREFIX/mingw64/bin and one in $PREFIX/usr/bin. The latter is the MSYS2 version.

> @Arjen: to answer Brad's questions you should modify our top-level CMakeLists.txt
> to also report CMAKE_HOST_SYSTEM_NAME (just in case that is not the same
> as CMAKE_SYSTEM_NAME which we already report there).  >


The MinGW version of Cmake reports Windows for both variables and the MSYS2 version reports MSYS.

I set CC and FC to x64cc and nagfor respectively before invoking CMake (either version), so that the proper tools are used. However, the problem is that sometimes the configuration fails, sometimes the build fails. There is very little information about what is going wrong. Or there is a lot I simply fail to find the wanted needle in that haystack.

I have also had a situation where the Freetype library was recognised but the build failed on a bunch of unresolved externals.

Further complication: my trial licence for NAG Fortran ends today :(.

So, the exercise up to now has brought us a nice way to use NAG Fortran in its native environment, but without the benefit of installed packages under MinGW-w64/MSYS2.

The number of combinations to try is also rather big, I am afraid. That would require a lot more trial and error, if no pruning is possible.

Regards,

Arjen

DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180214/bad8bd71/attachment-0001.html>

From brad.king at kitware.com  Wed Feb 14 09:40:46 2018
From: brad.king at kitware.com (Brad King)
Date: Wed, 14 Feb 2018 09:40:46 -0500
Subject: [CMake] MinGW-w64/MSYS2 (or Cygwin) and NAG Fortran - how to
 combine?
In-Reply-To: <8CF085736108634681FD03EC36E6A0729DA3BB4E@V-EXC-C02.DIRECTORY.INTRA>
References: <8CF085736108634681FD03EC36E6A0729DA378B6@V-EXC-C02.DIRECTORY.INTRA>
 <alpine.DEB.2.11.1802081330170.1805@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA37D6D@V-EXC-C02.DIRECTORY.INTRA>
 <5A83212B.8020301@kitware.com>
 <alpine.DEB.2.11.1802131144130.10563@enira.zlyna.ubzr>
 <5A8342D3.1080809@kitware.com>
 <alpine.DEB.2.11.1802131433410.10563@enira.zlyna.ubzr>
 <8CF085736108634681FD03EC36E6A0729DA3BB4E@V-EXC-C02.DIRECTORY.INTRA>
Message-ID: <5A844A6E.5060909@kitware.com>

On 2/14/2018 3:16 AM, Arjen Markus wrote:
> The MinGW version of Cmake reports Windows for both variables

Great, that's expected.  Then Windows-NAG-Fortran would be the proper
module for flags for a compiler targeting a Windows environment.

> and the MSYS2 version reports MSYS.

If CMAKE_SYSTEM_NAME is "MSYS" then likely all the `CYGWIN-*`
modules should become `MSYS-*` modules.

-Brad

From kim.walisch at gmail.com  Wed Feb 14 10:21:59 2018
From: kim.walisch at gmail.com (Kim Walisch)
Date: Wed, 14 Feb 2018 16:21:59 +0100
Subject: [CMake] Config.cmake.in: Conditionally serve static or shared
 library
Message-ID: <CAE_DJ11=v9Y-EXOcB+ff+q3=FCpYncQqKLKy+TOyr88oUK=XhQ@mail.gmail.com>

Hi,

My primesieve project builds as both a static and a shared library, hence
there are 2 targets in my main CMakeLists.txt:

1) libprimesieve (shared library)
2) libprimesieve-static

I am now trying to add support for find_package(Primesieve). Ideally I
would like that users can link against libprimesieve as follows:

find_package(Primesieve REQUIRED)
target_link_libraries(user_library Primesieve::Primesieve)

And I want Primesieve::Primesieve to be an alias for
Primesieve::libprimesieve if BUILD_SHARED_LIBS=ON (in the user's
CMakeLists.txt) and and alias for Primesieve::libprimesieve-static if
BUILD_SHARED_LIBS=OFF (or if it is not set).

Is this possible?
Do you know any library that has already implemented this?

Thanks,
Kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180214/f8d0d721/attachment.html>

From jm3689 at columbia.edu  Wed Feb 14 11:34:26 2018
From: jm3689 at columbia.edu (ThePhD)
Date: Wed, 14 Feb 2018 11:34:26 -0500
Subject: [CMake] Config.cmake.in: Conditionally serve static or shared
 library
In-Reply-To: <CAE_DJ11=v9Y-EXOcB+ff+q3=FCpYncQqKLKy+TOyr88oUK=XhQ@mail.gmail.com>
References: <CAE_DJ11=v9Y-EXOcB+ff+q3=FCpYncQqKLKy+TOyr88oUK=XhQ@mail.gmail.com>
Message-ID: <CANNiNqJukDoUaOKf+0OLMLQzY1bFjrPvM_YnSb8XwYHHqPRj=Q@mail.gmail.com>

I think you can use what's called an "Alias Library":
https://cmake.org/cmake/help/latest/command/add_library.html#alias-libraries

if (BUILD_SHARED_LIBS)
     add_library(my_libprimesieve ALIAS libprimesieve)
else
     add_library(my_libprimesieve ALIAS libprimesieve-static)
endif(BUILD_SHARED_LIBS)

Then, set it properly to Primesieve::Primesieve and it should work.


On Wed, Feb 14, 2018 at 10:21 AM, Kim Walisch <kim.walisch at gmail.com> wrote:

> Hi,
>
> My primesieve project builds as both a static and a shared library, hence
> there are 2 targets in my main CMakeLists.txt:
>
> 1) libprimesieve (shared library)
> 2) libprimesieve-static
>
> I am now trying to add support for find_package(Primesieve). Ideally I
> would like that users can link against libprimesieve as follows:
>
> find_package(Primesieve REQUIRED)
> target_link_libraries(user_library Primesieve::Primesieve)
>
> And I want Primesieve::Primesieve to be an alias for
> Primesieve::libprimesieve if BUILD_SHARED_LIBS=ON (in the user's
> CMakeLists.txt) and and alias for Primesieve::libprimesieve-static if
> BUILD_SHARED_LIBS=OFF (or if it is not set).
>
> Is this possible?
> Do you know any library that has already implemented this?
>
> Thanks,
> Kim
>
> --
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180214/b009ba9a/attachment-0001.html>

From robert.maynard at kitware.com  Wed Feb 14 11:56:45 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 14 Feb 2018 11:56:45 -0500
Subject: [CMake] Config.cmake.in: Conditionally serve static or shared
 library
In-Reply-To: <CANNiNqJukDoUaOKf+0OLMLQzY1bFjrPvM_YnSb8XwYHHqPRj=Q@mail.gmail.com>
References: <CAE_DJ11=v9Y-EXOcB+ff+q3=FCpYncQqKLKy+TOyr88oUK=XhQ@mail.gmail.com>
 <CANNiNqJukDoUaOKf+0OLMLQzY1bFjrPvM_YnSb8XwYHHqPRj=Q@mail.gmail.com>
Message-ID: <CAFzjYVq13P=G4syiLMFwe7=pJaFL4+kL53fyShW6f7R19Tc0rg@mail.gmail.com>

If you want to support consumers that are building shared and static
libraries themselves you can do this by using an import library with a
generator expression.
A simplified version of how do this, besides the import library can be found at:

https://github.com/robertmaynard/Sandbox/blob/master/CMakeInterfaceChangesLibrary/CMakeLists.txt

On Wed, Feb 14, 2018 at 11:34 AM, ThePhD <jm3689 at columbia.edu> wrote:
> I think you can use what's called an "Alias Library":
> https://cmake.org/cmake/help/latest/command/add_library.html#alias-libraries
>
> if (BUILD_SHARED_LIBS)
>      add_library(my_libprimesieve ALIAS libprimesieve)
> else
>      add_library(my_libprimesieve ALIAS libprimesieve-static)
> endif(BUILD_SHARED_LIBS)
>
> Then, set it properly to Primesieve::Primesieve and it should work.
>
>
> On Wed, Feb 14, 2018 at 10:21 AM, Kim Walisch <kim.walisch at gmail.com> wrote:
>>
>> Hi,
>>
>> My primesieve project builds as both a static and a shared library, hence
>> there are 2 targets in my main CMakeLists.txt:
>>
>> 1) libprimesieve (shared library)
>> 2) libprimesieve-static
>>
>> I am now trying to add support for find_package(Primesieve). Ideally I
>> would like that users can link against libprimesieve as follows:
>>
>> find_package(Primesieve REQUIRED)
>> target_link_libraries(user_library Primesieve::Primesieve)
>>
>> And I want Primesieve::Primesieve to be an alias for
>> Primesieve::libprimesieve if BUILD_SHARED_LIBS=ON (in the user's
>> CMakeLists.txt) and and alias for Primesieve::libprimesieve-static if
>> BUILD_SHARED_LIBS=OFF (or if it is not set).
>>
>> Is this possible?
>> Do you know any library that has already implemented this?
>>
>> Thanks,
>> Kim
>>
>> --
>>
>> 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
>

From kim.walisch at gmail.com  Wed Feb 14 13:08:06 2018
From: kim.walisch at gmail.com (Kim Walisch)
Date: Wed, 14 Feb 2018 19:08:06 +0100
Subject: [CMake] Config.cmake.in: Conditionally serve static or shared
 library
In-Reply-To: <CANNiNqJukDoUaOKf+0OLMLQzY1bFjrPvM_YnSb8XwYHHqPRj=Q@mail.gmail.com>
References: <CAE_DJ11=v9Y-EXOcB+ff+q3=FCpYncQqKLKy+TOyr88oUK=XhQ@mail.gmail.com>
 <CANNiNqJukDoUaOKf+0OLMLQzY1bFjrPvM_YnSb8XwYHHqPRj=Q@mail.gmail.com>
Message-ID: <CAE_DJ12gRtiX5GyQh0QbqDYf=odeNjSK_BhUYTiqDpcNe+so6Q@mail.gmail.com>

CMake currently does not allow alias libraries for import targets:

$ cmake ..
CMake Error at /usr/local/lib/cmake/primesieve/PrimesieveConfig.cmake:7
(add_library):
  add_library cannot create ALIAS target "my_libprimesieve" because target
  "Primesieve::libprimesieve-static" is IMPORTED.
Call Stack (most recent call first):
  CMakeLists.txt:6 (find_package)

-- Configuring incomplete, errors occurred!

Kim


On Wed, Feb 14, 2018 at 5:34 PM, ThePhD <jm3689 at columbia.edu> wrote:

> I think you can use what's called an "Alias Library": https://cmake.org/
> cmake/help/latest/command/add_library.html#alias-libraries
>
> if (BUILD_SHARED_LIBS)
>      add_library(my_libprimesieve ALIAS libprimesieve)
> else
>      add_library(my_libprimesieve ALIAS libprimesieve-static)
> endif(BUILD_SHARED_LIBS)
>
> Then, set it properly to Primesieve::Primesieve and it should work.
>
>
> On Wed, Feb 14, 2018 at 10:21 AM, Kim Walisch <kim.walisch at gmail.com>
> wrote:
>
>> Hi,
>>
>> My primesieve project builds as both a static and a shared library, hence
>> there are 2 targets in my main CMakeLists.txt:
>>
>> 1) libprimesieve (shared library)
>> 2) libprimesieve-static
>>
>> I am now trying to add support for find_package(Primesieve). Ideally I
>> would like that users can link against libprimesieve as follows:
>>
>> find_package(Primesieve REQUIRED)
>> target_link_libraries(user_library Primesieve::Primesieve)
>>
>> And I want Primesieve::Primesieve to be an alias for
>> Primesieve::libprimesieve if BUILD_SHARED_LIBS=ON (in the user's
>> CMakeLists.txt) and and alias for Primesieve::libprimesieve-static if
>> BUILD_SHARED_LIBS=OFF (or if it is not set).
>>
>> Is this possible?
>> Do you know any library that has already implemented this?
>>
>> Thanks,
>> Kim
>>
>> --
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180214/009c3c63/attachment.html>

From kim.walisch at gmail.com  Wed Feb 14 15:47:24 2018
From: kim.walisch at gmail.com (Kim Walisch)
Date: Wed, 14 Feb 2018 21:47:24 +0100
Subject: [CMake] Config.cmake.in: Conditionally serve static or shared
 library
In-Reply-To: <CAE_DJ12gRtiX5GyQh0QbqDYf=odeNjSK_BhUYTiqDpcNe+so6Q@mail.gmail.com>
References: <CAE_DJ11=v9Y-EXOcB+ff+q3=FCpYncQqKLKy+TOyr88oUK=XhQ@mail.gmail.com>
 <CANNiNqJukDoUaOKf+0OLMLQzY1bFjrPvM_YnSb8XwYHHqPRj=Q@mail.gmail.com>
 <CAE_DJ12gRtiX5GyQh0QbqDYf=odeNjSK_BhUYTiqDpcNe+so6Q@mail.gmail.com>
Message-ID: <CAE_DJ129X28vH-5dGVvsBw-yyQ-Th1mjSbVNpYnpiHvLpWJ4sQ@mail.gmail.com>

Thanks, I got it working!

Unfortunately I could not make the generator expression work inside
PrimesieveConfig.cmake.in, here is the error message:

CMake Error:
  Error evaluating generator expression:
    $<BUILD_SHARED_LIBS:libprimesieve>
  Expression did not evaluate to a known generator expression

Note that in my main CMakeLists.txt the generator expression worked
fine. But I figured out I don't actually need the generator expression,
the following code inside my PrimesieveConfig.cmake.in does the trick:

if(BUILD_SHARED_LIBS)
        add_library(Primesieve::Primesieve INTERFACE IMPORTED)
        set_target_properties(Primesieve::Primesieve PROPERTIES
                INTERFACE_LINK_LIBRARIES "Primesieve::libprimesieve")
else()
        add_library(Primesieve::Primesieve INTERFACE IMPORTED)
        set_target_properties(Primesieve::Primesieve PROPERTIES
                INTERFACE_LINK_LIBRARIES "Primesieve::libprimesieve-static")
endif()

This trick is also used by the c-ares library:
https://github.com/gjasny/c-ares/blob/fec405a420597180244e6c66912f09ae84b31123/c-ares-config.cmake.in

The trick was already discussed on the cmake mailing list before:
https://cmake.org/pipermail/cmake-developers/2017-June/030115.html

It would be really nice though if CMake would support library aliases for
import targets, then I could achieve the same using much nicer code.

Kim

On Wed, Feb 14, 2018 at 7:08 PM, Kim Walisch <kim.walisch at gmail.com> wrote:

> CMake currently does not allow alias libraries for import targets:
>
> $ cmake ..
> CMake Error at /usr/local/lib/cmake/primesieve/PrimesieveConfig.cmake:7
> (add_library):
>   add_library cannot create ALIAS target "my_libprimesieve" because target
>   "Primesieve::libprimesieve-static" is IMPORTED.
> Call Stack (most recent call first):
>   CMakeLists.txt:6 (find_package)
>
> -- Configuring incomplete, errors occurred!
>
> Kim
>
>
> On Wed, Feb 14, 2018 at 5:34 PM, ThePhD <jm3689 at columbia.edu> wrote:
>
>> I think you can use what's called an "Alias Library":
>> https://cmake.org/cmake/help/latest/command/add_li
>> brary.html#alias-libraries
>>
>> if (BUILD_SHARED_LIBS)
>>      add_library(my_libprimesieve ALIAS libprimesieve)
>> else
>>      add_library(my_libprimesieve ALIAS libprimesieve-static)
>> endif(BUILD_SHARED_LIBS)
>>
>> Then, set it properly to Primesieve::Primesieve and it should work.
>>
>>
>> On Wed, Feb 14, 2018 at 10:21 AM, Kim Walisch <kim.walisch at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> My primesieve project builds as both a static and a shared library, hence
>>> there are 2 targets in my main CMakeLists.txt:
>>>
>>> 1) libprimesieve (shared library)
>>> 2) libprimesieve-static
>>>
>>> I am now trying to add support for find_package(Primesieve). Ideally I
>>> would like that users can link against libprimesieve as follows:
>>>
>>> find_package(Primesieve REQUIRED)
>>> target_link_libraries(user_library Primesieve::Primesieve)
>>>
>>> And I want Primesieve::Primesieve to be an alias for
>>> Primesieve::libprimesieve if BUILD_SHARED_LIBS=ON (in the user's
>>> CMakeLists.txt) and and alias for Primesieve::libprimesieve-static if
>>> BUILD_SHARED_LIBS=OFF (or if it is not set).
>>>
>>> Is this possible?
>>> Do you know any library that has already implemented this?
>>>
>>> Thanks,
>>> Kim
>>>
>>> --
>>>
>>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180214/3716c117/attachment-0001.html>

From post at hendrik-sattler.de  Wed Feb 14 17:42:29 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Wed, 14 Feb 2018 23:42:29 +0100
Subject: [CMake] Config.cmake.in: Conditionally serve static or shared
 library
In-Reply-To: <CAE_DJ129X28vH-5dGVvsBw-yyQ-Th1mjSbVNpYnpiHvLpWJ4sQ@mail.gmail.com>
References: <CAE_DJ11=v9Y-EXOcB+ff+q3=FCpYncQqKLKy+TOyr88oUK=XhQ@mail.gmail.com>
 <CANNiNqJukDoUaOKf+0OLMLQzY1bFjrPvM_YnSb8XwYHHqPRj=Q@mail.gmail.com>
 <CAE_DJ12gRtiX5GyQh0QbqDYf=odeNjSK_BhUYTiqDpcNe+so6Q@mail.gmail.com>
 <CAE_DJ129X28vH-5dGVvsBw-yyQ-Th1mjSbVNpYnpiHvLpWJ4sQ@mail.gmail.com>
Message-ID: <4B911529-B73D-4D58-9F92-F1180BB16886@hendrik-sattler.de>



Am 14. Februar 2018 21:47:24 MEZ schrieb Kim Walisch <kim.walisch at gmail.com>:
>Thanks, I got it working!
>
>Unfortunately I could not make the generator expression work inside
>PrimesieveConfig.cmake.in, here is the error message:
>
>CMake Error:
>  Error evaluating generator expression:
>    $<BUILD_SHARED_LIBS:libprimesieve>
>  Expression did not evaluate to a known generator expression
>
>Note that in my main CMakeLists.txt the generator expression worked
>fine. But I figured out I don't actually need the generator expression,
>the following code inside my PrimesieveConfig.cmake.in does the trick:
>
>if(BUILD_SHARED_LIBS)

This is IMHO using the wrong variable! This variable tells that I want to build MY libs as static, not that I want to link 3rdParty libs statically!
At least this is surprising behavior.

OTOH and luckily, there are still the real targets to choose from.

>This trick is also used by the c-ares library:

Others also doing this wrong does not make it any better.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

From damienrg+list at gmail.com  Wed Feb 14 18:00:51 2018
From: damienrg+list at gmail.com (Damien R)
Date: Thu, 15 Feb 2018 00:00:51 +0100
Subject: [CMake] Auto generating package configuration file?
Message-ID: <CAKPeRif1NqFidaPGdyb-xf-kk_WOVHWA-ku=ABR2+mG3ROY4Ng@mail.gmail.com>

Hi,

I know that I could write FooConfig.cmake.in, call
configure_package_config_file() to generate package configuration file and
call write_basic_package_version_file() to generate a version file.
Typically FooConfig.cmake.in contains:
@PACKAGE_INIT@
find_dependency(...)

My question is why do I need to do that? Is it not possible for cmake to
autogenerate theses files?
I may be wrong but I think that "modern cmake" has the necessary
informations to do that.

Regards,

Damien R.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180215/229a226a/attachment.html>

From kim.walisch at gmail.com  Thu Feb 15 02:11:05 2018
From: kim.walisch at gmail.com (Kim Walisch)
Date: Thu, 15 Feb 2018 08:11:05 +0100
Subject: [CMake] Config.cmake.in: Conditionally serve static or shared
 library
In-Reply-To: <4B911529-B73D-4D58-9F92-F1180BB16886@hendrik-sattler.de>
References: <CAE_DJ11=v9Y-EXOcB+ff+q3=FCpYncQqKLKy+TOyr88oUK=XhQ@mail.gmail.com>
 <CANNiNqJukDoUaOKf+0OLMLQzY1bFjrPvM_YnSb8XwYHHqPRj=Q@mail.gmail.com>
 <CAE_DJ12gRtiX5GyQh0QbqDYf=odeNjSK_BhUYTiqDpcNe+so6Q@mail.gmail.com>
 <CAE_DJ129X28vH-5dGVvsBw-yyQ-Th1mjSbVNpYnpiHvLpWJ4sQ@mail.gmail.com>
 <4B911529-B73D-4D58-9F92-F1180BB16886@hendrik-sattler.de>
Message-ID: <CAE_DJ12VHSjxO9ZHaciF1=mbHnv9uwaR4S=-gtrnMWRtjGiJYw@mail.gmail.com>

Thanks for your comment, I seem to have misunderstood the usage of
BUILD_SHARED_LIBS. I will remove the hack to serve either a static or
shared libprimesieve from my cmake config file.

Kim

On Feb 14, 2018 11:42 PM, "Hendrik Sattler" <post at hendrik-sattler.de> wrote:

>
>
> Am 14. Februar 2018 21:47:24 MEZ schrieb Kim Walisch <
> kim.walisch at gmail.com>:
> >Thanks, I got it working!
> >
> >Unfortunately I could not make the generator expression work inside
> >PrimesieveConfig.cmake.in, here is the error message:
> >
> >CMake Error:
> >  Error evaluating generator expression:
> >    $<BUILD_SHARED_LIBS:libprimesieve>
> >  Expression did not evaluate to a known generator expression
> >
> >Note that in my main CMakeLists.txt the generator expression worked
> >fine. But I figured out I don't actually need the generator expression,
> >the following code inside my PrimesieveConfig.cmake.in does the trick:
> >
> >if(BUILD_SHARED_LIBS)
>
> This is IMHO using the wrong variable! This variable tells that I want to
> build MY libs as static, not that I want to link 3rdParty libs statically!
> At least this is surprising behavior.
>
> OTOH and luckily, there are still the real targets to choose from.
>
> >This trick is also used by the c-ares library:
>
> Others also doing this wrong does not make it any better.
>
> HS
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180215/bd8b0118/attachment.html>

From robert.maynard at kitware.com  Thu Feb 15 11:39:59 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 15 Feb 2018 11:39:59 -0500
Subject: [CMake] Config.cmake.in: Conditionally serve static or shared
 library
In-Reply-To: <CAE_DJ129X28vH-5dGVvsBw-yyQ-Th1mjSbVNpYnpiHvLpWJ4sQ@mail.gmail.com>
References: <CAE_DJ11=v9Y-EXOcB+ff+q3=FCpYncQqKLKy+TOyr88oUK=XhQ@mail.gmail.com>
 <CANNiNqJukDoUaOKf+0OLMLQzY1bFjrPvM_YnSb8XwYHHqPRj=Q@mail.gmail.com>
 <CAE_DJ12gRtiX5GyQh0QbqDYf=odeNjSK_BhUYTiqDpcNe+so6Q@mail.gmail.com>
 <CAE_DJ129X28vH-5dGVvsBw-yyQ-Th1mjSbVNpYnpiHvLpWJ4sQ@mail.gmail.com>
Message-ID: <CAFzjYVpr=UiPp0z0SE_n+Tw5=2NJbyOhkGOrO4CW=Q5ZGoN-Sw@mail.gmail.com>

It would be really nice though if CMake would support library aliases for
import targets, then I could achieve the same using much nicer code.

3.11 will include support for aliasing import targets, as long as the
import target was marked with GLOBAL visibility.

On Wed, Feb 14, 2018 at 3:47 PM, Kim Walisch <kim.walisch at gmail.com> wrote:
> Thanks, I got it working!
>
> Unfortunately I could not make the generator expression work inside
> PrimesieveConfig.cmake.in, here is the error message:
>
> CMake Error:
>   Error evaluating generator expression:
>     $<BUILD_SHARED_LIBS:libprimesieve>
>   Expression did not evaluate to a known generator expression
>
> Note that in my main CMakeLists.txt the generator expression worked
> fine. But I figured out I don't actually need the generator expression,
> the following code inside my PrimesieveConfig.cmake.in does the trick:
>
> if(BUILD_SHARED_LIBS)
>         add_library(Primesieve::Primesieve INTERFACE IMPORTED)
>         set_target_properties(Primesieve::Primesieve PROPERTIES
>                 INTERFACE_LINK_LIBRARIES "Primesieve::libprimesieve")
> else()
>         add_library(Primesieve::Primesieve INTERFACE IMPORTED)
>         set_target_properties(Primesieve::Primesieve PROPERTIES
>                 INTERFACE_LINK_LIBRARIES "Primesieve::libprimesieve-static")
> endif()
>
> This trick is also used by the c-ares library:
> https://github.com/gjasny/c-ares/blob/fec405a420597180244e6c66912f09ae84b31123/c-ares-config.cmake.in
>
> The trick was already discussed on the cmake mailing list before:
> https://cmake.org/pipermail/cmake-developers/2017-June/030115.html
>
> It would be really nice though if CMake would support library aliases for
> import targets, then I could achieve the same using much nicer code.
>
> Kim
>
> On Wed, Feb 14, 2018 at 7:08 PM, Kim Walisch <kim.walisch at gmail.com> wrote:
>>
>> CMake currently does not allow alias libraries for import targets:
>>
>> $ cmake ..
>> CMake Error at /usr/local/lib/cmake/primesieve/PrimesieveConfig.cmake:7
>> (add_library):
>>   add_library cannot create ALIAS target "my_libprimesieve" because target
>>   "Primesieve::libprimesieve-static" is IMPORTED.
>> Call Stack (most recent call first):
>>   CMakeLists.txt:6 (find_package)
>>
>> -- Configuring incomplete, errors occurred!
>>
>> Kim
>>
>>
>> On Wed, Feb 14, 2018 at 5:34 PM, ThePhD <jm3689 at columbia.edu> wrote:
>>>
>>> I think you can use what's called an "Alias Library":
>>> https://cmake.org/cmake/help/latest/command/add_library.html#alias-libraries
>>>
>>> if (BUILD_SHARED_LIBS)
>>>      add_library(my_libprimesieve ALIAS libprimesieve)
>>> else
>>>      add_library(my_libprimesieve ALIAS libprimesieve-static)
>>> endif(BUILD_SHARED_LIBS)
>>>
>>> Then, set it properly to Primesieve::Primesieve and it should work.
>>>
>>>
>>> On Wed, Feb 14, 2018 at 10:21 AM, Kim Walisch <kim.walisch at gmail.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> My primesieve project builds as both a static and a shared library,
>>>> hence
>>>> there are 2 targets in my main CMakeLists.txt:
>>>>
>>>> 1) libprimesieve (shared library)
>>>> 2) libprimesieve-static
>>>>
>>>> I am now trying to add support for find_package(Primesieve). Ideally I
>>>> would like that users can link against libprimesieve as follows:
>>>>
>>>> find_package(Primesieve REQUIRED)
>>>> target_link_libraries(user_library Primesieve::Primesieve)
>>>>
>>>> And I want Primesieve::Primesieve to be an alias for
>>>> Primesieve::libprimesieve if BUILD_SHARED_LIBS=ON (in the user's
>>>> CMakeLists.txt) and and alias for Primesieve::libprimesieve-static if
>>>> BUILD_SHARED_LIBS=OFF (or if it is not set).
>>>>
>>>> Is this possible?
>>>> Do you know any library that has already implemented this?
>>>>
>>>> Thanks,
>>>> Kim
>>>>
>>>> --
>>>>
>>>> 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
>>>
>>
>
>
> --
>
> 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
>

From robert.maynard at kitware.com  Thu Feb 15 12:51:13 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Thu, 15 Feb 2018 12:51:13 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.11.0-rc1 is now ready for testing
Message-ID: <CAFzjYVoBKS1PNtEtKSO5Gq4Xotns6Lgw07pFLOxozerTwCYeaw@mail.gmail.com>

I am proud to announce the first CMake 3.11 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.11

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.11/release/3.11.html

Some of the more significant changes in CMake 3.11 are:

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE_<LANG>_COMPILER_LAUNCHER" variable and
  "<LANG>_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" Generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.

* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.

* The "COMPILE_DEFINITIONS" source file property learned to support
  "generator expressions".

* A "COMPILE_OPTIONS" source file property was added to manage list
  of options to pass to the compiler.

* When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
  parallel "moc" or "uic" processes to reduce the build time. A new
  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
  property may be set to specify the number of parallel "moc" or "uic"
  processes to start.  The default is derived from the number of CPUs
  on the host.


CMake 3.11 Release Notes
************************

Changes made since CMake 3.10 include the following.


New Features
============


Platforms
---------

* TI C/C++ compilers are now supported by the "Ninja" generator.


Generators
----------

* The "CodeBlocks" extra generator learned to check a
  "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler
  identification value to place in the project file.

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE_<LANG>_COMPILER_LAUNCHER" variable and
  "<LANG>_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.


Commands
--------

* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC"
  and "NETRC_FILE" options to specify use of a ".netrc" file.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.


Variables
---------

* A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the
  selected instance of the generator's corresponding native tools if
  multiple are available.  This is used by the "Visual Studio 15 2017"
  generator to hold the selected instance of Visual Studio
  persistently.

* A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added
  to enable setting of default permissions for directories created
  implicitly during installation of files by "install()" and
  "file(INSTALL)", e.g. during "make install".

* A "CMAKE_JOB_POOLS" variable was added specify a value to use for
  the "JOB_POOLS" property. This enables control over build
  parallelism with command line configuration parameters when using
  the Ninja generator.

* The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to
  specify use of a ".netrc" file by the "file(DOWNLOAD)" and
  "file(UPLOAD)" commands and the "ExternalProject" module.

* A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to
  initialize the "CUDA_SEPARABLE_COMPILATION" target property on
  targets when they are created.


Properties
----------

* The "COMPILE_DEFINITIONS" source file property learned to support
  "generator expressions".

* A "COMPILE_OPTIONS" source file property was added to manage list
  of options to pass to the compiler.

* An "IMPORTED_GLOBAL" target property was added to indicate whether
  an IMPORTED target is globally visible. It is automatically set to a
  true value for targets created with the "GLOBAL" option to
  "add_library()" or "add_executable()". Additionally, project code
  may now *promote* a local imported target to be globally visible by
  setting this property to "TRUE".

* An "INCLUDE_DIRECTORIES" source file property was added to specify
  list of preprocessor include file search directories.

* Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and
  "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of
  ".hlsl" sources with Visual Studio Generators.


Modules
-------

* The "CheckIncludeFile" module "check_include_file" macro learned
  to honor the "CMAKE_REQUIRED_LIBRARIES" variable.

* The "CheckIncludeFileCXX" module "check_include_file_cxx" macro
  learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable.

* The "CheckIncludeFiles" module "check_include_files" macro learned
  to honor the "CMAKE_REQUIRED_LIBRARIES" variable.

* The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command
  gained a "LANGUAGE" option to specify whether to check using the "C"
  or "CXX" compiler.

* The "CMakePackageConfigHelpers" module
  "write_basic_package_version_file()" command learned a new
  "SameMinorVersion" mode for the "COMPATIBILITY" argument.

* The "ExternalProject" module learned to substitute
  "<DOWNLOAD_DIR>" in comments, commands, working directory and
  byproducts.

* The "ExternalProject" module gained "NETRC" and "NETRC_FILE"
  options to specify use of a ".netrc" file.

* A new "FetchContent" module was added which supports populating
  content at configure time using any of the download/update methods
  supported by "ExternalProject_Add()".  This allows the content to be
  used immediately during the configure stage, such as with
  "add_subdirectory()", etc.  Hierarchical project structures are well
  supported, allowing parent projects to override the content details
  of child projects and ensuring content is not populated multiple
  times throughout the whole project tree.

* The "FindBLAS" and "FindLAPACK" modules learned to support FLAME
  "blis" and "libflame".

* The "FindDoxygen" module "doxygen_add_docs()" function now
  supports a new "DOXYGEN_VERBATIM_VARS" list variable.  Any
  "DOXYGEN_..." variable contained in that list will bypass the
  automatic quoting logic, leaving its contents untouched when
  transferring them to the output "Doxyfile".

* A "FindIconv" module was added to locate iconv support.

* The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command
  gained an "INCLUDE_GUARD_NAME" option to change the name of the
  include guard symbol written to the generated export header.
  Additionally, it now adds a comment after the closing "#endif" on
  the generated export header's include guard.

* The "UseJava" module "add_jar" command gained a
  "GENERATE_NATIVE_HEADERS" option to generate native header files
  using "javac -h" for "javac" 1.8 or above.  This supersedes
  "create_javah", which no longer works with JDK 1.10 and above due to
  removal of the "javah" tool by JEP 313.


Autogen
-------

* When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
  parallel "moc" or "uic" processes to reduce the build time. A new
  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
  property may be set to specify the number of parallel "moc" or "uic"
  processes to start.  The default is derived from the number of CPUs
  on the host.


CTest
-----

* The "ctest_start()" command no longer sets
  "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is
  called from inside a function. Instead, it sets an internal variable
  in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the
  global scope still prevents the script from being re-run at the end.


CPack
-----

* "cpack(1)" gained "--trace" and "--trace-expand" options.

* The "CPackIFW" module gained new
  "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the
  target directory should not be deleted when uninstalling.

* The "CPackRPM" module learned to enable enforcing of execute
  privileges on programs and shared libraries. See
  "CPACK_RPM_INSTALL_WITH_EXEC" variable.

* A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added
  which serves the same purpose during packaging (e.g. "make package")
  as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves
  during installation (e.g. "make install").


Other
-----

* Alias Targets may now alias Imported Targets that are created with
  the "GLOBAL" option to "add_library()".

* Interface Libraries may now have custom properties set on them if
  they start with either an underscore ("_") or a lowercase ASCII
  character. The original intention was to only allow properties which
  made sense for "INTERFACE" libraries, but it also blocked usage of
  custom properties.

* The "cmake(1)" "--open <dir>" command-line option was added to
  open generated IDE projects like Visual Studio solutions or Xcode
  projects.


Deprecated and Removed Features
===============================

* An explicit deprecation diagnostic was added for policies
  "CMP0037" through "CMP0054" ("CMP0036" and below were already
  deprecated). The "cmake-policies(7)" manual explains that the OLD
  behaviors of all policies are deprecated and that projects should
  port to the NEW behaviors.

* The "KDevelop3" generator has been removed.


Other Changes
=============

* Policy "CMP0037" no longer reserves target names associated with
  optional features, such as "test" and "package", unless the
  corresponding feature is enabled.

* The "FindOpenGL" module now prefers GLVND libraries if available.
  See policy "CMP0072".

* The minimum deployment target set in the
  "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for
  macOS regardless of the selected SDK.  It is now properly set for
  the target platform selected by "CMAKE_OSX_SYSROOT". For example, if
  the sysroot variable specifies an iOS SDK then the value in
  "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version.

* The "Xcode" generator behavior of generating one project file per
  "project()" command may now be controlled with the
  "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could
  be useful to speed up the CMake generation step for large projects
  and to work-around a bug in the "ZERO_CHECK" logic.

* Since the "CMakeCache.txt" format does not support newlines in
  values, values containing newlines are now truncated before writing
  to the file. In addition, a warning comment is written to the cache
  file, and a warning message is displayed to the user on the console.

From kim.walisch at gmail.com  Thu Feb 15 16:04:10 2018
From: kim.walisch at gmail.com (Kim Walisch)
Date: Thu, 15 Feb 2018 22:04:10 +0100
Subject: [CMake] find_package(): fails because static library is not
 installed
Message-ID: <CAE_DJ10XJYPd-PyJZB-hpx9rSE6vZhVqLa+C86QnW7r7DrCLuQ@mail.gmail.com>

Hi,

I have added support for find_package(primesieve) to my primesieve library
and I have exported 2 targets in my main CMakeLists.txt:

primesieve::libprimesieve (shared library)
primesieve::libprimesieve-static

It works fine if both the static and shared primesieve libraries have
previously
been installed. As a test I have now deleted the static libprimesieve from
my
PC and now find_package(primesieve) fails:

CMake Error at /usr/local/lib/cmake/primesieve/primesieveTargets.cmake:88
(message):
  The imported target "primesieve::libprimesieve-static" references the file
     "/usr/local/lib/libprimesieve.a"
  but this file does not exist.  Possible reasons include...

The error seems reasonable but if I leave my code as is this error will be
triggered if somebody installs the libprimesieve RPM package on Fedora or
Red Hat Linux. The libprimesieve package contains only the shared
libprimesieve. Fedora requires that static libraries are put into a separate
package. Hence the static primesieve library is in libprimesieve-static.

How can I solve this issue? If the shared libprimesieve is installed but the
static libprimesieve is not installed then I would like to only export:

primesieve::libprimesieve (shared library)

But if both the static and shared libprimesieve are installed I would like
to export:

primesieve::libprimesieve (shared library)
primesieve::libprimesieve-static

Do you know any library which has already implemented this?

Thanks,
Kim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180215/a1305d0b/attachment-0001.html>

From cornelis at bockemuehl.ch  Fri Feb 16 11:31:16 2018
From: cornelis at bockemuehl.ch (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=)
Date: Fri, 16 Feb 2018 17:31:16 +0100
Subject: [CMake] Parallel build setup question
Message-ID: <1518798676.10410.55.camel@bockemuehl.ch>

Hello,

Somehow I seem to miss some crucial point regarding setup for parallel
build with CMake, so I would be happy if somebody can push me the last
few millimeters to hit my target!

My configuration is on OpenSuse Linux (Leap - 64-bit), working with
QtCreator and CMake, using the "make" configuration.

I learned from "the internet" that actually I would have to pass a -jN
option to make or gmake (with N being the max number of processors I
want to use). Or even more elegant: go for a -lN option to somehow
balance the load. Sounds good!

But what I do not see is how to pass these nice options to make through
CMake and QtCreator! One attempt was to specify CMAKE_CXX_FLAGS=-j4 or
the like because some comment "in the internet" seemed to suggest this.
However, like I already feared: this passes the option to the compiler
call - and that is the wrong address for it, so I get an error message.

Basically I think that it is 99% a CMake question and maximum 1% a
QtCreator problem, so I am asking this question here.

And now I am stuck - if not some friendly and knowing person can help
me out of this!

Thanks for any helpful hint!
Cornelis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180216/457d1af4/attachment.html>

From mellery451 at gmail.com  Fri Feb 16 11:59:33 2018
From: mellery451 at gmail.com (Michael Ellery)
Date: Fri, 16 Feb 2018 08:59:33 -0800
Subject: [CMake] Parallel build setup question
In-Reply-To: <1518798676.10410.55.camel@bockemuehl.ch>
References: <1518798676.10410.55.camel@bockemuehl.ch>
Message-ID: <634C2184-8BE9-4B8D-90E1-5D44DACB67DE@gmail.com>

I don?t know anything about QTCreator, but the question really boils down to how to get your IDE to pass extra args to the build tool - it?s not really a cmake issue except to the extent that CMake can be used to invoke the build step (after it has been used to generate the build).  It sounds like QT uses ?cmake --build? to do the build phase (which makes sense), so you just need to add your ?-j N? argument to the build step invocation. If you believe this:  https://doc.qt.io/qtcreator/creator-build-settings.html, then it sounds like maybe ?Tool Arguments? is what you want (see ?CMake Build Steps?) ?  BTW, the way I do this myself (since I don?t use an IDE) is something like ?cmake --build . -- -j 8?  where the double dash stops shell argument processing and effectively passes everything else on to the build tool that cmake ultimately invokes (e.g. make or ninja or msbuild, etc.)

HTH,
Mike

> On Feb 16, 2018, at 8:31 AM, Cornelis Bockem?hl <cornelis at bockemuehl.ch> wrote:
> 
> Hello,
> 
> Somehow I seem to miss some crucial point regarding setup for parallel build with CMake, so I would be happy if somebody can push me the last few millimeters to hit my target!
> 
> My configuration is on OpenSuse Linux (Leap - 64-bit), working with QtCreator and CMake, using the "make" configuration.
> 
> I learned from "the internet" that actually I would have to pass a -jN option to make or gmake (with N being the max number of processors I want to use). Or even more elegant: go for a -lN option to somehow balance the load. Sounds good!
> 
> But what I do not see is how to pass these nice options to make through CMake and QtCreator! One attempt was to specify CMAKE_CXX_FLAGS=-j4 or the like because some comment "in the internet" seemed to suggest this. However, like I already feared: this passes the option to the compiler call - and that is the wrong address for it, so I get an error message.
> 
> Basically I think that it is 99% a CMake question and maximum 1% a QtCreator problem, so I am asking this question here.
> 
> And now I am stuck - if not some friendly and knowing person can help me out of this!
> 
> Thanks for any helpful hint!
> Cornelis
> -- 
> 
> 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


From cornelis at bockemuehl.ch  Fri Feb 16 12:20:13 2018
From: cornelis at bockemuehl.ch (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=)
Date: Fri, 16 Feb 2018 18:20:13 +0100
Subject: [CMake] Parallel build setup question
In-Reply-To: <634C2184-8BE9-4B8D-90E1-5D44DACB67DE@gmail.com>
References: <1518798676.10410.55.camel@bockemuehl.ch>
 <634C2184-8BE9-4B8D-90E1-5D44DACB67DE@gmail.com>
Message-ID: <1518801613.10410.59.camel@bockemuehl.ch>

Thanks for your hints! And you are right: it is still interesting to
know how QtCreator is actually invoking and using cmake.

This is the beginning of a log that the QtCreator was generating during
a build. Actually with two modules where nothing had to be done, but
still showing how cmake and gmake are being invoked - and all a bit
above my understanding of the two tools:

===================================
/usr/bin/cmake -H/Sources/GitLinux/RMT -B/BinariesLinux/RMT/Debug --
check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start
/BinariesLinux/RMT/Debug/CMakeFiles
/BinariesLinux/RMT/Debug/CMakeFiles/progress.marks
/usr/bin/gmake -f CMakeFiles/Makefile2 all
gmake[1]: Entering directory '/BinariesLinux/RMT/Debug'
/usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make
CMakeFiles/FirstModule.dir/depend
gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E cmake_depends "Unix
Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT
/BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug
/BinariesLinux/RMT/Debug/CMakeFiles/FirstModule.dir/DependInfo.cmake --
color=
gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
/usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make
CMakeFiles/FirstModule.dir/build
gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
gmake[2]: Nothing to be done for 'CMakeFiles/FirstModule.dir/build'.
gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
[??3%] Built target FirstModule
/usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make
CMakeFiles/SecondModule.dir/depend
gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E cmake_depends "Unix
Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT
/BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug
/BinariesLinux/RMT/Debug/CMakeFiles/SecondModule.dir/DependInfo.cmake
--color=
gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
/usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make
CMakeFiles/SecondModule.dir/build
gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
gmake[2]: Nothing to be done for 'CMakeFiles/SecondModule.dir/build'.
gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
[??6%] Built target SecondModule
...
===========================================

For example I do not really understand all the parameters that are
passed to cmake - and I do not find them in the documentation either
(like -H, -B or --check-build-system...

Regards,
Cornelis

Am Freitag, den 16.02.2018, 08:59 -0800 schrieb Michael Ellery:
> > > > > > > > > > > > > > I don?t know anything about QTCreator, but the question really boils
down to how to get your IDE to pass extra args to the build tool -
it?s not really a cmake issue except to the extent that CMake can be
used to invoke the build step (after it has been used to generate the
build).??It sounds like QT uses ?cmake --build? to do the build phase
(which makes sense), so you just need to add your ?-j N? argument to
the build step invocation. If you believe this:??https://doc.qt.io/qt
creator/creator-build-settings.html, then it sounds like maybe ?Tool
Arguments? is what you want (see ?CMake Build Steps?) ???BTW, the way
I do this myself (since I don?t use an IDE) is something like ?cmake
--build . -- -j 8???where the double dash stops shell argument
processing and effectively passes everything else on to the build
tool that cmake ultimately invokes (e.g. make or ninja or msbuild,
etc.)
> 
> HTH,
> Mike
> 
> > > > On Feb 16, 2018, at 8:31 AM, Cornelis Bockem?hl <cornelis at bockemueh
l.ch> wrote:
> > 
> > Hello,
> > 
> > > > > > Somehow I seem to miss some crucial point regarding setup for
parallel build with CMake, so I would be happy if somebody can push
me the last few millimeters to hit my target!
> > 
> > > > My configuration is on OpenSuse Linux (Leap - 64-bit), working with
QtCreator and CMake, using the "make" configuration.
> > 
> > > > > > > > I learned from "the internet" that actually I would have to pass a
-jN option to make or gmake (with N being the max number of
processors I want to use). Or even more elegant: go for a -lN
option to somehow balance the load. Sounds good!
> > 
> > > > > > > > > > > > But what I do not see is how to pass these nice options to make
through CMake and QtCreator! One attempt was to specify
CMAKE_CXX_FLAGS=-j4 or the like because some comment "in the
internet" seemed to suggest this. However, like I already feared:
this passes the option to the compiler call - and that is the wrong
address for it, so I get an error message.
> > 
> > > > Basically I think that it is 99% a CMake question and maximum 1% a
QtCreator problem, so I am asking this question here.
> > 
> > > > And now I am stuck - if not some friendly and knowing person can
help me out of this!
> > 
> > Thanks for any helpful hint!
> > Cornelis
> > --?
> > 
> > Powered by www.kitware.com
> > 
> > > > Please keep messages on-topic and check the CMake FAQ at: http://ww
w.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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180216/5ea5ca76/attachment.html>

From annulen at yandex.ru  Fri Feb 16 12:25:21 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 16 Feb 2018 20:25:21 +0300
Subject: [CMake] Parallel build setup question
In-Reply-To: <1518801613.10410.59.camel@bockemuehl.ch>
References: <1518798676.10410.55.camel@bockemuehl.ch>
 <634C2184-8BE9-4B8D-90E1-5D44DACB67DE@gmail.com>
 <1518801613.10410.59.camel@bockemuehl.ch>
Message-ID: <20661518801921@web50j.yandex.ru>

An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180216/566b3527/attachment.html>

From satzeni at nvidia.com  Fri Feb 16 12:29:04 2018
From: satzeni at nvidia.com (Simone Atzeni)
Date: Fri, 16 Feb 2018 17:29:04 +0000
Subject: [CMake] OBJECT Library Type
Message-ID: <0976b14b68ad42ba84af166b54ec0a8b@HQMAIL102.nvidia.com>

Hi,

I am trying to merge together two "OBJECT" libraries.
I am following the tutorial at: https://cmake.org/Wiki/CMake/Tutorials/Object_Library

However, in my case I have more level of folder nesting, and at the parent level I would like to merge two "OBJECT" libraries and only at the top I want to create the actual library.

I tried with:

add_library(common OBJECT "$<TARGET_OBJECTS:A> $<TARGET_OBJECTS:B> $<TARGET_OBJECTS:C>")

But I get the following error:

-----------------------------------------------------------------------------------------------------
CMake Error at lib/common/CMakeLists.txt:31 (add_library):
  OBJECT library "common" contains:

    file1.cpp.o
    file2.cpp.o
    file3.cpp.o
    ...

  but may contain only sources that compile, header files, and other files
  that would not affect linking of a normal library.

CMake Error at lib/common/CMakeLists.txt:31 (add_library):
  Only executables and non-OBJECT libraries may reference target objects.

What's the correct way to do this?

Thanks.
Simone


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180216/39ca7c44/attachment-0001.html>

From satzeni at nvidia.com  Fri Feb 16 12:34:48 2018
From: satzeni at nvidia.com (Simone Atzeni)
Date: Fri, 16 Feb 2018 17:34:48 +0000
Subject: [CMake] OBJECT Library Type
Message-ID: <e58114c1193c4fc9a029beb7975acaaf@HQMAIL102.nvidia.com>

Hi,

I am trying to merge together two "OBJECT" libraries.
I am following the tutorial at: https://cmake.org/Wiki/CMake/Tutorials/Object_Library

However, in my case I have more level of folder nesting, and at the parent level I would like to merge two "OBJECT" libraries and only at the top I want to create the actual library.

I tried with:

add_library(common OBJECT "$<TARGET_OBJECTS:A> $<TARGET_OBJECTS:B> $<TARGET_OBJECTS:C>")

But I get the following error:

-----------------------------------------------------------------------------------------------------
CMake Error at lib/common/CMakeLists.txt:31 (add_library):
  OBJECT library "common" contains:

    file1.cpp.o
    file2.cpp.o
    file3.cpp.o
    ...

  but may contain only sources that compile, header files, and other files
  that would not affect linking of a normal library.

CMake Error at lib/common/CMakeLists.txt:31 (add_library):
  Only executables and non-OBJECT libraries may reference target objects.

What's the correct way to do this?

Thanks.
Simone


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180216/fac00c31/attachment.html>

From cornelis at bockemuehl.ch  Fri Feb 16 13:32:07 2018
From: cornelis at bockemuehl.ch (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=)
Date: Fri, 16 Feb 2018 19:32:07 +0100
Subject: [CMake] Parallel build setup question
In-Reply-To: <20661518801921@web50j.yandex.ru>
References: <1518798676.10410.55.camel@bockemuehl.ch>
 <634C2184-8BE9-4B8D-90E1-5D44DACB67DE@gmail.com>
 <1518801613.10410.59.camel@bockemuehl.ch> <20661518801921@web50j.yandex.ru>
Message-ID: <1518805927.10410.64.camel@bockemuehl.ch>

Thanks - that did the trick!

And indeed by entering -j4 in the "Tool arguments" field, the build
command changes "magically" into "cmake --build . --target all -- -j4"
- with the "--" to pass the argument further to gmake.


Actually compile time of my project after a "clean" went down from 23
to 14 min, thus reduction factor 1.6 with 4 processors: I tend to
attribute the diffference to "almost 4" to the nature of my project
where gmake seems not to see too many opportunities for parallel
processing. Maybe it works always module by module, or whatever.

Anyway, my question is answered - thanks again!

Regards,
Cornelis

Am Freitag, den 16.02.2018, 20:25 +0300 schrieb Konstantin Tokarev:
> ?
> ?
> > 16.02.2018, 20:20, "Cornelis Bockem?hl" <cornelis at bockemuehl.ch>:
> > > > Thanks for your hints! And you are right: it is still interesting
to know how QtCreator is actually invoking and using cmake.
> > You should go to project settings and change cmake --build arguments
there
> ?
> > ?
> > > > > > > > This is the beginning of a log that the QtCreator was generating
during a build. Actually with two modules where nothing had to be
done, but still showing how cmake and gmake are being invoked - and
all a bit above my understanding of the two tools:
> > ?
> > ===================================
> > > > /usr/bin/cmake -H/Sources/GitLinux/RMT -B/BinariesLinux/RMT/Debug
--check-build-system CMakeFiles/Makefile.cmake 0
> > > > > > /usr/bin/cmake -E cmake_progress_start
/BinariesLinux/RMT/Debug/CMakeFiles
/BinariesLinux/RMT/Debug/CMakeFiles/progress.marks
> > /usr/bin/gmake -f CMakeFiles/Makefile2 all
> > gmake[1]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make
CMakeFiles/FirstModule.dir/depend
> > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E cmake_depends
"Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT
/BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug
/BinariesLinux/RMT/Debug/CMakeFiles/FirstModule.dir/DependInfo.cmak
e --color=
> > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make
CMakeFiles/FirstModule.dir/build
> > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > gmake[2]: Nothing to be done for
'CMakeFiles/FirstModule.dir/build'.
> > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > [??3%] Built target FirstModule
> > > > /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make
CMakeFiles/SecondModule.dir/depend
> > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E cmake_depends
"Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT
/BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug
/BinariesLinux/RMT/Debug/CMakeFiles/SecondModule.dir/DependInfo.cma
ke --color=
> > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > > > /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make
CMakeFiles/SecondModule.dir/build
> > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > gmake[2]: Nothing to be done for
'CMakeFiles/SecondModule.dir/build'.
> > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > [??6%] Built target SecondModule
> > ...
> > ===========================================
> > ?
> > > > > > For example I do not really understand all the parameters that are
passed to cmake - and I do not find them in the documentation
either (like -H, -B or --check-build-system...
> > ?
> > Regards,
> > Cornelis
> > ?
> > Am Freitag, den 16.02.2018, 08:59 -0800 schrieb Michael Ellery:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don?t know anything about QTCreator, but the question really
boils down to how to get your IDE to pass extra args to the build
tool - it?s not really a cmake issue except to the extent that
CMake can be used to invoke the build step (after it has been
used to generate the build).??It sounds like QT uses ?cmake --
build? to do the build phase (which makes sense), so you just
need to add your ?-j N? argument to the build step invocation. If
you believe this:??https://doc.qt.io/qtcreator/creator-build-sett
ings.html, then it sounds like maybe ?Tool Arguments? is what you
want (see ?CMake Build Steps?) ???BTW, the way I do this myself
(since I don?t use an IDE) is something like ?cmake --build . --
-j 8???where the double dash stops shell argument processing and
effectively passes everything else on to the build tool that
cmake ultimately invokes (e.g. make or ninja or msbuild, etc.)
> > > HTH,
> > > Mike
> > > 
> > > 
> > > > > > On Feb 16, 2018, at 8:31 AM, Cornelis Bockem?hl <cornelis at bockemu
ehl.ch> wrote:
> > > 
> > > Hello,
> > > 
> > > > > > > > > Somehow I seem to miss some crucial point regarding setup for
parallel build with CMake, so I would be happy if somebody can
push me the last few millimeters to hit my target!
> > > 
> > > > > > My configuration is on OpenSuse Linux (Leap - 64-bit), working
with QtCreator and CMake, using the "make" configuration.
> > > 
> > > > > > > > > > > > I learned from "the internet" that actually I would have to pass
a -jN option to make or gmake (with N being the max number of
processors I want to use). Or even more elegant: go for a -lN
option to somehow balance the load. Sounds good!
> > > 
> > > > > > > > > > > > > > > > > > But what I do not see is how to pass these nice options to make
through CMake and QtCreator! One attempt was to specify
CMAKE_CXX_FLAGS=-j4 or the like because some comment "in the
internet" seemed to suggest this. However, like I already feared:
this passes the option to the compiler call - and that is the
wrong address for it, so I get an error message.
> > > 
> > > > > > Basically I think that it is 99% a CMake question and maximum 1%
a QtCreator problem, so I am asking this question here.
> > > 
> > > > > > And now I am stuck - if not some friendly and knowing person can
help me out of this!
> > > 
> > > Thanks for any helpful hint!
> > > Cornelis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180216/c4b8e607/attachment.html>

From annulen at yandex.ru  Fri Feb 16 13:35:26 2018
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Fri, 16 Feb 2018 21:35:26 +0300
Subject: [CMake] Parallel build setup question
In-Reply-To: <1518805927.10410.64.camel@bockemuehl.ch>
References: <1518798676.10410.55.camel@bockemuehl.ch>
 <634C2184-8BE9-4B8D-90E1-5D44DACB67DE@gmail.com>
 <1518801613.10410.59.camel@bockemuehl.ch> <20661518801921@web50j.yandex.ru>
 <1518805927.10410.64.camel@bockemuehl.ch>
Message-ID: <2212331518806126@web32g.yandex.ru>



16.02.2018, 21:32, "Cornelis Bockem?hl" <cornelis at bockemuehl.ch>:
> Thanks - that did the trick!
>
> And indeed by entering -j4 in the "Tool arguments" field, the build command changes "magically" into "cmake --build . --target all -- -j4" - with the "--" to pass the argument further to gmake.
>
> Actually compile time of my project after a "clean" went down from 23 to 14 min, thus reduction factor 1.6 with 4 processors: I tend to attribute the diffference to "almost 4" to the nature of my project where gmake seems not to see too many opportunities for parallel processing. Maybe it works always module by module, or whatever.
>
> Anyway, my question is answered - thanks again!

Note that if you used Ninja generator, it would use all cores by default.

>
> Regards,
> Cornelis
>
> Am Freitag, den 16.02.2018, 20:25 +0300 schrieb Konstantin Tokarev:
>> 16.02.2018, 20:20, "Cornelis Bockem?hl" <cornelis at bockemuehl.ch>:
>>> Thanks for your hints! And you are right: it is still interesting to know how QtCreator is actually invoking and using cmake.
>>
>> You should go to project settings and change cmake --build arguments there
>>
>>> This is the beginning of a log that the QtCreator was generating during a build. Actually with two modules where nothing had to be done, but still showing how cmake and gmake are being invoked - and all a bit above my understanding of the two tools:
>>>
>>> ===================================
>>> /usr/bin/cmake -H/Sources/GitLinux/RMT -B/BinariesLinux/RMT/Debug --check-build-system CMakeFiles/Makefile.cmake 0
>>> /usr/bin/cmake -E cmake_progress_start /BinariesLinux/RMT/Debug/CMakeFiles /BinariesLinux/RMT/Debug/CMakeFiles/progress.marks
>>> /usr/bin/gmake -f CMakeFiles/Makefile2 all
>>> gmake[1]: Entering directory '/BinariesLinux/RMT/Debug'
>>> /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make CMakeFiles/FirstModule.dir/depend
>>> gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
>>> cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug/CMakeFiles/FirstModule.dir/DependInfo.cmake --color=
>>> gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
>>> /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make CMakeFiles/FirstModule.dir/build
>>> gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
>>> gmake[2]: Nothing to be done for 'CMakeFiles/FirstModule.dir/build'.
>>> gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
>>> [??3%] Built target FirstModule
>>> /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make CMakeFiles/SecondModule.dir/depend
>>> gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
>>> cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug/CMakeFiles/SecondModule.dir/DependInfo.cmake --color=
>>> gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
>>> /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make CMakeFiles/SecondModule.dir/build
>>> gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
>>> gmake[2]: Nothing to be done for 'CMakeFiles/SecondModule.dir/build'.
>>> gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
>>> [??6%] Built target SecondModule
>>> ...
>>> ===========================================
>>>
>>> For example I do not really understand all the parameters that are passed to cmake - and I do not find them in the documentation either (like -H, -B or --check-build-system...
>>>
>>> Regards,
>>> Cornelis
>>>
>>> Am Freitag, den 16.02.2018, 08:59 -0800 schrieb Michael Ellery:
>>>> I don?t know anything about QTCreator, but the question really boils down to how to get your IDE to pass extra args to the build tool - it?s not really a cmake issue except to the extent that CMake can be used to invoke the build step (after it has been used to generate the build). It sounds like QT uses ?cmake --build? to do the build phase (which makes sense), so you just need to add your ?-j N? argument to the build step invocation. If you believe this: https://doc.qt.io/qtcreator/creator-build-settings.html, then it sounds like maybe ?Tool Arguments? is what you want (see ?CMake Build Steps?) ? BTW, the way I do this myself (since I don?t use an IDE) is something like ?cmake --build . -- -j 8? where the double dash stops shell argument processing and effectively passes everything else on to the build tool that cmake ultimately invokes (e.g. make or ninja or msbuild, etc.) HTH, Mike On Feb 16, 2018, at 8:31 AM, Cornelis Bockem?hl <cornelis at bockemuehl.ch> wrote: Hello, Somehow I seem to miss some crucial point regarding setup for parallel build with CMake, so I would be happy if somebody can push me the last few millimeters to hit my target! My configuration is on OpenSuse Linux (Leap - 64-bit), working with QtCreator and CMake, using the "make" configuration. I learned from "the internet" that actually I would have to pass a -jN option to make or gmake (with N being the max number of processors I want to use). Or even more elegant: go for a -lN option to somehow balance the load. Sounds good! But what I do not see is how to pass these nice options to make through CMake and QtCreator! One attempt was to specify CMAKE_CXX_FLAGS=-j4 or the like because some comment "in the internet" seemed to suggest this. However, like I already feared: this passes the option to the compiler call - and that is the wrong address for it, so I get an error message. Basically I think that it is 99% a CMake question and maximum 1% a QtCreator problem, so I am asking this question here. And now I am stuck - if not some friendly and knowing person can help me out of this! Thanks for any helpful hint! Cornelis


--?
Regards,
Konstantin

From robert.maynard at kitware.com  Fri Feb 16 14:33:12 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Fri, 16 Feb 2018 14:33:12 -0500
Subject: [CMake] OBJECT Library Type
In-Reply-To: <0976b14b68ad42ba84af166b54ec0a8b@HQMAIL102.nvidia.com>
References: <0976b14b68ad42ba84af166b54ec0a8b@HQMAIL102.nvidia.com>
Message-ID: <CAFzjYVruCYNOf3KYCgHk0-eJ7hU1fCqQK3pX0yXOmjPZ++ss+Q@mail.gmail.com>

As the error message states an OBJECT library can't consume other
OBJECT libraries. When creating the actual library you will have to
explicitly state what $<TARGET_OBJECTS:?> you need.

If you are just looking at a way to simplify the logic for the
consuming library you should look at doing the following:

1. Use a global property to store what OBJECT targets should be consumed

2. Wait for https://gitlab.kitware.com/cmake/cmake/merge_requests/1524
to be finished.

On Fri, Feb 16, 2018 at 12:29 PM, Simone Atzeni <satzeni at nvidia.com> wrote:
> Hi,
>
>
>
> I am trying to merge together two ?OBJECT? libraries.
>
> I am following the tutorial at:
> https://cmake.org/Wiki/CMake/Tutorials/Object_Library
>
>
>
> However, in my case I have more level of folder nesting, and at the parent
> level I would like to merge two ?OBJECT? libraries and only at the top I
> want to create the actual library.
>
>
>
> I tried with:
>
>
>
> add_library(common OBJECT "$<TARGET_OBJECTS:A> $<TARGET_OBJECTS:B>
> $<TARGET_OBJECTS:C>")
>
>
>
> But I get the following error:
>
>
>
> -----------------------------------------------------------------------------------------------------
>
> CMake Error at lib/common/CMakeLists.txt:31 (add_library):
>
>   OBJECT library "common" contains:
>
>
>
>     file1.cpp.o
>
>     file2.cpp.o
>
>     file3.cpp.o
>
>     ?
>
>
>
>   but may contain only sources that compile, header files, and other files
>
>   that would not affect linking of a normal library.
>
>
>
> CMake Error at lib/common/CMakeLists.txt:31 (add_library):
>
>   Only executables and non-OBJECT libraries may reference target objects.
>
>
>
> What?s the correct way to do this?
>
>
>
> Thanks.
>
> Simone
>
>
>
> ________________________________
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential information.  Any unauthorized review, use, disclosure
> or distribution is prohibited.  If you are not the intended recipient,
> please contact the sender by reply email and destroy all copies of the
> original message.
> ________________________________
>
> --
>
> 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
>

From cornelis at bockemuehl.ch  Sat Feb 17 02:06:53 2018
From: cornelis at bockemuehl.ch (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=)
Date: Sat, 17 Feb 2018 08:06:53 +0100
Subject: [CMake] Parallel build setup question
In-Reply-To: <2212331518806126@web32g.yandex.ru>
References: <1518798676.10410.55.camel@bockemuehl.ch>
 <634C2184-8BE9-4B8D-90E1-5D44DACB67DE@gmail.com>
 <1518801613.10410.59.camel@bockemuehl.ch> <20661518801921@web50j.yandex.ru>
 <1518805927.10410.64.camel@bockemuehl.ch>
 <2212331518806126@web32g.yandex.ru>
Message-ID: <1518851213.10410.65.camel@bockemuehl.ch>

Thanks also for this hint: I will give it a try!

Regards, Cornelis

Am Freitag, den 16.02.2018, 21:35 +0300 schrieb Konstantin Tokarev:
> 
> > 16.02.2018, 21:32, "Cornelis Bockem?hl" <cornelis at bockemuehl.ch>:
> > Thanks - that did the trick!
> > 
> > > > > > And indeed by entering -j4 in the "Tool arguments" field, the build
command changes "magically" into "cmake --build . --target all --
-j4" - with the "--" to pass the argument further to gmake.
> > 
> > > > > > > > > > > > Actually compile time of my project after a "clean" went down from
23 to 14 min, thus reduction factor 1.6 with 4 processors: I tend
to attribute the diffference to "almost 4" to the nature of my
project where gmake seems not to see too many opportunities for
parallel processing. Maybe it works always module by module, or
whatever.
> > 
> > Anyway, my question is answered - thanks again!
> 
> > Note that if you used Ninja generator, it would use all cores by
default.
> 
> > 
> > Regards,
> > Cornelis
> > 
> > Am Freitag, den 16.02.2018, 20:25 +0300 schrieb Konstantin Tokarev:
> > > > > > 16.02.2018, 20:20, "Cornelis Bockem?hl" <cornelis at bockemuehl.ch>:
> > > > > > > > > > > > Thanks for your hints! And you are right: it is still
interesting to know how QtCreator is actually invoking and
using cmake.
> > > 
> > > > > > You should go to project settings and change cmake --build
arguments there
> > > 
> > > > > > > > > > > > > > > > > > > > This is the beginning of a log that the QtCreator was
generating during a build. Actually with two modules where
nothing had to be done, but still showing how cmake and gmake
are being invoked - and all a bit above my understanding of the
two tools:
> > > > 
> > > > ===================================
> > > > > > > > > > > > /usr/bin/cmake -H/Sources/GitLinux/RMT
-B/BinariesLinux/RMT/Debug --check-build-system
CMakeFiles/Makefile.cmake 0
> > > > > > > > > > > > /usr/bin/cmake -E cmake_progress_start
/BinariesLinux/RMT/Debug/CMakeFiles
/BinariesLinux/RMT/Debug/CMakeFiles/progress.marks
> > > > /usr/bin/gmake -f CMakeFiles/Makefile2 all
> > > > gmake[1]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make
CMakeFiles/FirstModule.dir/depend
> > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > > > > > > > > > > > cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E cmake_depends
"Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT
/BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug
/BinariesLinux/RMT/Debug/CMakeFiles/FirstModule.dir/DependInfo.
cmake --color=
> > > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > > > > > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make
CMakeFiles/FirstModule.dir/build
> > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > gmake[2]: Nothing to be done for
'CMakeFiles/FirstModule.dir/build'.
> > > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > > > [??3%] Built target FirstModule
> > > > > > > > /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make
CMakeFiles/SecondModule.dir/depend
> > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > > > > > > > > > > > cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E cmake_depends
"Unix Makefiles" /Sources/GitLinux/RMT /Sources/GitLinux/RMT
/BinariesLinux/RMT/Debug /BinariesLinux/RMT/Debug
/BinariesLinux/RMT/Debug/CMakeFiles/SecondModule.dir/DependInfo
.cmake --color=
> > > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > > > > > > > /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make
CMakeFiles/SecondModule.dir/build
> > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > gmake[2]: Nothing to be done for
'CMakeFiles/SecondModule.dir/build'.
> > > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > > > [??6%] Built target SecondModule
> > > > ...
> > > > ===========================================
> > > > 
> > > > > > > > > > > > For example I do not really understand all the parameters that
are passed to cmake - and I do not find them in the
documentation either (like -H, -B or --check-build-system...
> > > > 
> > > > Regards,
> > > > Cornelis
> > > > 
> > > > Am Freitag, den 16.02.2018, 08:59 -0800 schrieb Michael Ellery:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don?t know anything about QTCreator, but the question
really boils down to how to get your IDE to pass extra args
to the build tool - it?s not really a cmake issue except to
the extent that CMake can be used to invoke the build step
(after it has been used to generate the build). It sounds
like QT uses ?cmake --build? to do the build phase (which
makes sense), so you just need to add your ?-j N? argument to
the build step invocation. If you believe this: https://doc.q
t.io/qtcreator/creator-build-settings.html, then it sounds
like maybe ?Tool Arguments? is what you want (see ?CMake
Build Steps?) ? BTW, the way I do this myself (since I don?t
use an IDE) is something like ?cmake --build . -- -j 8? where
the double dash stops shell argument processing and
effectively passes everything else on to the build tool that
cmake ultimately invokes (e.g. make or ninja or msbuild,
etc.) HTH, Mike On Feb 16, 2018, at 8:31 AM, Cornelis
Bockem?hl <cornelis at bockemuehl.ch> wrote: Hello, Somehow I
seem to miss some crucial point regarding setup for parallel
build with CMake, so I would be happy if somebody can push me
the last few millimeters to hit my target! My configuration
is on OpenSuse Linux (Leap - 64-bit), working with QtCreator
and CMake, using the "make" configuration. I learned from
"the internet" that actually I would have to pass a -jN
option to make or gmake (with N being the max number of
processors I want to use). Or even more elegant: go for a -lN
option to somehow balance the load. Sounds good! But what I
do not see is how to pass these nice options to make through
CMake and QtCreator! One attempt was to specify
CMAKE_CXX_FLAGS=-j4 or the like because some comment "in the
internet" seemed to suggest this. However, like I already
feared: this passes the option to the compiler call - and
that is the wrong address for it, so I get an error message.
Basically I think that it is 99% a CMake question and maximum
1% a QtCreator problem, so I am asking this question here.
And now I am stuck - if not some friendly and knowing person
can help me out of this! Thanks for any helpful hint!
Cornelis
> 
> 
> --?
> Regards,
> Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180217/35b094fb/attachment.html>

From cmake at a.legko.ru  Sat Feb 17 07:29:17 2018
From: cmake at a.legko.ru (cmake at a.legko.ru)
Date: Sat, 17 Feb 2018 15:29:17 +0300 (MSK)
Subject: [CMake] define addition search path for .cmake files
Message-ID: <alpine.LNX.2.21.1802171528350.22430@scil.sinp.msu.ru>



Hi!

So, I have separate installation (root) path for a project, many libs 
there, installing their own *.cmake files (VTK,
etc.) files into that root.
How to define (add) alternative paths for cmake to search for *.cmake 
files?
Testing environment variables without any effect (CMAKE_*).
The idea to change original cmake files in each source package is not a 
good one.


Thanx!


From calebwherry at gmail.com  Sat Feb 17 09:18:54 2018
From: calebwherry at gmail.com (J. Caleb Wherry)
Date: Sat, 17 Feb 2018 14:18:54 +0000
Subject: [CMake] define addition search path for .cmake files
In-Reply-To: <alpine.LNX.2.21.1802171528350.22430@scil.sinp.msu.ru>
References: <alpine.LNX.2.21.1802171528350.22430@scil.sinp.msu.ru>
Message-ID: <CAJxY6XpXLRf4HKKPrMaRQ7=mtQwCgjcnsQ=NgRV50CzJuJWz+Q@mail.gmail.com>

https://cmake.org/cmake/help/latest/variable/CMAKE_MODULE_PATH.html#variable:CMAKE_MODULE_PATH

Should do the trick. Set it before you call project, not sure if it works
after that or not.

-Caleb

On Sat, Feb 17, 2018 at 7:47 AM <cmake at a.legko.ru> wrote:

>
>
> Hi!
>
> So, I have separate installation (root) path for a project, many libs
> there, installing their own *.cmake files (VTK,
> etc.) files into that root.
> How to define (add) alternative paths for cmake to search for *.cmake
> files?
> Testing environment variables without any effect (CMAKE_*).
> The idea to change original cmake files in each source package is not a
> good one.
>
>
> Thanx!
>
> --
>
> 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
>
-- 
Sent from my iPhone 4s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180217/0c2f6fce/attachment-0001.html>

From zanchey at ucc.gu.uwa.edu.au  Sun Feb 18 00:17:34 2018
From: zanchey at ucc.gu.uwa.edu.au (David Adam)
Date: Sun, 18 Feb 2018 13:17:34 +0800 (AWST)
Subject: [CMake] Ignore installation failure
Message-ID: <alpine.DEB.2.20.1802181311331.1675@motsugo.ucc.gu.uwa.edu.au>

Hi there,

Our project installs an empty directory for other programs to drop files 
in, the location of which is overrideable with a cache variable. Some 
environments set the location of this directory outside the writeable 
area and create it themselves, so I'd like to set up CMake so that it 
tries to create the directory but skips over it if there is a failure.

At the moment we use:

SET(extra_completionsdir
    ${rel_datadir}/fish/vendor_completions.d
    CACHE STRING "Path for extra completions")
INSTALL(DIRECTORY DESTINATION ${extra_completionsdir})

but that fails if the destination is not writeable.

Is there an idiomatic way of ignoring a failed installation step? At the 
moment, I'm trying various install(script code execute_process(... 
incantations, but I'm aware there's lots of corner cases with DESTDIR and 
so on.

Thanks

David Adam
zanchey at ucc.gu.uwa.edu.au

From cfsworks at gmail.com  Sun Feb 18 05:49:30 2018
From: cfsworks at gmail.com (Sam Edwards)
Date: Sun, 18 Feb 2018 03:49:30 -0700
Subject: [CMake] Generator expressions: Identifying when they're used in a
 custom command?
Message-ID: <CAH5Ym4jzYto07cb-i4HnRahBWO92FD5oNJ5f-fEugCANDfFNWg@mail.gmail.com>

Hi list!

I'm working on a CMake buildsystem for the Panda3D project. The project is
essentially a C++ 3D engine with its own custom Python binding generator
known as Interrogate. The basic idea is that after a library's C++ code is
compiled in the usual way, the C++ source files and headers are passed to
Interrogate which parses a (very large) subset of the C++ language and
generates suitable C++ to bind the library to the CPython API. This is then
compiled into a CPython extension module and linked against the C++ code.

Because Interrogate is invoked in much the same way as a compiler, and as
such needs to know the include search path, I use a generator expression to
read the INTERFACE_INCLUDE_DIRECTORIES target property for the library in
question and produce -I flags for Interrogate. So far, so good.

But again, Interrogate only knows a subset of C++, and while the Panda3D
core is written with this in mind, this is a problem for third-party header
files which might go outside of this subset. To solve this, the Panda3D
source repository contains a "parser-inc" directory which contains
stubbed-out header files solely intended for Interrogate. This means
*hiding* the third-party package paths from Interrogate when it walks over
INTERFACE_INCLUDE_DIRECTORIES.

"No problem," I thought, "generator expressions do exactly that." So I
wrote a generator expression that looks at the highest target and, if it
has the IS_INTERROGATE property, hides it.

However, when it came time to actually set this IS_INTERROGATE property, I
could find no way to apply it to a custom command. I guess this makes sense
- custom commands aren't targets, after all. But I couldn't convert my
custom command to a custom target, because it produces a C++ source file
and I need to use OUTPUT to let CMake know where that source file comes
from, and you can't use OUTPUT and TARGET together in add_custom_command.

At the end of the day, I ended up using this
<https://github.com/panda3d/panda3d/commit/23996559206445a8016032d207bfbea320ff088e>
as
my workaround. It's really quite awful, and I'm not happy at all about the
idea of maintaining it, but it does get the job done. *Thus, *my two
questions are:
1) Is there a less messy way of accomplishing what I'm trying to do (that
works in CMake 2.8.12+)? and
2) If not, should CMake be given an informational generator expression
going forward that can determine context when targets aren't involved?

Or put another way, "Am I missing something, or is this actually a
shortcoming in CMake?"

Thank you for your time, and I hope you're having a good day,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180218/3409f448/attachment.html>

From cornelis at bockemuehl.ch  Sun Feb 18 11:36:33 2018
From: cornelis at bockemuehl.ch (Cornelis =?ISO-8859-1?Q?Bockem=FChl?=)
Date: Sun, 18 Feb 2018 17:36:33 +0100
Subject: [CMake] Parallel build setup question
In-Reply-To: <1518851213.10410.65.camel@bockemuehl.ch>
References: <1518798676.10410.55.camel@bockemuehl.ch>
 <634C2184-8BE9-4B8D-90E1-5D44DACB67DE@gmail.com>
 <1518801613.10410.59.camel@bockemuehl.ch> <20661518801921@web50j.yandex.ru>
 <1518805927.10410.64.camel@bockemuehl.ch>
 <2212331518806126@web32g.yandex.ru>
 <1518851213.10410.65.camel@bockemuehl.ch>
Message-ID: <1518971793.10410.78.camel@bockemuehl.ch>

Just to close this thread: Also the ninja tipp turned out to be a very
good one! I did the same full built (clear - rebuild) with ninja
instead of make -j4 and times were more or less comparable: from
initially 23 minutes down to 13-14 with make, and 12-13 with ninja.
However, what is much more helpful in practical programming work is the
fact that if I change only one or two files, ninja "knows" this
instantaneously, i.e. no perceivable overhead to find out about
outdated files, while make still takes maybe half a minute or such for
checking.

And since this is a very common case during development I decided to
stay with the QtCreator - CMake - ninja "team of tools"!

Regards, Cornelis

Am Samstag, den 17.02.2018, 08:06 +0100 schrieb Cornelis Bockem?hl:
> Thanks also for this hint: I will give it a try!
> 
> Regards, Cornelis
> 
> Am Freitag, den 16.02.2018, 21:35 +0300 schrieb Konstantin Tokarev:
> > > > 16.02.2018, 21:32, "Cornelis Bockem?hl" <cornelis at bockemuehl.ch>:
> > > Thanks - that did the trick!
> > > 
> > > > > > > > > > > > And indeed by entering -j4 in the "Tool arguments" field, the
build command changes "magically" into "cmake --build . --target
all -- -j4" - with the "--" to pass the argument further to
gmake.
> > > 
> > > > > > > > > > > > > > > > > > Actually compile time of my project after a "clean" went down
from 23 to 14 min, thus reduction factor 1.6 with 4 processors: I
tend to attribute the diffference to "almost 4" to the nature of
my project where gmake seems not to see too many opportunities
for parallel processing. Maybe it works always module by module,
or whatever.
> > > 
> > > Anyway, my question is answered - thanks again!
> > 
> > > > Note that if you used Ninja generator, it would use all cores by
default.
> > 
> > > 
> > > Regards,
> > > Cornelis
> > > 
> > > > > > Am Freitag, den 16.02.2018, 20:25 +0300 schrieb Konstantin
Tokarev:
> > > > > > > > 16.02.2018, 20:20, "Cornelis Bockem?hl" <cornelis at bockemuehl.ch
>:
> > > > > > > > > > > > > > > Thanks for your hints! And you are right: it is still
interesting to know how QtCreator is actually invoking and
using cmake.
> > > > 
> > > > > > > > You should go to project settings and change cmake --build
arguments there
> > > > 
> > > > > > > > > > > > > > > > > > > > > > > > > This is the beginning of a log that the QtCreator was
generating during a build. Actually with two modules where
nothing had to be done, but still showing how cmake and gmake
are being invoked - and all a bit above my understanding of
the two tools:
> > > > > 
> > > > > ===================================
> > > > > > > > > > > > > > > /usr/bin/cmake -H/Sources/GitLinux/RMT
-B/BinariesLinux/RMT/Debug --check-build-system
CMakeFiles/Makefile.cmake 0
> > > > > > > > > > > > > > > /usr/bin/cmake -E cmake_progress_start
/BinariesLinux/RMT/Debug/CMakeFiles
/BinariesLinux/RMT/Debug/CMakeFiles/progress.marks
> > > > > /usr/bin/gmake -f CMakeFiles/Makefile2 all
> > > > > gmake[1]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make
CMakeFiles/FirstModule.dir/depend
> > > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E
cmake_depends "Unix Makefiles" /Sources/GitLinux/RMT
/Sources/GitLinux/RMT /BinariesLinux/RMT/Debug
/BinariesLinux/RMT/Debug
/BinariesLinux/RMT/Debug/CMakeFiles/FirstModule.dir/DependInf
o.cmake --color=
> > > > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > /usr/bin/gmake -f CMakeFiles/FirstModule.dir/build.make
CMakeFiles/FirstModule.dir/build
> > > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > gmake[2]: Nothing to be done for
'CMakeFiles/FirstModule.dir/build'.
> > > > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > > > > [??3%] Built target FirstModule
> > > > > > > > > > /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make
CMakeFiles/SecondModule.dir/depend
> > > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > cd /BinariesLinux/RMT/Debug && /usr/bin/cmake -E
cmake_depends "Unix Makefiles" /Sources/GitLinux/RMT
/Sources/GitLinux/RMT /BinariesLinux/RMT/Debug
/BinariesLinux/RMT/Debug
/BinariesLinux/RMT/Debug/CMakeFiles/SecondModule.dir/DependIn
fo.cmake --color=
> > > > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > /usr/bin/gmake -f CMakeFiles/SecondModule.dir/build.make
CMakeFiles/SecondModule.dir/build
> > > > > gmake[2]: Entering directory '/BinariesLinux/RMT/Debug'
> > > > > > > > > > gmake[2]: Nothing to be done for
'CMakeFiles/SecondModule.dir/build'.
> > > > > gmake[2]: Leaving directory '/BinariesLinux/RMT/Debug'
> > > > > [??6%] Built target SecondModule
> > > > > ...
> > > > > ===========================================
> > > > > 
> > > > > > > > > > > > > > > For example I do not really understand all the parameters
that are passed to cmake - and I do not find them in the
documentation either (like -H, -B or --check-build-system...
> > > > > 
> > > > > Regards,
> > > > > Cornelis
> > > > > 
> > > > > > > > > > Am Freitag, den 16.02.2018, 08:59 -0800 schrieb Michael
Ellery:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I don?t know anything about QTCreator, but the question
really boils down to how to get your IDE to pass extra args
to the build tool - it?s not really a cmake issue except to
the extent that CMake can be used to invoke the build step
(after it has been used to generate the build). It sounds
like QT uses ?cmake --build? to do the build phase (which
makes sense), so you just need to add your ?-j N? argument
to the build step invocation. If you believe this: https://
doc.qt.io/qtcreator/creator-build-settings.html, then it
sounds like maybe ?Tool Arguments? is what you want (see
?CMake Build Steps?) ? BTW, the way I do this myself (since
I don?t use an IDE) is something like ?cmake --build . --
-j 8? where the double dash stops shell argument processing
and effectively passes everything else on to the build tool
that cmake ultimately invokes (e.g. make or ninja or
msbuild, etc.) HTH, Mike On Feb 16, 2018, at 8:31 AM,
Cornelis Bockem?hl <cornelis at bockemuehl.ch> wrote: Hello,
Somehow I seem to miss some crucial point regarding setup
for parallel build with CMake, so I would be happy if
somebody can push me the last few millimeters to hit my
target! My configuration is on OpenSuse Linux (Leap - 64-
bit), working with QtCreator and CMake, using the "make"
configuration. I learned from "the internet" that actually
I would have to pass a -jN option to make or gmake (with N
being the max number of processors I want to use). Or even
more elegant: go for a -lN option to somehow balance the
load. Sounds good! But what I do not see is how to pass
these nice options to make through CMake and QtCreator! One
attempt was to specify CMAKE_CXX_FLAGS=-j4 or the like
because some comment "in the internet" seemed to suggest
this. However, like I already feared: this passes the
option to the compiler call - and that is the wrong address
for it, so I get an error message. Basically I think that
it is 99% a CMake question and maximum 1% a QtCreator
problem, so I am asking this question here. And now I am
stuck - if not some friendly and knowing person can help me
out of this! Thanks for any helpful hint! Cornelis
> > 
> > 
> > --?
> > Regards,
> > Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180218/65dee9d5/attachment-0001.html>

From irwin at beluga.phys.uvic.ca  Sun Feb 18 17:09:49 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Sun, 18 Feb 2018 14:09:49 -0800 (PST)
Subject: [CMake] Generator expressions: Identifying when they're used in
 a custom command?
In-Reply-To: <CAH5Ym4jzYto07cb-i4HnRahBWO92FD5oNJ5f-fEugCANDfFNWg@mail.gmail.com>
References: <CAH5Ym4jzYto07cb-i4HnRahBWO92FD5oNJ5f-fEugCANDfFNWg@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1802181355540.10563@enira.zlyna.ubzr>

On 2018-02-18 03:49-0700 Sam Edwards wrote:

> However, when it came time to actually set this IS_INTERROGATE property, I
> could find no way to apply it to a custom command. I guess this makes sense
> - custom commands aren't targets, after all. But I couldn't convert my
> custom command to a custom target, because it produces a C++ source file
> and I need to use OUTPUT to let CMake know where that source file comes
> from, and you can't use OUTPUT and TARGET together in add_custom_command.

Hi Sam:

It's quite common for each custom command to have a corresponding
custom target that DEPENDS on the OUTPUT of the custom command.  So
building the target part of that pair means the custom command is
executed *only if* the OUTPUT from it is out of date.

If you used that paradigm for the custom commands you refer to
above (where each such custom command is paired with a unique target
via the DEPENDS of the latter) could you not set the IS_INTERROGATE
property for the custom target part of of each pair whenever that
property is relevant?

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
__________________________

From cfsworks at gmail.com  Sun Feb 18 21:47:09 2018
From: cfsworks at gmail.com (Sam Edwards)
Date: Sun, 18 Feb 2018 19:47:09 -0700
Subject: [CMake] Generator expressions: Identifying when they're used in
 a custom command?
In-Reply-To: <alpine.DEB.2.11.1802181355540.10563@enira.zlyna.ubzr>
References: <CAH5Ym4jzYto07cb-i4HnRahBWO92FD5oNJ5f-fEugCANDfFNWg@mail.gmail.com>
 <alpine.DEB.2.11.1802181355540.10563@enira.zlyna.ubzr>
Message-ID: <CAH5Ym4j9tDDv41QWHo1+L6uebZa_kPpN9XciwdiKSt4aNe_FMg@mail.gmail.com>

Alan,

Thanks for your help! I tried to implement that paradigm myself in a small
example CMakeLists.txt which I've attached, but the addition of a depending
custom target doesn't seem to change the context of the 'this' target. In
other words, the IS_INTERROGATE property is still read from fake_target and
not depending_target.

Could you take a look and clarify what I'm not doing quite right?

Best,
Sam

On Sun, Feb 18, 2018 at 3:09 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
wrote:

> On 2018-02-18 03:49-0700 Sam Edwards wrote:
>
> However, when it came time to actually set this IS_INTERROGATE property, I
>> could find no way to apply it to a custom command. I guess this makes
>> sense
>> - custom commands aren't targets, after all. But I couldn't convert my
>> custom command to a custom target, because it produces a C++ source file
>> and I need to use OUTPUT to let CMake know where that source file comes
>> from, and you can't use OUTPUT and TARGET together in add_custom_command.
>>
>
> Hi Sam:
>
> It's quite common for each custom command to have a corresponding
> custom target that DEPENDS on the OUTPUT of the custom command.  So
> building the target part of that pair means the custom command is
> executed *only if* the OUTPUT from it is out of date.
>
> If you used that paradigm for the custom commands you refer to
> above (where each such custom command is paired with a unique target
> via the DEPENDS of the latter) could you not set the IS_INTERROGATE
> property for the custom target part of of each pair whenever that
> property is relevant?
>
> 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
> __________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180218/95a94058/attachment.html>
-------------- next part --------------
cmake_minimum_required(VERSION 2.8.12)

# Create a fake target, with a property with a generator expression
add_custom_target(base_target)
set_target_properties(base_target PROPERTIES
  IS_INTERROGATE 0
  INTERFACE_INCLUDE_DIRECTORIES "IS_INTERROGATE=$<BOOL:$<TARGET_PROPERTY:IS_INTERROGATE>>")

add_custom_target(fake_target)
set_target_properties(fake_target PROPERTIES
  IS_INTERROGATE 0
  INTERFACE_INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:base_target,INTERFACE_INCLUDE_DIRECTORIES>")

# This is the script that we run with the custom command which generates our
# C source code.
set(script_path "${CMAKE_CURRENT_BINARY_DIR}/make_printer_program.py")
FILE(WRITE "${script_path}" "
import sys

arg = sys.argv[1]

print('#include <stdio.h>')
print('int main() { puts(\"%s\"); return 0; }' % arg)
")

# Run the generation script
find_package(PythonInterp QUIET REQUIRED)
add_custom_command(OUTPUT source.c
  COMMAND "${PYTHON_EXECUTABLE}" "${script_path}" "$<TARGET_PROPERTY:fake_target,INTERFACE_INCLUDE_DIRECTORIES>" > source.c)

# Add a custom target to depend on source.c, as suggested
add_custom_target(depending_target)
set_target_properties(depending_target PROPERTIES
  IS_INTERROGATE 1)

# Compile the output
add_executable(output source.c)
# Make sure we depend on the custom target
add_dependencies(output depending_target)

From irwin at beluga.phys.uvic.ca  Mon Feb 19 14:05:21 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Mon, 19 Feb 2018 11:05:21 -0800 (PST)
Subject: [CMake] Generator expressions: Identifying when they're used in
 a custom command?
In-Reply-To: <CAH5Ym4j9tDDv41QWHo1+L6uebZa_kPpN9XciwdiKSt4aNe_FMg@mail.gmail.com>
References: <CAH5Ym4jzYto07cb-i4HnRahBWO92FD5oNJ5f-fEugCANDfFNWg@mail.gmail.com>
 <alpine.DEB.2.11.1802181355540.10563@enira.zlyna.ubzr>
 <CAH5Ym4j9tDDv41QWHo1+L6uebZa_kPpN9XciwdiKSt4aNe_FMg@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1802190951150.10563@enira.zlyna.ubzr>

On 2018-02-18 19:47-0700 Sam Edwards wrote:

> Alan,
>
> Thanks for your help! I tried to implement that paradigm myself in a small
> example CMakeLists.txt which I've attached, but the addition of a depending
> custom target doesn't seem to change the context of the 'this' target. In
> other words, the IS_INTERROGATE property is still read from fake_target and
> not depending_target.
>
> Could you take a look and clarify what I'm not doing quite right?

Hi Sam:

I just looked at the custom command part of it which was

add_custom_command(OUTPUT source.c
   COMMAND "${PYTHON_EXECUTABLE}" "${script_path}"
"$<TARGET_PROPERTY:fake_target,INTERFACE_INCLUDE_DIRECTORIES>" >
source.c)

# Add a custom target to depend on source.c, as suggested
add_custom_target(depending_target)
set_target_properties(depending_target PROPERTIES
   IS_INTERROGATE 1)

# Compile the output
add_executable(output source.c)
# Make sure we depend on the custom target
add_dependencies(output depending_target)

I would change the above to the following:

add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/source.c
   COMMAND "${PYTHON_EXECUTABLE}" "${script_path}"
"$<TARGET_PROPERTY:fake_target,INTERFACE_INCLUDE_DIRECTORIES>" >
source.c)

# Add a custom target to depend on source.c, as suggested
add_custom_target(depending_target
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/source.c)
set_target_properties(depending_target PROPERTIES
   IS_INTERROGATE 1)

# Compile the output
add_executable(output ${CMAKE_CURRENT_BINARY_DIR}/source.c)

Here are my reasons for the suggested changes.

* Absolute path when referring to source.c.  I am not sure whether
   this is stylistic or required, but this style works for me.

* Use DEPENDS to make the custom target depend on the custom command.
   This change is essential.

* Drop add_dependency.  The typical way you let CMake know that source
code is generated is with the GENERATED property which should take
care of all dependencies.  However,
<https://cmake.org/cmake/help/v3.11/prop_sf/GENERATED.html> implies to
me you do not even need to specify the GENERATED property for
${CMAKE_CURRENT_BINARY_DIR}/source.c.  So try the above and see, and
if it does not work try using the GENERATED property.

* Set a much higher minimum CMake version.  You mentioned CMake
2.8.12+ in your original post, but there are some fundamental
differences between CMake-2 and CMake-3, and in my opinion you are
just making a rod for your back if you try to make your build system
work for both.  For example, I have no idea whether the above approach
will work for 2.8.12.  Another constraint is early versions of CMake-3 were
frankly buggy.  So I use a minimum version of CMake-3.6.2 for all my
build systems, and that works well for me.  Note all modern
Linux distributions, Cygwin, MinGW-w64/MSYS2, HomeBrew, MacPorts, and
Fink all provide that version of CMake or higher, and Kitware provides
CMake for that version and higher for MSVC as well so that choice of minimum
CMake version should inconvenience very few of your potential users.

I hope these suggested changes help you toward your broader goal.

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
__________________________

From cfsworks at gmail.com  Mon Feb 19 15:03:26 2018
From: cfsworks at gmail.com (Sam Edwards)
Date: Mon, 19 Feb 2018 13:03:26 -0700
Subject: [CMake] Generator expressions: Identifying when they're used in
 a custom command?
In-Reply-To: <alpine.DEB.2.11.1802190951150.10563@enira.zlyna.ubzr>
References: <CAH5Ym4jzYto07cb-i4HnRahBWO92FD5oNJ5f-fEugCANDfFNWg@mail.gmail.com>
 <alpine.DEB.2.11.1802181355540.10563@enira.zlyna.ubzr>
 <CAH5Ym4j9tDDv41QWHo1+L6uebZa_kPpN9XciwdiKSt4aNe_FMg@mail.gmail.com>
 <alpine.DEB.2.11.1802190951150.10563@enira.zlyna.ubzr>
Message-ID: <CAH5Ym4jTv9NsfYKvJznWyE6Vo4R9eH5QOeU33hKop5TuyvoQfg@mail.gmail.com>

Alan,

I'm kicking myself for leaving off the DEPENDS in add_custom_target as that
is the most essential part of what you suggested. Bah!

I tried copying in your changes verbatim and I'm still left with an output
that produces IS_INTERROGATE=0. This is on both 3.9.6 (my development
machine) and 2.8.12 (my testing VM). Does your version of CMake produce
IS_INTERROGATE=1 with your changes?

The rationale behind 2.8.12 is this is the version that ships with Ubuntu
Trusty and will probably be what's present if a user is simply told to
"install CMake" - although 3.5.1 is also available on that platform under
the cmake3 package, so I might be able to justify a minimum version of
either that or 3.0.1 (which is what's on backports-less Debian Jessie). I'd
have to bring it up with the project maintainer to see, but in any case
we're trying to follow a "stick with the same minimum version until we
encounter a bug we can't work around, then bump the minimum to the version
that fixes that bug" approach.

Thanks for your suggestions,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180219/9786a774/attachment.html>

From elvis.stansvik at orexplore.com  Mon Feb 19 15:45:11 2018
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Mon, 19 Feb 2018 21:45:11 +0100
Subject: [CMake] Generator expressions: Identifying when they're used in
 a custom command?
In-Reply-To: <CAH5Ym4jTv9NsfYKvJznWyE6Vo4R9eH5QOeU33hKop5TuyvoQfg@mail.gmail.com>
References: <CAH5Ym4jzYto07cb-i4HnRahBWO92FD5oNJ5f-fEugCANDfFNWg@mail.gmail.com>
 <alpine.DEB.2.11.1802181355540.10563@enira.zlyna.ubzr>
 <CAH5Ym4j9tDDv41QWHo1+L6uebZa_kPpN9XciwdiKSt4aNe_FMg@mail.gmail.com>
 <alpine.DEB.2.11.1802190951150.10563@enira.zlyna.ubzr>
 <CAH5Ym4jTv9NsfYKvJznWyE6Vo4R9eH5QOeU33hKop5TuyvoQfg@mail.gmail.com>
Message-ID: <CAE-7VJngTccgdyb8KjiGzgewLSRiZAOAKMqXKT6mbA9JkDtmPg@mail.gmail.com>

2018-02-19 21:03 GMT+01:00 Sam Edwards <cfsworks at gmail.com>:
> Alan,
>
> I'm kicking myself for leaving off the DEPENDS in add_custom_target as that
> is the most essential part of what you suggested. Bah!
>
> I tried copying in your changes verbatim and I'm still left with an output
> that produces IS_INTERROGATE=0. This is on both 3.9.6 (my development
> machine) and 2.8.12 (my testing VM). Does your version of CMake produce
> IS_INTERROGATE=1 with your changes?
>
> The rationale behind 2.8.12 is this is the version that ships with Ubuntu
> Trusty and will probably be what's present if a user is simply told to
> "install CMake" - although 3.5.1 is also available on that platform under
> the cmake3 package, so I might be able to justify a minimum version of
> either that or 3.0.1 (which is what's on backports-less Debian Jessie). I'd
> have to bring it up with the project maintainer to see, but in any case
> we're trying to follow a "stick with the same minimum version until we
> encounter a bug we can't work around, then bump the minimum to the version
> that fixes that bug" approach.
>
> Thanks for your suggestions,

Hm, I'm not sure I'm enough of a CMake ninja to understand this, but,
when I read in the docs:

$<TARGET_PROPERTY:prop>
    Value of the property prop on the target on which the generator
expression is evaluated.

And then see:

set_target_properties(base_target PROPERTIES
  IS_INTERROGATE 0
  INTERFACE_INCLUDE_DIRECTORIES
"IS_INTERROGATE=$<BOOL:$<TARGET_PROPERTY:IS_INTERROGATE>>")

Correct me if I'm wrong, but I think that
$<TARGET_PROPERTY:IS_INTERROGATE> here will always be the value of
IS_INTERROGATE on the base_target (so 0), since that's the target on
which the generator expression is evaluated? Or?

I think that's where the 0 in your output comes from in the end?

Elvis

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

From irwin at beluga.phys.uvic.ca  Mon Feb 19 18:21:25 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Mon, 19 Feb 2018 15:21:25 -0800 (PST)
Subject: [CMake] Generator expressions: Identifying when they're used in
 a custom command?
In-Reply-To: <CAH5Ym4jTv9NsfYKvJznWyE6Vo4R9eH5QOeU33hKop5TuyvoQfg@mail.gmail.com>
References: <CAH5Ym4jzYto07cb-i4HnRahBWO92FD5oNJ5f-fEugCANDfFNWg@mail.gmail.com>
 <alpine.DEB.2.11.1802181355540.10563@enira.zlyna.ubzr>
 <CAH5Ym4j9tDDv41QWHo1+L6uebZa_kPpN9XciwdiKSt4aNe_FMg@mail.gmail.com>
 <alpine.DEB.2.11.1802190951150.10563@enira.zlyna.ubzr>
 <CAH5Ym4jTv9NsfYKvJznWyE6Vo4R9eH5QOeU33hKop5TuyvoQfg@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1802191459590.10563@enira.zlyna.ubzr>

On 2018-02-19 13:03-0700 Sam Edwards wrote:

> Alan,
>
> I'm kicking myself for leaving off the DEPENDS in add_custom_target as that
> is the most essential part of what you suggested. Bah!
>
> I tried copying in your changes verbatim and I'm still left with an output
> that produces IS_INTERROGATE=0. This is on both 3.9.6 (my development
> machine) and 2.8.12 (my testing VM). Does your version of CMake produce
> IS_INTERROGATE=1 with your changes?

I don't want to get involved in too much further testing since the
overview of what you are attempting to do with generator expressions
is beyond my expertise.  However, I did build the following simple
project (with CMake-3.6.2)

cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
project(test NONE)
add_custom_target(depending_target)
set_target_properties(depending_target PROPERTIES
   IS_INTERROGATE 1)
get_target_property(target_interrogate depending_target IS_INTERROGATE)
message(STATUS "target_interrogate = ${target_interrogate}")

The results were

-- target_interrogate = 1
-- Configuring done
-- Generating done
-- Build files have been written to: /home/software/plplot/HEAD/build_dir/test_build

That result confirms that if you set that property on a custom target,
then that value is accessible via get_target_property (as expected).
So I don't know why that value is not currently accessible to you with
generator expressions, but for what it is worth (since this is beyond
my CMake expertise) I think it should be.  Anyhow, to debug this
further I suggest you simplify your test case even further (similar to
above) and compare generator expression results with
get_target_property results to try and understand what is going
on with the generator expression version.

>
> The rationale behind 2.8.12 is this is the version that ships with Ubuntu
> Trusty and will probably be what's present if a user is simply told to
> "install CMake" - although 3.5.1 is also available on that platform under
> the cmake3 package, so I might be able to justify a minimum version of
> either that or 3.0.1 (which is what's on backports-less Debian Jessie). I'd
> have to bring it up with the project maintainer to see, but in any case
> we're trying to follow a "stick with the same minimum version until we
> encounter a bug we can't work around, then bump the minimum to the version
> that fixes that bug" approach.

I would take the opposite approach, i.e., develop for the latest CMake, and
then once that completely works, push the minimum version to smaller
values to see how far you can get before you run into any difficulties.

In any case, I would definitely avoid early CMake 3 versions such as
3.0.1 for the reasons I mentioned.  I hauled that around on my back
for a while by working around its bugs with the PLplot build system,
but it was quite a lot of effort, and that build system became
somewhat simpler once I bumped the minimum cmake version to 3.6.2.

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
__________________________

From zanchey at ucc.gu.uwa.edu.au  Tue Feb 20 08:10:18 2018
From: zanchey at ucc.gu.uwa.edu.au (David Adam)
Date: Tue, 20 Feb 2018 21:10:18 +0800 (AWST)
Subject: [CMake] Ignore installation failure
In-Reply-To: <alpine.DEB.2.20.1802181311331.1675@motsugo.ucc.gu.uwa.edu.au>
References: <alpine.DEB.2.20.1802181311331.1675@motsugo.ucc.gu.uwa.edu.au>
Message-ID: <alpine.DEB.2.20.1802202107330.1675@motsugo.ucc.gu.uwa.edu.au>

On Sun, 18 Feb 2018, David Adam wrote:
> Our project installs an empty directory for other programs to drop files 
> in, the location of which is overrideable with a cache variable. Some 
> environments set the location of this directory outside the writeable 
> area and create it themselves, so I'd like to set up CMake so that it 
> tries to create the directory but skips over it if there is a failure.
> 
> At the moment we use:
> 
> SET(extra_completionsdir
>     ${rel_datadir}/fish/vendor_completions.d
>     CACHE STRING "Path for extra completions")
> INSTALL(DIRECTORY DESTINATION ${extra_completionsdir})
> 
> but that fails if the destination is not writeable.
> 
> Is there an idiomatic way of ignoring a failed installation step? At the 
> moment, I'm trying various install(script code execute_process(... 
> incantations, but I'm aware there's lots of corner cases with DESTDIR and 
> so on.

For the record, I ended up implementing just enough to make our use case 
work:

FUNCTION(FISH_TRY_CREATE_DIRS)
  FOREACH(dir ${ARGV})
    IF(NOT IS_ABSOLUTE ${dir})
      SET(abs_dir "\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${dir}")
    ELSE()
      SET(abs_dir "\$ENV{DESTDIR}${dir}")
    ENDIF()
    INSTALL(SCRIPT CODE "EXECUTE_PROCESS(COMMAND mkdir -p ${abs_dir} OUTPUT_QUIET ERROR_QUIET)
                         EXECUTE_PROCESS(COMMAND chmod 755 ${abs_dir} OUTPUT_QUIET ERROR_QUIET)
                        ")
  ENDFOREACH()
ENDFUNCTION(FISH_TRY_CREATE_DIRS)

Perhaps that will help someone in a similar situation in the future.

David Adam
zanchey at ucc.gu.uwa.edu.au


From cristian.adam at gmail.com  Tue Feb 20 08:12:31 2018
From: cristian.adam at gmail.com (Cristian Adam)
Date: Tue, 20 Feb 2018 14:12:31 +0100
Subject: [CMake] [blog article] It's Time To Do CMake Right
Message-ID: <CA+u+m-JkdEysLWffzm0wmUU6igGQaBgTa6eDiCF_EdQnv=onpw@mail.gmail.com>

Hi,

I thought the audience here would appreciate this:
https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/

It did quite a stir on /r/cpp too:
https://www.reddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/

Cheers,
Cristian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180220/e49e7763/attachment-0001.html>

From kai.wolf at gmail.com  Tue Feb 20 08:59:10 2018
From: kai.wolf at gmail.com (Kai Wolf)
Date: Tue, 20 Feb 2018 14:59:10 +0100
Subject: [CMake] [blog article] It's Time To Do CMake Right
In-Reply-To: <CAEOrzjrGLJjoJ_TY+VgOCLjowECXJdTNf0W7GLzb_XhAP4whgw@mail.gmail.com>
References: <CA+u+m-JkdEysLWffzm0wmUU6igGQaBgTa6eDiCF_EdQnv=onpw@mail.gmail.com>
 <CAEOrzjrGLJjoJ_TY+VgOCLjowECXJdTNf0W7GLzb_XhAP4whgw@mail.gmail.com>
Message-ID: <CAEOrzjo_fR8G2fjaQCnja-YRvWmraNykbmsn+XdCDvcQkz+-NQ@mail.gmail.com>

 Nice,

?I've found a smaller issue though. I've just submitted a PR on GitHub.
The reddit discussion is also interesting. A common theme in the typical
"CMake is bad" discussions is not the lack of documentation?, but a good
tutorial on how to *actually accomplish things* using CMake in a correct
and scalabale manner.
As a shameless self-plug: I am currently writing a book[1] on exact this
topic and really hope, I'll be able to release it by summer 2018 :-(

Greetings,

Kai

[1] http://effective-cmake.com/

<https://github.com/NewProggie>

2018-02-20 14:38 GMT+01:00 Kai Wolf <mail at kai-wolf.me>:

> Nice,
>
> ?I've found a smaller issue though. I've just submitted a PR on GitHub.
> The reddit discussion is also interesting. A common theme in the typical
> "CMake is bad" discussions is not the lack of documentation?, but a good
> tutorial on how to *actually accomplish things* using CMake in a correct
> and scalabale manner.
> As a shameless self-plug: I am currently writing a book[1] on exact this
> topic and really hope, I'll be able to release it by summer 2018 :-(
>
> Greetings,
>
> Kai
>
> [1] http://effective-cmake.com/
>
>
> 2018-02-20 14:12 GMT+01:00 Cristian Adam <cristian.adam at gmail.com>:
>
>> Hi,
>>
>> I thought the audience here would appreciate this:
>> https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/
>>
>> It did quite a stir on /r/cpp too:
>> https://www.reddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/
>>
>> Cheers,
>> Cristian.
>>
>> --
>>
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180220/31ffa068/attachment.html>

From boud at valdyas.org  Tue Feb 20 09:41:14 2018
From: boud at valdyas.org (Boudewijn Rempt)
Date: Tue, 20 Feb 2018 15:41:14 +0100
Subject: [CMake] [blog article] It's Time To Do CMake Right
In-Reply-To: <CAEOrzjo_fR8G2fjaQCnja-YRvWmraNykbmsn+XdCDvcQkz+-NQ@mail.gmail.com>
References: <CA+u+m-JkdEysLWffzm0wmUU6igGQaBgTa6eDiCF_EdQnv=onpw@mail.gmail.com>
 <CAEOrzjrGLJjoJ_TY+VgOCLjowECXJdTNf0W7GLzb_XhAP4whgw@mail.gmail.com>
 <CAEOrzjo_fR8G2fjaQCnja-YRvWmraNykbmsn+XdCDvcQkz+-NQ@mail.gmail.com>
Message-ID: <2312052.6FlBq6nl6u@linux-s09k>

On Tuesday, 20 February 2018 14:59:10 CET Kai Wolf wrote:
>  Nice,
> 
> ?I've found a smaller issue though. I've just submitted a PR on GitHub.
> The reddit discussion is also interesting. A common theme in the typical
> "CMake is bad" discussions is not the lack of documentation?, but a good
> tutorial on how to *actually accomplish things* using CMake in a correct
> and scalable manner.

I've used cmake since 2006, and I am completely in a fog when it comes to how 
I should update my project (which has a couple of hundred cmakelists.txt 
files, thirty external cmake projects and oodles of libraries and plugins) to 
something more modern...

> As a shameless self-plug: I am currently writing a book[1] on exact this
> topic and really hope, I'll be able to release it by summer 2018 :-(

Well, put me down for three copies!

-- 
Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org



From kai.wolf at gmail.com  Tue Feb 20 10:06:31 2018
From: kai.wolf at gmail.com (Kai Wolf)
Date: Tue, 20 Feb 2018 16:06:31 +0100
Subject: [CMake] [blog article] It's Time To Do CMake Right
In-Reply-To: <2312052.6FlBq6nl6u@linux-s09k>
References: <CA+u+m-JkdEysLWffzm0wmUU6igGQaBgTa6eDiCF_EdQnv=onpw@mail.gmail.com>
 <CAEOrzjrGLJjoJ_TY+VgOCLjowECXJdTNf0W7GLzb_XhAP4whgw@mail.gmail.com>
 <CAEOrzjo_fR8G2fjaQCnja-YRvWmraNykbmsn+XdCDvcQkz+-NQ@mail.gmail.com>
 <2312052.6FlBq6nl6u@linux-s09k>
Message-ID: <CAEOrzjoLJ=2Rhd5GC7OgAmskELiL+KZYJr2aXKNsQH94D5PpbQ@mail.gmail.com>

?Well, sounds like a reasonably sized C++ project :-)

On a more serious note: Are you aware of so called Superbuilds? This is a
term that is used quite often in the context of large CMake based
dependency builds. Speaking from personal experience, I've found that
Superbuild projects do scale quite well and managing a large set of
(external) thirdparty dependencies is usually not as bad as it might look.

Greetings,

Kai Wolf
<http://kai-wolf.me/> <http://kai-wolf.me/> <http://kai-wolf.me/>
<http://kai-wolf.me/> http://kai-wolf.me/


2018-02-20 15:41 GMT+01:00 Boudewijn Rempt <boud at valdyas.org>:

> On Tuesday, 20 February 2018 14:59:10 CET Kai Wolf wrote:
> >  Nice,
> >
> > ?I've found a smaller issue though. I've just submitted a PR on GitHub.
> > The reddit discussion is also interesting. A common theme in the typical
> > "CMake is bad" discussions is not the lack of documentation?, but a good
> > tutorial on how to *actually accomplish things* using CMake in a correct
> > and scalable manner.
>
> I've used cmake since 2006, and I am completely in a fog when it comes to
> how
> I should update my project (which has a couple of hundred cmakelists.txt
> files, thirty external cmake projects and oodles of libraries and plugins)
> to
> something more modern...
>
> > As a shameless self-plug: I am currently writing a book[1] on exact this
> > topic and really hope, I'll be able to release it by summer 2018 :-(
>
> Well, put me down for three copies!
>
> --
> Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org
>
>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180220/f3b28151/attachment.html>

From eeide at cs.utah.edu  Tue Feb 20 11:28:41 2018
From: eeide at cs.utah.edu (Eric Eide)
Date: Tue, 20 Feb 2018 09:28:41 -0700
Subject: [CMake] [blog article] It's Time To Do CMake Right
In-Reply-To: <CAEOrzjo_fR8G2fjaQCnja-YRvWmraNykbmsn+XdCDvcQkz+-NQ@mail.gmail.com>
 (Kai Wolf's message of "Tue, 20 Feb 2018 14:59:10 +0100")
References: <CA+u+m-JkdEysLWffzm0wmUU6igGQaBgTa6eDiCF_EdQnv=onpw@mail.gmail.com>
 <CAEOrzjrGLJjoJ_TY+VgOCLjowECXJdTNf0W7GLzb_XhAP4whgw@mail.gmail.com>
 <CAEOrzjo_fR8G2fjaQCnja-YRvWmraNykbmsn+XdCDvcQkz+-NQ@mail.gmail.com>
Message-ID: <m14lmbtykm.fsf@gris-dmz.flux.utah.edu>

Kai Wolf <kai.wolf at gmail.com> writes:

> As a shameless self-plug: I am currently writing a book[1] on exact this
> topic and really hope, I'll be able to release it by summer 2018 :-(
> [1] http://effective-cmake.com/

This is great to hear!

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide at cs.utah.edu>  .         University of Utah School of Computing
http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX

From sstallion at gmail.com  Tue Feb 20 11:41:53 2018
From: sstallion at gmail.com (Steven Stallion)
Date: Tue, 20 Feb 2018 10:41:53 -0600
Subject: [CMake] [blog article] It's Time To Do CMake Right
In-Reply-To: <m14lmbtykm.fsf@gris-dmz.flux.utah.edu>
References: <CA+u+m-JkdEysLWffzm0wmUU6igGQaBgTa6eDiCF_EdQnv=onpw@mail.gmail.com>
 <CAEOrzjrGLJjoJ_TY+VgOCLjowECXJdTNf0W7GLzb_XhAP4whgw@mail.gmail.com>
 <CAEOrzjo_fR8G2fjaQCnja-YRvWmraNykbmsn+XdCDvcQkz+-NQ@mail.gmail.com>
 <m14lmbtykm.fsf@gris-dmz.flux.utah.edu>
Message-ID: <CAGGHmKH+eZSHm=gkVMCYW-wdAe62f9YqjgyM_8gSo4_g_RTjTQ@mail.gmail.com>

Indeed. Our CMake build here is spread across >500 list files with
around 1G of source code. I've often wondered how it compared to other
large C and assembly projects. To wit, several of the practices in the
article we've followed as well. It's great to hear that someone is
working on a book - I've considered doing the same!

On Tue, Feb 20, 2018 at 10:28 AM, Eric Eide <eeide at cs.utah.edu> wrote:
> Kai Wolf <kai.wolf at gmail.com> writes:
>
>> As a shameless self-plug: I am currently writing a book[1] on exact this
>> topic and really hope, I'll be able to release it by summer 2018 :-(
>> [1] http://effective-cmake.com/
>
> This is great to hear!
>
> --
> -------------------------------------------------------------------------------
> Eric Eide <eeide at cs.utah.edu>  .         University of Utah School of Computing
> http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX
> --
>
> 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

From kmorel at sandia.gov  Tue Feb 20 16:08:27 2018
From: kmorel at sandia.gov (Moreland, Kenneth)
Date: Tue, 20 Feb 2018 21:08:27 +0000
Subject: [CMake] Latest versions of CMake/Qt Creator lock up configuration
 on CMake error
Message-ID: <c36991d9be2549acb33fd3e0bf08776d@ES08AMSNLNT.srn.sandia.gov>

This might be a question for the folks at Qt, but I thought I would float it here first as other CMake users might have run into it.

This morning I updated to the most recent versions of CMake (3.10.2) and Qt Creator (4.5.1). I then tried to use Qt Creator to configure a non-trivial CMake project from scratch and ran into an issue. The problem is that any time CMake fails to configure, the Qt Creator Build Settings GUI becomes non-responsive. This is a serious issue since it is common for CMake to fail because it cannot find some required component (like a library it depends on), and then to use the GUI to point CMake to the proper location of the library. However, once CMake fails to configure, Qt Creator doesn't let you change the CMake variables to point it in the right direction.

I suspect this is caused by the new server-mode feature of CMake. My guess is that once the CMake server fails to configure, it stops providing any information to Qt Creator, which then becomes nonresponsive until the configure succeeds.

Has anyone seen this behavior or have any workarounds?

-Ken

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov<mailto:kmorel at sandia.gov>
**  ***  **  phone: (505) 844-8919
    ***      web:   http://kennethmoreland.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180220/56be5035/attachment.html>

From haocheng.liu at kitware.com  Tue Feb 20 17:50:04 2018
From: haocheng.liu at kitware.com (Haocheng Liu)
Date: Tue, 20 Feb 2018 17:50:04 -0500
Subject: [CMake] Latest versions of CMake/Qt Creator lock up
 configuration on CMake error
In-Reply-To: <c36991d9be2549acb33fd3e0bf08776d@ES08AMSNLNT.srn.sandia.gov>
References: <c36991d9be2549acb33fd3e0bf08776d@ES08AMSNLNT.srn.sandia.gov>
Message-ID: <CACbTE7P0nKL+SrFEw2uDOH98UNW+q0PWERZ-Qi+AA6f_hryf4w@mail.gmail.com>

Hi Ken,

On Tue, Feb 20, 2018 at 4:08 PM, Moreland, Kenneth <kmorel at sandia.gov>
wrote:

> This might be a question for the folks at Qt, but I thought I would float
> it here first as other CMake users might have run into it.
>
>
>
> This morning I updated to the most recent versions of CMake (3.10.2) and
> Qt Creator (4.5.1). I then tried to use Qt Creator to configure a
> non-trivial CMake project from scratch and ran into an issue. The problem
> is that any time CMake fails to configure, the Qt Creator Build Settings
> GUI becomes non-responsive. This is a serious issue since it is common for
> CMake to fail because it cannot find some required component (like a
> library it depends on), and then to use the GUI to point CMake to the
> proper location of the library. However, once CMake fails to configure, Qt
> Creator doesn?t let you change the CMake variables to point it in the right
> direction.
>
>
>
Out of curiosity, I updated my Qt Creator to 4.5.1 and tested it with
CMake(3.10.1) on my Ubuntu 16.04 laptop and it works fine. I'm able to
modify the CMake variables.

> I suspect this is caused by the ne w server-mode feature of CMake. My
> guess is that once the CMake server fails to configure, it stops providing
> any information to Qt Creator, which then becomes nonresponsive until the
> configure succeeds.
>
>
>
Since CMake introduces its server mode in 3.7, ideally my CMake(3.10.1)
should also be affected. Humm.

> Has anyone seen this behavior or have any workarounds?
>
>
>
Have you tried to tweak the CMake variables via ccmake or cmake-gui then
right click your project in Qt Creator ->  call `Run CMake` in the context
menu?

best regards
Haocheng

> -Ken
>
>
>
>    ****      Kenneth Moreland
>
>     ***      Sandia National Laboratories
> ***********
> *** *** ***  email: kmorel at sandia.gov
>
> **  ***  **  phone: (505) 844-8919
>     ***      web:   http://kennethmoreland.com
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
>


-- 
Best regards
Haocheng

Haocheng LIU
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4421 <(518)%20881-4421>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180220/885cd4a7/attachment.html>

From kmorel at sandia.gov  Tue Feb 20 18:04:04 2018
From: kmorel at sandia.gov (Moreland, Kenneth)
Date: Tue, 20 Feb 2018 23:04:04 +0000
Subject: [CMake] Latest versions of CMake/Qt Creator lock up
 configuration on CMake error
Message-ID: <8834E5E3-25AB-4D47-B963-025A2CE04350@sandia.gov>

Haocheng,

Yes, if I go to the CMake GUI, use that to set all the CMake variables so that the configure succeeds, and then load that configuration into Qt Creator, everything works fine. The problem is only when CMake configuration fails because a variable needs to change. The common case where you have configuration code like the following:

find_package(foo)
if (NOT foo_FOUND)
  message(SEND_ERROR ?Need package foo?)
endif()

Often on the first run of CMake, you?ll get the error about not finding package foo. Then you set the foo_DIR variable (or whatever CMake needs to find the library) and the configure succeed. But Qt Creator is not letting me set those variables, which is clearly wrong.

One more data point, this is on Windows 10. I don?t know if there is a difference on different systems.

-Ken

From: Haocheng Liu <haocheng.liu at kitware.com>
Date: Tuesday, February 20, 2018 at 3:50 PM
To: "Moreland, Kenneth" <kmorel at sandia.gov>
Cc: "cmake at cmake.org" <cmake at cmake.org>
Subject: [EXTERNAL] Re: [CMake] Latest versions of CMake/Qt Creator lock up configuration on CMake error

Hi Ken,

On Tue, Feb 20, 2018 at 4:08 PM, Moreland, Kenneth <kmorel at sandia.gov<mailto:kmorel at sandia.gov>> wrote:
This might be a question for the folks at Qt, but I thought I would float it here first as other CMake users might have run into it.

This morning I updated to the most recent versions of CMake (3.10.2) and Qt Creator (4.5.1). I then tried to use Qt Creator to configure a non-trivial CMake project from scratch and ran into an issue. The problem is that any time CMake fails to configure, the Qt Creator Build Settings GUI becomes non-responsive. This is a serious issue since it is common for CMake to fail because it cannot find some required component (like a library it depends on), and then to use the GUI to point CMake to the proper location of the library. However, once CMake fails to configure, Qt Creator doesn?t let you change the CMake variables to point it in the right direction.

Out of curiosity, I updated my Qt Creator to 4.5.1 and tested it with CMake(3.10.1) on my Ubuntu 16.04 laptop and it works fine. I'm able to modify the CMake variables.
I suspect this is caused by the ne w server-mode feature of CMake. My guess is that once the CMake server fails to configure, it stops providing any information to Qt Creator, which then becomes nonresponsive until the configure succeeds.

Since CMake introduces its server mode in 3.7, ideally my CMake(3.10.1) should also be affected. Humm.
Has anyone seen this behavior or have any workarounds?

Have you tried to tweak the CMake variables via ccmake or cmake-gui then right click your project in Qt Creator ->  call `Run CMake` in the context menu?

best regards
Haocheng
-Ken

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov<mailto:kmorel at sandia.gov>
**  ***  **  phone: (505) 844-8919<tel:(505)%20844-8919>
    ***      web:   http://kennethmoreland.com



--

Powered by www.kitware.com<http://www.kitware.com>

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

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



--
Best regards
Haocheng

Haocheng LIU
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4421<tel:(518)%20881-4421>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180220/29c979a6/attachment-0001.html>

From Marek.Vojtko at firaxis.com  Wed Feb 21 22:20:40 2018
From: Marek.Vojtko at firaxis.com (Marek Vojtko (Firaxis))
Date: Thu, 22 Feb 2018 03:20:40 +0000
Subject: [CMake] Copying Shared Libraries (DLLs) Next to the Executable
Message-ID: <BL2PR14MB0932390910759947A383239D96CD0@BL2PR14MB0932.namprd14.prod.outlook.com>

Hi,

I need to copy external shared libraries (DLLs on Windows) next to the generated executable. Is calling "cmake -E copy_if_different" through a custom command added to the executable target still the best way to achieve this? CMake tracks include directories, compile definitions or options, link flags, etc. through its dependency system, but it doesn't provide an easy way to list / copy all shared libraries a target depends on?

I am trying to follow the "new" CMake paradigms, using add_subdirectory(), set_target*() with PUBLIC/PRIVATE/INTERFACE scope, etc. to create a modular, re-usable setup, but that actively prevents me from using a custom command on the executable target. To wit:

App depends on Lib. Lib depends on several third-party, pre-built DLLs and encapsulates the logic of when to depend on them. The third-party, pre-built shared libraries (DLLs) are located through custom Find*.cmake modules and used as IMPORTED targets.

/CMakelists.txt
/App
    /CMakelists.txt
/Lib
    /CMakelists.txt

/CMakelists.txt
*************
set(CMAKE_MODULE_PATH "<my_modules>")
project("DLLTest")
add_subdirectory("${CMAKE_CURRENT_SOURCE_DIR}/Lib")
add_subdirectory("${CMAKE_CURRENT_SOURCE_DIR}/App")

/App/CMakelists.txt
*****************
add_executable(App WIN32 main.cpp)
target_link_libraries(App PRIVATE Lib)

/Lib/CMakelists.txt
****************
add_library(Lib STATIC lib.h lib.cpp)
target_include_directories(Lib PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}")

if(Lib_NEEDS_DEPENDENCY)
    find_package(Dependency REQUIRED)
    target_link_libraries(Lib PUBLIC Dependency::Dependency)
endif()

FindDependency.cmake
********************
[snip]
add_library(Dependency::Dependency SHARED IMPORTED)
set_target_properties(Dependency::Dependency PROPERTIES
            INTERFACE_INCLUDE_DIRECTORIES "inc"
            IMPORTED_IMPLIB "dependency.lib"
            IMPORTED_LOCATION "dependency.dll"
)

In this setup, it is impossible to propagate a shared library (DLL) from Lib to App. This is because Lib and App have different BINARY_DIRs and Lib must create its target before App calls target_link_libraries(). That means that Lib does not know where App will generate its executable. If Lib is a SHARED target, I cannot set its RUNTIME_OUTPUT_DIRECTORY to be the same as App's. If Lib depends on IMPORTED targets (as is my case), I cannot create either a file(COPY) step, or an install(FILES) step, or even an add_custom_command() step in Lib to copy the shared library, because I don't know the destination.

The only solution, it would seem, is to add a custom command to App's target, because then I know where to copy the shared libraries to. But that means that App now has to know it needs to copy a shared library from a "hidden" dependency of Lib. App also needs to know about every SHARED or IMPORTED target Lib depends on, not to mention duplicate the logic in Lib's CMakelists.txt that decided whether Lib depends on Dependency in the first place.

I was looking into GetPrerequisites and FixupBundle, but both of those operate on an already existing executable and try to guess what shared libraries (DLLs) it might need. It feels silly to guess at something that CMake already knows (as the IMPORTED target sets the IMPORTED_IMPLIB and IMPORTED_LOCATION properties).

Setting a common CMAKE_RUNTIME_OUTPUT_DIRECTORY for both App and Lib is problematic if I have multiple executables in my root CMakelists.txt and they depend on different versions of the shared libraries or I have other name clashes.

Is there no automated way to get the list of shared libraries a target depends on?

Thanks,
Marek

From rsjtaylor.github at gmail.com  Thu Feb 22 13:07:53 2018
From: rsjtaylor.github at gmail.com (Rich T)
Date: Thu, 22 Feb 2018 18:07:53 +0000
Subject: [CMake] Building and exporting static and shared libs - best
 practice?
Message-ID: <CAJ1+j+JjbbseUnEj0tNcc5SEmK=SeAZLKnzpKyeW7Q4Mxiv2YQ@mail.gmail.com>

It's often useful to be able to make both static and shared varients of a
library available to users of a package.

My goal is to make the project cmake files as clean as possible, while
supporting usage of either or both types of library by users. It should
work from both build and installed locations, in a reasonably intuitive way.

I've tried a few methods so far, but none feel completely satisfactory. I
was wondering what was currently thought of as best practice with recent
versions of CMake?

1: Don't specify library type

add_library(myLib mySource.cpp)

The type of library is then controlled by the value of BUILD_SHARED_LIBS
This is nice:
* No duplication. Things common to both types are only specified once,
without resorting to custom variables.
* By default you only build one sort of library, so no build overhead.
* Type-dependent logic clearly presented by branching on a single, standard
variable

e.g.
if(NOT BUILD_SHARED_LIBS)
  target_compile_definitions(myLib PUBLIC MYLIB_STATIC_BUILD)
endif()

Using this sort of project to build an installation package that contains
both types of target can be accomplished with a little care.
You build the project twice in different directories, once with
BUILD_SHARED_LIBS and once without, but install to the same prefix.
* Namespace at the point of export based on type (MyPackage::SHARED::myLib
or MyPackage::STATIC::myLib)
* Export to a type-specific config (myLib_exports_static.cmake
myLib_exports_shared.config)
* Have your package config check for and include the exported static and
shared config files using if(EXISTS)
* Some MSVC specific code to prevent shared import lib and static lib
output names conflicting
* On cmake 3.11+, alias one flavour to MyPackage::myLib based on some user
variable for convenience

This all works well, the problem comes with registering a build tree in the
user repository.

export(PACKAGE myPackage)

In a downstream project, only one build location will be arbitrarily chosen
from the user registry.
While you could manually choose either the static or shared tree by setting
myPackage_DIR, you can't have both, at least not from the build tree. Even
if a user only wants one, the fact they might get the 'wrong' version by
default is likely to confuse.

Setting MYLIB_FOUND to FALSE in a package config aborts the search process
rather than continuing to search for other possible configs, else you could
do partial loading from two different build trees in much the same way that
you can merge installations (or search for a shared vs static based on a
user variable)

I've tried calling include_subdirectory(myLibDir) twice in a project, both
before and after setting BUILD_SHARED_LIBS.
This requires you to change the target name as duplicates are not allowed
(for obvious reasons). A variable target name requires a custom variable
anywhere your target is referenced, which is error prone. Also feels a bit
of an abuse of the variable.

You could export to two different packages, but having to do
find_package(MyLibShared) or find_package(MyLibStatic) feels a bit
counterintuitive from the installed perspective if both versions are
distributed together.

2: Create two separate targets, one for each type

One common approach is to assign sources and other build ingredients to a
custom variable, then call any target-modifying functions once for each
target, passing this variable.

set(mySources mySource.cpp)
add_target(myLib_static STATIC ${mySources})
add_target(myLib_shared SHARED ${mySources})

This can be difficult to debug as mistakes are often distant from the
location at which an error is caught. It's also a lot more verbose as every
target method is duplicated.

I think the need for a variable can be mitigated in some circumstances by
using generator expressions

e.g.

target_include_directories(myLib_shared
  PRIVATE $<TARGET_PROPERTY,myLib_static,INCLUDE_DIRECTORIES>
  INTERFACE $<TARGET_PROPERTY,myLib_static,INTERFACE_INCLUDE_DIRECTORIES>)

However, this only works for properties that are identical between
variants, necessitates always building the first target and is even more
verbose that using custom variables.

So from the upstream point of view, the first method is the clear winner,
but its restrictions when importing targets from the build tree can make it
less convenient for downstream users, who may be working on projects that
take the two target approach.

So what's considered the best option at the moment? Am I missing something
obvious?

Thanks,

Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180222/0a3e0e32/attachment.html>

From dschepler at scalable-networks.com  Thu Feb 22 13:44:17 2018
From: dschepler at scalable-networks.com (Daniel Schepler)
Date: Thu, 22 Feb 2018 18:44:17 +0000
Subject: [CMake] Copying Shared Libraries (DLLs) Next to the Executable
In-Reply-To: <BL2PR14MB0932390910759947A383239D96CD0@BL2PR14MB0932.namprd14.prod.outlook.com>
References: <BL2PR14MB0932390910759947A383239D96CD0@BL2PR14MB0932.namprd14.prod.outlook.com>
Message-ID: <E80C0FB7C5F9C7489F5E4B83BAD92C940136016109@SNTMAIL01.snt.loc>

Personally, I find it much simpler just to expect the Path to include the locations of the DLL files as opposed to copying them.  (And I often write small batch scripts to set up this development environment, and then optionally start cmake-gui.exe / devenv.exe / etc.)
-- 
Daniel Schepler
________________________________________
From: CMake [cmake-bounces at cmake.org] on behalf of Marek Vojtko (Firaxis) [Marek.Vojtko at firaxis.com]
Sent: Wednesday, February 21, 2018 7:20 PM
To: cmake at cmake.org
Subject: [CMake] Copying Shared Libraries (DLLs) Next to the Executable

Hi,

I need to copy external shared libraries (DLLs on Windows) next to the generated executable. Is calling "cmake -E copy_if_different" through a custom command added to the executable target still the best way to achieve this? CMake tracks include directories, compile definitions or options, link flags, etc. through its dependency system, but it doesn't provide an easy way to list / copy all shared libraries a target depends on?

I am trying to follow the "new" CMake paradigms, using add_subdirectory(), set_target*() with PUBLIC/PRIVATE/INTERFACE scope, etc. to create a modular, re-usable setup, but that actively prevents me from using a custom command on the executable target. To wit:

App depends on Lib. Lib depends on several third-party, pre-built DLLs and encapsulates the logic of when to depend on them. The third-party, pre-built shared libraries (DLLs) are located through custom Find*.cmake modules and used as IMPORTED targets.

/CMakelists.txt
/App
    /CMakelists.txt
/Lib
    /CMakelists.txt

/CMakelists.txt
*************
set(CMAKE_MODULE_PATH "<my_modules>")
project("DLLTest")
add_subdirectory("${CMAKE_CURRENT_SOURCE_DIR}/Lib")
add_subdirectory("${CMAKE_CURRENT_SOURCE_DIR}/App")

/App/CMakelists.txt
*****************
add_executable(App WIN32 main.cpp)
target_link_libraries(App PRIVATE Lib)

/Lib/CMakelists.txt
****************
add_library(Lib STATIC lib.h lib.cpp)
target_include_directories(Lib PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}")

if(Lib_NEEDS_DEPENDENCY)
    find_package(Dependency REQUIRED)
    target_link_libraries(Lib PUBLIC Dependency::Dependency)
endif()

FindDependency.cmake
********************
[snip]
add_library(Dependency::Dependency SHARED IMPORTED)
set_target_properties(Dependency::Dependency PROPERTIES
            INTERFACE_INCLUDE_DIRECTORIES "inc"
            IMPORTED_IMPLIB "dependency.lib"
            IMPORTED_LOCATION "dependency.dll"
)

In this setup, it is impossible to propagate a shared library (DLL) from Lib to App. This is because Lib and App have different BINARY_DIRs and Lib must create its target before App calls target_link_libraries(). That means that Lib does not know where App will generate its executable. If Lib is a SHARED target, I cannot set its RUNTIME_OUTPUT_DIRECTORY to be the same as App's. If Lib depends on IMPORTED targets (as is my case), I cannot create either a file(COPY) step, or an install(FILES) step, or even an add_custom_command() step in Lib to copy the shared library, because I don't know the destination.

The only solution, it would seem, is to add a custom command to App's target, because then I know where to copy the shared libraries to. But that means that App now has to know it needs to copy a shared library from a "hidden" dependency of Lib. App also needs to know about every SHARED or IMPORTED target Lib depends on, not to mention duplicate the logic in Lib's CMakelists.txt that decided whether Lib depends on Dependency in the first place.

I was looking into GetPrerequisites and FixupBundle, but both of those operate on an already existing executable and try to guess what shared libraries (DLLs) it might need. It feels silly to guess at something that CMake already knows (as the IMPORTED target sets the IMPORTED_IMPLIB and IMPORTED_LOCATION properties).

Setting a common CMAKE_RUNTIME_OUTPUT_DIRECTORY for both App and Lib is problematic if I have multiple executables in my root CMakelists.txt and they depend on different versions of the shared libraries or I have other name clashes.

Is there no automated way to get the list of shared libraries a target depends on?

Thanks,
Marek
--

Powered by www.kitware.com

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

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

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

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

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



From post at hendrik-sattler.de  Thu Feb 22 15:17:51 2018
From: post at hendrik-sattler.de (Hendrik Sattler)
Date: Thu, 22 Feb 2018 21:17:51 +0100
Subject: [CMake] Copying Shared Libraries (DLLs) Next to the Executable
In-Reply-To: <BL2PR14MB0932390910759947A383239D96CD0@BL2PR14MB0932.namprd14.prod.outlook.com>
References: <BL2PR14MB0932390910759947A383239D96CD0@BL2PR14MB0932.namprd14.prod.outlook.com>
Message-ID: <8310EC43-1527-4C20-848C-B9556EC63B29@hendrik-sattler.de>



Am 22. Februar 2018 04:20:40 MEZ schrieb "Marek Vojtko (Firaxis)" <Marek.Vojtko at firaxis.com>:
>I was looking into GetPrerequisites and FixupBundle, but both of those
>operate on an already existing executable and try to guess what shared
>libraries (DLLs) it might need. It feels silly to guess at something
>that CMake already knows (as the IMPORTED target sets the
>IMPORTED_IMPLIB and IMPORTED_LOCATION properties).

Actually at the point of installation this is the best approach especially for multi-config generators like e.g. Visual Studio. Else you'd have to know if a found .lib file is a shared or a static library (how?) and what DLL file it references. That's actually much more work than just looking at the actually dependencies of the binaries. Additionally if you don't exactly know for 3rd party binaries or plugins.

Catching all directories to find the dll files is also not simple but easier.

HS

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

From Caleb.Pentecost at cognex.com  Thu Feb 22 17:16:21 2018
From: Caleb.Pentecost at cognex.com (Pentecost, Caleb)
Date: Thu, 22 Feb 2018 22:16:21 +0000
Subject: [CMake] Adding a custom_command dependency to all sources
Message-ID: <MWHPR06MB3504740312FA2DE4510125498BCD0@MWHPR06MB3504.namprd06.prod.outlook.com>

Howdy,

I'm looking to add a dependency to all source files to ensure that a generated file is up-to-date before compilation. This generated file is "passed in" to the compiler via a global compiler definition. Is there an easy or built-in way to do this, or will I need to manually add a made-up target to every file in every library directory?

Currently, the generated file is created in the CMake Options file, using an exec_program command near the top of the file. The output of this process is not tracked, but the GLOBAL_DEFS variable applied to every source file includes a line that directs the compiler to consume the new file. It looks a little like this:

Lib_options.cmake
[...]
exec_program(
    <executable>
    ARGS
    -o <outputFile>
    -I <inputFile>
    -x <extraArgs...>
)
[...]
set (GLOBAL_DEFS
  -D<definitions...>
  -@<outputFile>
)
[...]


However, the dependency tree is not aware of this file and will not prepare it in any way on a per-file bases. In this case the program is executed every build regardless of if <inputFile> has been modified. This adds unnecessary time to an incremental build if no change is made, and if <inputFile> does happen to change CMake will not recompile the sources accordingly. I have to do a clean/rebuild in order for the changes to "take".

What I would like to see is a way to actually add <outputFile> as a dependency to each source file. Now, I'm no CMake expert, but I think it would look something like this:

Lib_options.cmake
[...]
# Create a command/target for our output file
add_custom_command(
  OUTPUT
    <outputFile>
  DEPENDS
    <inputFile>
  COMMAND
  <executable>
    ARGS
      -o <outputFile>
      -I <inputFile>
      -x <extraArgs...>
)

# Do something to make all source files depend on <outputFile>
# <Magic goes here>

[...]
set (GLOBAL_DEFS
  -D<definitions...>
  -@<outputFile>
)
[...]


Would this be a feasible thing to do in CMake, especially at the options file level? If you need any more information please let me know.

Thank you in advance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180222/4ae4ddd9/attachment-0001.html>

From azukaitis at gmail.com  Fri Feb 23 10:59:12 2018
From: azukaitis at gmail.com (Anthony Zukaitis)
Date: Fri, 23 Feb 2018 08:59:12 -0700
Subject: [CMake] Bug on Windows with Intel Fortran
Message-ID: <CACpOV+ML8OEEW6zJ8419reZ-WvC2oA2w5N38SF8ezhjzgVcabA@mail.gmail.com>

On windows I found an issue with Visual studio where intel fortran was
attempting to preprocess lowercase .f90 files.  Intel's documentation
states that it does not preprocess these files.  Looking into the cmake
source code I found:

in Modules/Platform/Windows-Intel-Fortran line 3:

set(_COMPILE_Fortran " /fpp")

which looks to me like cmake is adding this flag by default to all fortran
files not .F90 vs .f90.  Also we are using our own preprocessor which would
also complicate things.  Can you guys remove the setting of this flag?

Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180223/3efc2128/attachment.html>

From zbeekman at gmail.com  Fri Feb 23 17:27:03 2018
From: zbeekman at gmail.com (Zaak Beekman)
Date: Fri, 23 Feb 2018 22:27:03 +0000
Subject: [CMake] Help with find module for package w/ components
Message-ID: <CAAbnBwb4wJ6pAHwz2c7QBPXM81ZWqDGwg-aCno9Z-ELcqvqk6A@mail.gmail.com>

I need some guidance. I am writing a find module for a package that defines
multiple library archives, includes and Fortran module files. I would like
to make a "best practices" and "modern" find module and define a target so
that transitive properties are propagated correctly. I would like to define
two components, the base package itself (multiple library files and Fortran
module files) and then the C interface (additional library file and C
include files).

The biggest point of confusion: Is there a way to define a single target
that can be passed to target_link_libraries() that will cause the
*multiple* (imported) library archives of the base package to linked in?
Can I define it in such a way that it is namespaced like Foo::Foo?

For an optional component, then do I specify an additional target for that
component?

Thanks,
Zaak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180223/627b1058/attachment.html>

From irwin at beluga.phys.uvic.ca  Fri Feb 23 20:01:18 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Fri, 23 Feb 2018 17:01:18 -0800 (PST)
Subject: [CMake] Help with find module for package w/ components
In-Reply-To: <CAAbnBwb4wJ6pAHwz2c7QBPXM81ZWqDGwg-aCno9Z-ELcqvqk6A@mail.gmail.com>
References: <CAAbnBwb4wJ6pAHwz2c7QBPXM81ZWqDGwg-aCno9Z-ELcqvqk6A@mail.gmail.com>
Message-ID: <alpine.DEB.2.11.1802231551350.10563@enira.zlyna.ubzr>

On 2018-02-23 22:27-0000 Zaak Beekman wrote:

> Is there a way to define a single target
> that can be passed to target_link_libraries() that will cause the
> *multiple* (imported) library archives of the base package to linked in?

Hi Zaak:

Imported library targets are handled similarly to ordinary library
targets.  So suppose you have a core library with the name core_fortran
and a c interface library with the name c_interface, then C code
should be linked to c_interface (which draws in core_fortran if you
are transitively linking but otherwise not) and fortran code should be linked
to core_fortran.

> Can I define it in such a way that it is namespaced like Foo::Foo?

I have never tried that myself, but 
from my (very recent) reading of
<https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/>
namespacing is done using the NAMESPACE option for the
install(EXPORT...) command.  N.B. that article is extremely useful
so I would recommend reading and re-reading it with care.

> For an optional component, then do I specify an additional target for that
> component?

CMake users can organize the export of CMake packages in essentially
any way they like.  For example, the PLplot build system I am helping
to maintain uses a deprecated paradigm where there is just one
exported package containing a very large number of different targets.
But this approach is deprecated since it makes life too difficult for
software distribution maintainers who typically like to split up the
various libraries and dll's installed by a project into several
different interdependent binary packages.  So it is very much on my
agenda to reorganize our single export of a CMake package into a
number of different exports with each of those CMake packages
containing a disjoint subset of our targets with appropriate
find_package commands in Config mode to import all CMake packages that
a given CMake package depends on.

So in your case, this new approach we intend to take would boil down
to you exporting a CMake package corresponding to your C interface library and a
CMake package corresponding to your core Fortran library.  And the C interface
library CMake package should use find_package to find the fortran core
library package your C interface library depends on. So if user code
depends on your C interface, they should use find_package in Config
mode to find your C interface library package which in turn
automatically finds your core Fortran library. But if user code is
Fortran only they should just import your core Fortran library CMake
package.  N.B. in both cases, the net effect is all targets are imported
that are needed.  But once those targets are imported then the use of
those targets in target_link_library commands is completely orthogonal
to exactly how the targets are organized into separate packages.

Anyhow, I hope this discussion (especially the above URL reference to best
CMake practices) is a help to you.

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
__________________________

From sancelot at numalliance.com  Mon Feb 26 03:52:30 2018
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Mon, 26 Feb 2018 09:52:30 +0100
Subject: [CMake] recusively calling make install
Message-ID: <010da21f-a108-bca0-51a6-f9e6ba7bc7f2@numalliance.com>

Hi,

I have got a master CMake file that includes subprojects as follow :

add_subdirectory(proj1)
add_subdirectory(proj2)

src+proj1

 ???? +proj2

The main problem is that I can run make install in each project 
directory, but not from the top CMake directory in src dir

how to propagate install in each projects?

Regards,

S.ancelot

From sancelot at numalliance.com  Mon Feb 26 05:07:53 2018
From: sancelot at numalliance.com (=?UTF-8?Q?St=c3=a9phane_Ancelot?=)
Date: Mon, 26 Feb 2018 11:07:53 +0100
Subject: [CMake] recusively calling make install
In-Reply-To: <010da21f-a108-bca0-51a6-f9e6ba7bc7f2@numalliance.com>
References: <010da21f-a108-bca0-51a6-f9e6ba7bc7f2@numalliance.com>
Message-ID: <b0279623-c59c-0005-be2c-cadebf8f7c28@numalliance.com>

found:that was because of a project that was not compiling ....


Le 26/02/2018 ? 09:52, St?phane Ancelot a ?crit?:
> Hi,
>
> I have got a master CMake file that includes subprojects as follow :
>
> add_subdirectory(proj1)
> add_subdirectory(proj2)
>
> src+proj1
>
> ???? +proj2
>
> The main problem is that I can run make install in each project 
> directory, but not from the top CMake directory in src dir
>
> how to propagate install in each projects?
>
> Regards,
>
> S.ancelot

From bill.hoffman at kitware.com  Mon Feb 26 12:21:25 2018
From: bill.hoffman at kitware.com (Bill Hoffman)
Date: Mon, 26 Feb 2018 12:21:25 -0500
Subject: [CMake] Bug on Windows with Intel Fortran
In-Reply-To: <CACpOV+ML8OEEW6zJ8419reZ-WvC2oA2w5N38SF8ezhjzgVcabA@mail.gmail.com>
References: <CACpOV+ML8OEEW6zJ8419reZ-WvC2oA2w5N38SF8ezhjzgVcabA@mail.gmail.com>
Message-ID: <08670fb3-baa1-3742-2f66-3b6db29b1780@kitware.com>

On 2/23/2018 10:59 AM, Anthony Zukaitis wrote:
> On windows I found an issue with Visual studio where intel fortran was 
> attempting to preprocess lowercase .f90 files.? Intel's documentation 
> states that it does not preprocess these files.? Looking into the cmake 
> source code I found:
> 
> in Modules/Platform/Windows-Intel-Fortran line 3:
> 
> set(_COMPILE_Fortran " /fpp")
> 
> 
> which looks to me like cmake is adding this flag by default to all 
> fortran files not .F90 vs .f90.? Also we are using our own preprocessor 
> which would also complicate things.? Can you guys remove the setting of 
> this flag?
> 
> Tony
> 
> 
> 
Please add the issue here:
https://gitlab.kitware.com/cmake/cmake/issues

From mike.jackson at bluequartz.net  Mon Feb 26 14:19:01 2018
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Mon, 26 Feb 2018 14:19:01 -0500
Subject: [CMake] Return an Error Code (or something) from a CMake Script.
Message-ID: <C97F5CB9-496A-4012-AC55-9071635E8A41@bluequartz.net>

In our CMake based project I generate a *.cmake file which I call with the following bit of code:

  add_custom_target(DREAM3D_MKDOCS_GENERATION ALL
    COMMAND "${CMAKE_COMMAND}" -P "${docsCmakeFile}"    
    COMMENT "using mkdocs to generate the documentation"
  )

Inside the generated file is the following cmake command:

  message(STATUS "Starting mkdocs execution. This can take a while.....")
  execute_process(COMMAND "/path/to/mkdocs" build
                OUTPUT_VARIABLE mkdocs_gen_output
                RESULT_VARIABLE mkdocs_gen_result
                ERROR_VARIABLE mkdocs_gen_error
                WORKING_DIRECTORY "/Users/mjackson/DREAM3D-Dev/DREAM3D-Build/Debug/Documentation/mkdocs"
                )
  message(STATUS "mkdocs_gen_result: ${mkdocs_gen_result}")
  message(STATUS "mkdocs_gen_error: ${mkdocs_gen_error}")
  message(STATUS "**************************************************************************")
  message(STATUS "mkdocs_gen_output: ${mkdocs_gen_output}")
  message(STATUS "**************************************************************************")


The issue that I am having is that if the mkdocs command fails, the build does NOT show the failure. Is there a way to have the "cmake -P" command pick up the fact that the cmake script failed so that the build fails or throws a warning/error?

Thanks
Mike Jackson



From eric.noulard at gmail.com  Mon Feb 26 16:10:59 2018
From: eric.noulard at gmail.com (Eric Noulard)
Date: Mon, 26 Feb 2018 22:10:59 +0100
Subject: [CMake] Return an Error Code (or something) from a CMake Script.
In-Reply-To: <CAPASGLrQaKkbupPOOx3dXXH6EiKZL7oKT-n-W0ZXRWGVfftumg@mail.gmail.com>
References: <C97F5CB9-496A-4012-AC55-9071635E8A41@bluequartz.net>
 <CAPASGLrQaKkbupPOOx3dXXH6EiKZL7oKT-n-W0ZXRWGVfftumg@mail.gmail.com>
Message-ID: <CAPASGLo15psUJkBXNPCXfN_ZiUFsYtiWNGbhFYQqnxLaRaYN_w@mail.gmail.com>

cmake -P usually do the right thing. Here  you ignore the error because you
only message (STATUS ...)
Try adding message (ERROR ...) or message (FATAL_ERROR ...) when
execute_process producer error and tout custom command should faim.

Le 26 f?vr. 2018 20:19, "Michael Jackson" <mike.jackson at bluequartz.net> a
?crit :

> In our CMake based project I generate a *.cmake file which I call with the
> following bit of code:
>
>   add_custom_target(DREAM3D_MKDOCS_GENERATION ALL
>     COMMAND "${CMAKE_COMMAND}" -P "${docsCmakeFile}"
>     COMMENT "using mkdocs to generate the documentation"
>   )
>
> Inside the generated file is the following cmake command:
>
>   message(STATUS "Starting mkdocs execution. This can take a while.....")
>   execute_process(COMMAND "/path/to/mkdocs" build
>                 OUTPUT_VARIABLE mkdocs_gen_output
>                 RESULT_VARIABLE mkdocs_gen_result
>                 ERROR_VARIABLE mkdocs_gen_error
>                 WORKING_DIRECTORY "/Users/mjackson/DREAM3D-Dev/D
> REAM3D-Build/Debug/Documentation/mkdocs"
>                 )
>   message(STATUS "mkdocs_gen_result: ${mkdocs_gen_result}")
>   message(STATUS "mkdocs_gen_error: ${mkdocs_gen_error}")
>   message(STATUS "*****************************
> *********************************************")
>   message(STATUS "mkdocs_gen_output: ${mkdocs_gen_output}")
>   message(STATUS "*****************************
> *********************************************")
>
>
> The issue that I am having is that if the mkdocs command fails, the build
> does NOT show the failure. Is there a way to have the "cmake -P" command
> pick up the fact that the cmake script failed so that the build fails or
> throws a warning/error?
>
> Thanks
> Mike Jackson
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180226/c99ecab4/attachment.html>

From irwin at beluga.phys.uvic.ca  Mon Feb 26 18:02:21 2018
From: irwin at beluga.phys.uvic.ca (Alan W. Irwin)
Date: Mon, 26 Feb 2018 15:02:21 -0800 (PST)
Subject: [CMake] Return an Error Code (or something) from a CMake Script.
In-Reply-To: <C97F5CB9-496A-4012-AC55-9071635E8A41@bluequartz.net>
References: <C97F5CB9-496A-4012-AC55-9071635E8A41@bluequartz.net>
Message-ID: <alpine.DEB.2.11.1802261450350.2923@enira.zlyna.ubzr>

On 2018-02-26 14:19-0500 Michael Jackson wrote:

> In our CMake based project I generate a *.cmake file which I call with the following bit of code:
>
>  add_custom_target(DREAM3D_MKDOCS_GENERATION ALL
>    COMMAND "${CMAKE_COMMAND}" -P "${docsCmakeFile}"
>    COMMENT "using mkdocs to generate the documentation"
>  )
>
> Inside the generated file is the following cmake command:
>
>  message(STATUS "Starting mkdocs execution. This can take a while.....")
>  execute_process(COMMAND "/path/to/mkdocs" build
>                OUTPUT_VARIABLE mkdocs_gen_output
>                RESULT_VARIABLE mkdocs_gen_result
>                ERROR_VARIABLE mkdocs_gen_error
>                WORKING_DIRECTORY "/Users/mjackson/DREAM3D-Dev/DREAM3D-Build/Debug/Documentation/mkdocs"
>                )
>  message(STATUS "mkdocs_gen_result: ${mkdocs_gen_result}")
>  message(STATUS "mkdocs_gen_error: ${mkdocs_gen_error}")
>  message(STATUS "**************************************************************************")
>  message(STATUS "mkdocs_gen_output: ${mkdocs_gen_output}")
>  message(STATUS "**************************************************************************")
>
>
> The issue that I am having is that if the mkdocs command fails, the build does NOT show the failure. Is there a way to have the "cmake -P" command pick up the fact that the cmake script failed so that the build fails or throws a warning/error?

Hi Mike:

I think you already have a good specific answer to your question, but
just out of curiosity could this CMake script approach be replaced by
executing "/path/to/mkdocs" as the COMMAND in a custom command where
your DREAM3D_MKDOCS_GENERATION custom target DEPENDS on the OUTPUT of
that custom command?  Or are there reasons not to implement this more
usual custom command/custom target approach in this case?

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
__________________________

From mike.jackson at bluequartz.net  Tue Feb 27 08:25:21 2018
From: mike.jackson at bluequartz.net (Michael Jackson)
Date: Tue, 27 Feb 2018 08:25:21 -0500
Subject: [CMake] Return an Error Code (or something) from a CMake Script.
In-Reply-To: <alpine.DEB.2.11.1802261450350.2923@enira.zlyna.ubzr>
References: <C97F5CB9-496A-4012-AC55-9071635E8A41@bluequartz.net>
 <alpine.DEB.2.11.1802261450350.2923@enira.zlyna.ubzr>
Message-ID: <5EFCB929-542E-4E87-9965-72CC7B753DA2@bluequartz.net>

-----Original Message-----
From: "Alan W. Irwin" <irwin at beluga.phys.uvic.ca>
Date: Monday, February 26, 2018 at 6:02 PM
To: Michael Jackson <mike.jackson at bluequartz.net>
Cc: CMake Mail List <cmake at cmake.org>
Subject: Re: [CMake] Return an Error Code (or something) from a CMake Script.

    On 2018-02-26 14:19-0500 Michael Jackson wrote:
    
    > In our CMake based project I generate a *.cmake file which I call with the following bit of code:
    >
    >  add_custom_target(DREAM3D_MKDOCS_GENERATION ALL
    >    COMMAND "${CMAKE_COMMAND}" -P "${docsCmakeFile}"
    >    COMMENT "using mkdocs to generate the documentation"
    >  )
    >
    > Inside the generated file is the following cmake command:
    >
    >  message(STATUS "Starting mkdocs execution. This can take a while.....")
    >  execute_process(COMMAND "/path/to/mkdocs" build
    >                OUTPUT_VARIABLE mkdocs_gen_output
    >                RESULT_VARIABLE mkdocs_gen_result
    >                ERROR_VARIABLE mkdocs_gen_error
    >                WORKING_DIRECTORY "/Users/mjackson/DREAM3D-Dev/DREAM3D-Build/Debug/Documentation/mkdocs"
    >                )
    >  message(STATUS "mkdocs_gen_result: ${mkdocs_gen_result}")
    >  message(STATUS "mkdocs_gen_error: ${mkdocs_gen_error}")
    >  message(STATUS "**************************************************************************")
    >  message(STATUS "mkdocs_gen_output: ${mkdocs_gen_output}")
    >  message(STATUS "**************************************************************************")
    >
    >
    > The issue that I am having is that if the mkdocs command fails, the build does NOT show the failure. Is there a way to have the "cmake -P" command pick up the fact that the cmake script failed so that the build fails or throws a warning/error?
    
    Hi Mike:
    
    I think you already have a good specific answer to your question, but
    just out of curiosity could this CMake script approach be replaced by
    executing "/path/to/mkdocs" as the COMMAND in a custom command where
    your DREAM3D_MKDOCS_GENERATION custom target DEPENDS on the OUTPUT of
    that custom command?  Or are there reasons not to implement this more
    usual custom command/custom target approach in this case?
    
    Alan
    __________________________
    Alan W. Irwin
    
Alan,
    There was a lot in that .cmake file that I left out. In order for the mkdocs to work all of our documentation has to be in the same folder (At least it makes it much easier) so during cmake time we generate the file with about 30~40 directory copy commands in it. We could do all of that in the mail cmake files but our project is starting to get overwhelmed with targets which makes opening it up on IDE's like Visual Studio and Xcode take a long time and the organization within those IDEs is frightful sometimes. So we factored out "copy" commands into a single file.

Mike Jackson



From james at 3dengineer.com  Tue Feb 27 11:03:58 2018
From: james at 3dengineer.com (James Swift)
Date: Tue, 27 Feb 2018 17:03:58 +0100
Subject: [CMake] Generate Visual Studio 2017 project with Basic Runtime
 Checks off
Message-ID: <CAMQS46qPy6Bt8jnK8Y0v+ps89Hcu6u1Rj5eSpsqyJFG5U6=6iQ@mail.gmail.com>

Hi,

I'm trying to generate a VS project where Basic Runtime Checks `/RTC1`
is not set for a file in a debug build.

with this minimal example

```
project(testrtc)
add_executable(testrtc testrtc.c)
```

`cmake . -G "Visual Studio 15 2017"`

the switch `/RTC1` is set for the Debug configuration.

Is there a way to force it off?

thanks,
James

From robert.maynard at kitware.com  Tue Feb 27 11:27:32 2018
From: robert.maynard at kitware.com (Robert Maynard)
Date: Tue, 27 Feb 2018 11:27:32 -0500
Subject: [CMake] [ANNOUNCE] CMake 3.11.0-rc2 is now ready for testing
Message-ID: <CAFzjYVpYVk+GFsALrgR6V63_9kUmdcwzT4VhgM1mYhAd0hE9Dg@mail.gmail.com>

I am proud to announce the second CMake 3.11 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.11

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.11/release/3.11.html

Some of the more significant changes in CMake 3.11 are:

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE_<LANG>_COMPILER_LAUNCHER" variable and
  "<LANG>_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" Generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.

* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.

* The "COMPILE_DEFINITIONS" source file property learned to support
  "generator expressions".

* A "COMPILE_OPTIONS" source file property was added to manage list
  of options to pass to the compiler.

* When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
  parallel "moc" or "uic" processes to reduce the build time. A new
  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
  property may be set to specify the number of parallel "moc" or "uic"
  processes to start.  The default is derived from the number of CPUs
  on the host.


CMake 3.11 Release Notes
************************

Changes made since CMake 3.10 include the following.


New Features
============


Platforms
---------

* TI C/C++ compilers are now supported by the "Ninja" generator.


Generators
----------

* The "CodeBlocks" extra generator learned to check a
  "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler
  identification value to place in the project file.

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE_<LANG>_COMPILER_LAUNCHER" variable and
  "<LANG>_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.


Commands
--------

* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC"
  and "NETRC_FILE" options to specify use of a ".netrc" file.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.


Variables
---------

* A "CMAKE_GENERATOR_INSTANCE" variable was introduced to hold the
  selected instance of the generator's corresponding native tools if
  multiple are available.  This is used by the "Visual Studio 15 2017"
  generator to hold the selected instance of Visual Studio
  persistently.

* A "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added
  to enable setting of default permissions for directories created
  implicitly during installation of files by "install()" and
  "file(INSTALL)", e.g. during "make install".

* A "CMAKE_JOB_POOLS" variable was added specify a value to use for
  the "JOB_POOLS" property. This enables control over build
  parallelism with command line configuration parameters when using
  the Ninja generator.

* The "CMAKE_NETRC" and "CMAKE_NETRC_FILE" variables were added to
  specify use of a ".netrc" file by the "file(DOWNLOAD)" and
  "file(UPLOAD)" commands and the "ExternalProject" module.

* A "CMAKE_CUDA_SEPARABLE_COMPILATION" variable was added to
  initialize the "CUDA_SEPARABLE_COMPILATION" target property on
  targets when they are created.


Properties
----------

* The "COMPILE_DEFINITIONS" source file property learned to support
  "generator expressions".

* A "COMPILE_OPTIONS" source file property was added to manage list
  of options to pass to the compiler.

* An "IMPORTED_GLOBAL" target property was added to indicate whether
  an IMPORTED target is globally visible. It is automatically set to a
  true value for targets created with the "GLOBAL" option to
  "add_library()" or "add_executable()". Additionally, project code
  may now *promote* a local imported target to be globally visible by
  setting this property to "TRUE".

* An "INCLUDE_DIRECTORIES" source file property was added to specify
  list of preprocessor include file search directories.

* Source file properties "VS_SHADER_DISABLE_OPTIMIZATIONS" and
  "VS_SHADER_ENABLE_DEBUG" have been added to specify more details of
  ".hlsl" sources with Visual Studio Generators.


Modules
-------

* The "CheckIncludeFile" module "check_include_file" macro learned
  to honor the "CMAKE_REQUIRED_LIBRARIES" variable.

* The "CheckIncludeFileCXX" module "check_include_file_cxx" macro
  learned to honor the "CMAKE_REQUIRED_LIBRARIES" variable.

* The "CheckIncludeFiles" module "check_include_files" macro learned
  to honor the "CMAKE_REQUIRED_LIBRARIES" variable.

* The "CheckIncludeFiles" module "CHECK_INCLUDE_FILES()" command
  gained a "LANGUAGE" option to specify whether to check using the "C"
  or "CXX" compiler.

* The "CMakePackageConfigHelpers" module
  "write_basic_package_version_file()" command learned a new
  "SameMinorVersion" mode for the "COMPATIBILITY" argument.

* The "ExternalProject" module learned to substitute
  "<DOWNLOAD_DIR>" in comments, commands, working directory and
  byproducts.

* The "ExternalProject" module gained "NETRC" and "NETRC_FILE"
  options to specify use of a ".netrc" file.

* A new "FetchContent" module was added which supports populating
  content at configure time using any of the download/update methods
  supported by "ExternalProject_Add()".  This allows the content to be
  used immediately during the configure stage, such as with
  "add_subdirectory()", etc.  Hierarchical project structures are well
  supported, allowing parent projects to override the content details
  of child projects and ensuring content is not populated multiple
  times throughout the whole project tree.

* The "FindBLAS" and "FindLAPACK" modules learned to support FLAME
  "blis" and "libflame".

* The "FindDoxygen" module "doxygen_add_docs()" function now
  supports a new "DOXYGEN_VERBATIM_VARS" list variable.  Any
  "DOXYGEN_..." variable contained in that list will bypass the
  automatic quoting logic, leaving its contents untouched when
  transferring them to the output "Doxyfile".

* A "FindIconv" module was added to locate iconv support.

* The "GenerateExportHeader" module "GENERATE_EXPORT_HEADER" command
  gained an "INCLUDE_GUARD_NAME" option to change the name of the
  include guard symbol written to the generated export header.
  Additionally, it now adds a comment after the closing "#endif" on
  the generated export header's include guard.

* The "UseJava" module "add_jar" command gained a
  "GENERATE_NATIVE_HEADERS" option to generate native header files
  using "javac -h" for "javac" 1.8 or above.  This supersedes
  "create_javah", which no longer works with JDK 1.10 and above due to
  removal of the "javah" tool by JEP 313.


Autogen
-------

* When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
  parallel "moc" or "uic" processes to reduce the build time. A new
  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
  property may be set to specify the number of parallel "moc" or "uic"
  processes to start.  The default is derived from the number of CPUs
  on the host.


CTest
-----

* The "ctest_start()" command no longer sets
  "CTEST_RUN_CURRENT_SCRIPT" due to issues with scoping if it is
  called from inside a function. Instead, it sets an internal variable
  in CTest. However, setting "CTEST_RUN_CURRENT_SCRIPT" to 0 at the
  global scope still prevents the script from being re-run at the end.


CPack
-----

* "cpack(1)" gained "--trace" and "--trace-expand" options.

* The "CPackIFW" module gained new
  "CPACK_IFW_PACKAGE_REMOVE_TARGET_DIR" variable to control if the
  target directory should not be deleted when uninstalling.

* The "CPackRPM" module learned to enable enforcing of execute
  privileges on programs and shared libraries. See
  "CPACK_RPM_INSTALL_WITH_EXEC" variable.

* A "CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable was added
  which serves the same purpose during packaging (e.g. "make package")
  as the "CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS" variable serves
  during installation (e.g. "make install").


Other
-----

* Alias Targets may now alias Imported Targets that are created with
  the "GLOBAL" option to "add_library()".

* Interface Libraries may now have custom properties set on them if
  they start with either an underscore ("_") or a lowercase ASCII
  character. The original intention was to only allow properties which
  made sense for "INTERFACE" libraries, but it also blocked usage of
  custom properties.

* The "cmake(1)" "--open <dir>" command-line option was added to
  open generated IDE projects like Visual Studio solutions or Xcode
  projects.


Deprecated and Removed Features
===============================

* An explicit deprecation diagnostic was added for policies
  "CMP0037" through "CMP0054" ("CMP0036" and below were already
  deprecated). The "cmake-policies(7)" manual explains that the OLD
  behaviors of all policies are deprecated and that projects should
  port to the NEW behaviors.

* The "KDevelop3" generator has been removed.


Other Changes
=============

* Policy "CMP0037" no longer reserves target names associated with
  optional features, such as "test" and "package", unless the
  corresponding feature is enabled.

* The "FindOpenGL" module now prefers GLVND libraries if available.
  See policy "CMP0072".

* The minimum deployment target set in the
  "CMAKE_OSX_DEPLOYMENT_TARGET" variable used to be only applied for
  macOS regardless of the selected SDK.  It is now properly set for
  the target platform selected by "CMAKE_OSX_SYSROOT". For example, if
  the sysroot variable specifies an iOS SDK then the value in
  "CMAKE_OSX_DEPLOYMENT_TARGET" is interpreted as minimum iOS version.

* The "Xcode" generator behavior of generating one project file per
  "project()" command may now be controlled with the
  "CMAKE_XCODE_GENERATE_TOP_LEVEL_PROJECT_ONLY" variable. This could
  be useful to speed up the CMake generation step for large projects
  and to work-around a bug in the "ZERO_CHECK" logic.

* Since the "CMakeCache.txt" format does not support newlines in
  values, values containing newlines are now truncated before writing
  to the file. In addition, a warning comment is written to the cache
  file, and a warning message is displayed to the user on the console.

----------------------------------------------------------------------------
Changes made since CMake 3.11.0-rc1:

Bernhard M. Wiedemann (1):
      Tests: Fix TIMESTAMP-UnixTime test under SOURCE_DATE_EPOCH=1

Brad King (4):
      Tests: Make CompileFeatures C dialect check consistent with impl
      CMakeLib: Link to system thread libraries to support std::thread
      Modules: Restore recently removed search path suffixes
      CMake 3.11.0-rc2

Gregor Jasny (1):
      Xcode: Generate ZERO_CHECK generator target only once

Grzegorz Dobinski (1):
      Compiler/TI: Fix depfile generation for C++

Sebastian Holtermann (2):
      Autogen: Doc: Extend AUTOGEN_TARGET_DEPENDS documentation
      Autogen: Doc: Extend AUTOMOC_DEPEND_FILTERS documentation

Shane Parris (1):
      Help: Fix command references in CMAKE_NETRC* variable documentation

From forums.jakob at resfarm.de  Tue Feb 27 11:30:50 2018
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Tue, 27 Feb 2018 17:30:50 +0100
Subject: [CMake] Configuration issues on AIX
Message-ID: <CA+ovNC4SGNcaqa2S_H7ADCGwxdg++wPijrBJsFMbb+p4qrN5qg@mail.gmail.com>

Hello,

In search for a new build tool for an existing project, I wanted to
give CMake 3.6.3 a try on AIX 5.3 with gcc 4.0.0, but quickly hit
obstacles with the GCC compiler identification and the file(STRINGS)
command. What I am looking for is guidance on how to solve the issues,
and for info whether I might miss some prerequisites, or whether there
are any workarounds I could temporarily put in place to get a first
build going.

Given this simple CMakeLists.txt:

    cmake_minimum_required(VERSION 3.6)
    project(foo LANGUAGES C)
    add_executable(hello main.c)
    # where main.c is just a printf hello world program

It does not recognize the compiler identification:

<<<<<<<<<<<<<
$ (mkdir -p build && cd build && cmake ..)
-- The C compiler identification is unknown
-- Check for working C compiler: /usr/bin/gcc
CMake Error at /opt/freeware/share/cmake/Modules/CMakeTestCCompiler.cmake:47
(try_compile):
  Unknown extension ".c" for file

    /home/.../build/CMakeFiles/CMakeTmp/testCCompiler.c

  try_compile() works only for enabled languages.  Currently these are:

    C

  See project() command to enable other languages.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Check for working C compiler: /usr/bin/gcc -- broken
CMake Error at /opt/freeware/share/cmake/Modules/CMakeTestCCompiler.cmake:61
(message):
  The C compiler "/usr/bin/gcc" is not able to compile a simple test program.

  It fails with the following output:





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "/home/.../build/CMakeFiles/CMakeOutput.log".
See also "/home/.../build/CMakeFiles/CMakeError.log".
>>>>>>>>>>>>>



I got hold of the try_compile output and it contains the following info:

    $ strings -a a.out | grep INFO
    INFO:compiler[GNU]
    INFO:platform[AIX]
    INFO:arch[]
    INFO:dialect_default[90]
    INFO:compiler_version[00000004.00000000.00000000]

Yet, the CMakeError.log states: The C compiler identification could
not be found in "/home/.../build/CMakeFiles/3.6.3/CompilerIdC/a.out"

I followed this up to the file(STRING ...) command in
CMakeDetermineCompilerId.cmake and noticed that the command seems
unable to grep any strings out of any file:

    file(STRINGS CMakeLists.txt strs)
    message("strs: ${strs}")
    file(STRINGS a.out strs) # copied the CompilerIdC/a.out file to
the source tree
    message("strs: ${strs}")

Output is
strs:
strs:

So not even the CMakeLists.txt contained any strings according to
this. Reading the file with file(READ CMakeLists.txt strs) worked,
however. On my windows machine with CMake 3.6.2 it works as expected
with the same input files (copied from the AIX machine).

Meanwhile I tried to specify the compiler identification manually with
cmake -DCMAKE_C_COMPILER_ID=GNU, but the output is about the same,
including the "Unknown extension .c for file testCCompiler.c" message.
The CMakeError.log now only contains "Determining if the C compiler
works failed with the following output: [nothing]".

Any hints? Tell if you need any specific additional information, please.

Kind regards,
Jakob


From dave.demarle at kitware.com  Tue Feb 27 14:42:31 2018
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 27 Feb 2018 14:42:31 -0500
Subject: [CMake] reminder: free VTK,
 ParaView and CMake training at Kitware New York in two weeks.
Message-ID: <CANjZAi_T6QjF2G-MRUmo1LpXexYNOw-YhxdER3UnHhHjOy3TMg@mail.gmail.com>

Read all about it in this blog post:
https://blog.kitware.com/events/march2018-free-vtk-paraview-and-cmake-training-courses-kitware

There are a few  seats available in case you can make it up to visit us.
https://goo.gl/forms/M3WmJcV9W6qKTK8x2

Thanks and hope to see you here.

David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180227/b06b4686/attachment.html>

From brad.king at kitware.com  Wed Feb 28 07:22:20 2018
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Feb 2018 07:22:20 -0500
Subject: [CMake] Configuration issues on AIX
In-Reply-To: <CA+ovNC4SGNcaqa2S_H7ADCGwxdg++wPijrBJsFMbb+p4qrN5qg@mail.gmail.com>
References: <CA+ovNC4SGNcaqa2S_H7ADCGwxdg++wPijrBJsFMbb+p4qrN5qg@mail.gmail.com>
Message-ID: <18229e87-7c60-4d17-4374-e1db249434da@kitware.com>

On 02/27/2018 11:30 AM, Jakob Reschke wrote:
> I followed this up to the file(STRING ...) command ... seems
> unable to grep any strings out of any file:

Strange.  That will need to be solved before anything can be
expected to work.  Where did you get the CMake binary?

FYI we've had nightly testing on AIX with both XL and GNU compilers
for years so CMake should work.

-Brad

From forums.jakob at resfarm.de  Wed Feb 28 12:59:02 2018
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Wed, 28 Feb 2018 18:59:02 +0100
Subject: [CMake] Configuration issues on AIX
In-Reply-To: <18229e87-7c60-4d17-4374-e1db249434da@kitware.com>
References: <CA+ovNC4SGNcaqa2S_H7ADCGwxdg++wPijrBJsFMbb+p4qrN5qg@mail.gmail.com>
 <18229e87-7c60-4d17-4374-e1db249434da@kitware.com>
Message-ID: <CA+ovNC4AzQJ6=ZUDbAd+e=KMuXiiFQW6Ycax3wVwzcK1tFhDoQ@mail.gmail.com>

2018-02-28 13:22 GMT+01:00 Brad King <brad.king at kitware.com>:
> On 02/27/2018 11:30 AM, Jakob Reschke wrote:
>> I followed this up to the file(STRING ...) command ... seems
>> unable to grep any strings out of any file:
>
> Strange.  That will need to be solved before anything can be
> expected to work.  Where did you get the CMake binary?

Someone else had to install it for me and I pointed them to this
location, so I assume it comes from there:
http://www.perzl.org/aix/index.php?n=Main.Cmake
I will ask them again to confirm, and will amend otherwise.

> FYI we've had nightly testing on AIX with both XL and GNU compilers
> for years so CMake should work.

Yes, I have seen the builds mentioned somewhere, which gives me hope
that it could be fixed on our machines.

From brad.king at kitware.com  Wed Feb 28 13:04:48 2018
From: brad.king at kitware.com (Brad King)
Date: Wed, 28 Feb 2018 13:04:48 -0500
Subject: [CMake] Configuration issues on AIX
In-Reply-To: <CA+ovNC4AzQJ6=ZUDbAd+e=KMuXiiFQW6Ycax3wVwzcK1tFhDoQ@mail.gmail.com>
References: <CA+ovNC4SGNcaqa2S_H7ADCGwxdg++wPijrBJsFMbb+p4qrN5qg@mail.gmail.com>
 <18229e87-7c60-4d17-4374-e1db249434da@kitware.com>
 <CA+ovNC4AzQJ6=ZUDbAd+e=KMuXiiFQW6Ycax3wVwzcK1tFhDoQ@mail.gmail.com>
Message-ID: <c02eaa60-7243-040e-5496-6d0b027d8b99@kitware.com>

On 02/28/2018 12:59 PM, Jakob Reschke wrote:
> Yes, I have seen the builds mentioned somewhere, which gives me hope
> that it could be fixed on our machines.

You could also try bootstrapping CMake from source.  Doing so with
GNU on AIX is supported.

-Brad

From forums.jakob at resfarm.de  Wed Feb 28 13:24:15 2018
From: forums.jakob at resfarm.de (Jakob Reschke)
Date: Wed, 28 Feb 2018 19:24:15 +0100
Subject: [CMake] Configuration issues on AIX
In-Reply-To: <c02eaa60-7243-040e-5496-6d0b027d8b99@kitware.com>
References: <CA+ovNC4SGNcaqa2S_H7ADCGwxdg++wPijrBJsFMbb+p4qrN5qg@mail.gmail.com>
 <18229e87-7c60-4d17-4374-e1db249434da@kitware.com>
 <CA+ovNC4AzQJ6=ZUDbAd+e=KMuXiiFQW6Ycax3wVwzcK1tFhDoQ@mail.gmail.com>
 <c02eaa60-7243-040e-5496-6d0b027d8b99@kitware.com>
Message-ID: <CA+ovNC6BnUZyKX+TfmqT+f_D+NRunVh5LVKEdbB5PGOxxJDa=Q@mail.gmail.com>

2018-02-28 19:04 GMT+01:00 Brad King <brad.king at kitware.com>:
> On 02/28/2018 12:59 PM, Jakob Reschke wrote:
>> Yes, I have seen the builds mentioned somewhere, which gives me hope
>> that it could be fixed on our machines.
>
> You could also try bootstrapping CMake from source.  Doing so with
> GNU on AIX is supported.

There is no C++ compiler on the machine yet (only C), but I could ask
whether they can install the compiler for me as well. It might take
some time until it happens, though. If there is anything else I could
try in the meantime, please let me know.