Re: [CMake] swig module add -fPIC flag

[CHEVRIER, Marc]

swig modules created with command SWIG_ADD_LIBRARY are "standard" CMake targets 
so, same approach apply.


>From convenience, you can use command SWIG_LINK_LIBRARIES (same semantic as 
>TARGET_LINK_LIBRARIES) to manage custom link flags.


Now, regarding specifically flag -fPIC you can manage more easily and in a 
portable way the 'Position Independent Code' generation by setting variable 
CMAKE_POSITION_INDEPENDENT_CODE=ON. And I think this flag is for the compiler, 
not the linker...



From: CMake  on behalf of Stéphane Ancelot 

Sent: Wednesday, April 25, 2018 3:40:45 PM
To: cmake@cmake.org
Subject: [CMake] swig module add -fPIC flag

Hi,

I have not found how to add -fPIC link flag to a SWIG module.

Regards

S.Ancelot

--

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

Re: [CMake] Generator expressions containing spaces

[CHEVRIER, Marc]

The space is used to separate arguments passed to COMMAND. So your generator 
expression is splitted before evaluation and elements are no longer valid 
generator expression.

So, to solve your problem, encapsulate the generator expression inside quotes. 
And apply the following advices for correct result:

  *   Separate command from args
  *   Use variable to list your arguments and add option COMMAND_EXPAND_LISTS 
(available with version 3.8) to avoid “spurious” semi-colons in the result

Your example reworked:

Set (args foo bar)
add_custom_target(foo)
add_custom_command(TARGET foo POST_BUILD
  COMMAND $<1:echo> "$<1 :${args}>"
  COMMAND_EXPAND_LISTS
  )


From: CMake  on behalf of Yves Frederix 

Date: Monday 23 April 2018 at 13:08
To: "cmake@cmake.org" 
Subject: [CMake] Generator expressions containing spaces

Hi,

I recently learned that the COMMAND line in a custom command supports generator 
expressions. In particular, what makes this powerful is that if the expression 
evaluates to the empty string, no corresponding code will be added to the 
target (as documented in the 
docs).

While this works very nicely for single-string command, I fail to make it work 
for commands consisting of multiple space-separated strings:

```
~/tmp/genex_with_spaces$ cat CMakeLists.txt 
 cmake_minimum_required(VERSION 
3.6)

add_custom_target(foo)
add_custom_command(TARGET foo POST_BUILD
  COMMAND $<1:echo bar>
  )

~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make   
 "\$$<1:echo" bar>
```

As can be seen, the generator expression is not expanded.

My question is now whether I am doing something wrong (is there a correct way 
of dealing with spaces in the context of generator expressions?) or might this 
be an inherent limitation of generator expression in general?

As a workaround, the only thing that seems to work is to put each of the 
space-separated components of the command in (typically identical) genexes:

```
~/tmp/genex_with_spaces$ cat CMakeLists.txt 
 cmake_minimum_required(VERSION 
3.6)

add_custom_target(foo)
add_custom_command(TARGET foo POST_BUILD
  COMMAND $<1:echo> $<1:bar>
  )

~/tmp/genex_with_spaces$ grep bar build/CMakeFiles/foo.dir/build.make   
 echo bar
```

Of course, while this works, things becomes very unreadable if the genex is 
more complex.

Other things that I have tried but failed:

  *   escape the space with a backslash -> this quotes the entire expression 
inside the genex.
  *   define the command directly as a list inside the genex -> this removes 
spaces between the different components of the command and quotes that result.
  *   treat the command as a list, perform string operations to wrap each 
element in the desired regex and convert semicolon to spaces -> again results 
in the command being quoted as a whole.

Any advice is highly appreciated.

Thanks,
Yves





-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] find_package and get_target_property

[CHEVRIER, Marc]

Using ‘install(EXPORT …)’ you can generate required files to manage imported 
targets BUT building and exporting targets must be done in a different build 
environment from the one which imports the targets.


From: Saad Khattak <saadrus...@gmail.com>
Date: Friday 13 April 2018 at 15:02
To: "CHEVRIER, Marc" <marc.chevr...@sap.com>
Subject: Re: [CMake] find_package and get_target_property

Ah I see. In this case, the Libraries I'm depending on are generated, built and 
installed using CMake. I'm hoping that CMake is able to generate the 
Find.cmake for me with the appropriate imported targets, as long as 
INSTALL(export...) was used properly...?

On Fri, Apr 13, 2018 at 8:58 AM CHEVRIER, Marc 
<marc.chevr...@sap.com<mailto:marc.chevr...@sap.com>> wrote:
Not necessarily. It depends how the package was created. Using EXPORT is a 
possibility to generate a Config file for the package.
Another possibility is to have a FindLibA.cmake file which creates an imported 
target by using command ‘add_library (LibA SHARED IMPORTED)’.


From: Saad Khattak <saadrus...@gmail.com<mailto:saadrus...@gmail.com>>
Date: Friday 13 April 2018 at 14:50
To: "CHEVRIER, Marc" <marc.chevr...@sap.com<mailto:marc.chevr...@sap.com>>
Cc: Cmake Mailing List <cmake@cmake.org<mailto:cmake@cmake.org>>
Subject: Re: [CMake] find_package and get_target_property

Thanks Marc. I assume you mean the library does not export its targets 
properly? Something like this:

# https://cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets
install(TARGETS generator DESTINATION lib/myproj/generators EXPORT 
myproj-targets)
install(EXPORT myproj-targets DESTINATION lib/myproj)

On Fri, Apr 13, 2018 at 3:05 AM CHEVRIER, Marc 
<marc.chevr...@sap.com<mailto:marc.chevr...@sap.com>> wrote:
The creation of “imported” target is the responsibility of the package. May be 
the package “LibA” does not create a such target.
In this case, you have to rely on variables (like LibA_LIBRARIES and so on…). 
The documentation of the package, if any, generally describe how to use the 
package.


From: CMake <cmake-boun...@cmake.org<mailto:cmake-boun...@cmake.org>> on behalf 
of Saad Khattak <saadrus...@gmail.com<mailto:saadrus...@gmail.com>>
Date: Friday 13 April 2018 at 05:29
To: Cmake Mailing List <cmake@cmake.org<mailto:cmake@cmake.org>>
Subject: [CMake] find_package and get_target_property

Hi,

I am successfully able to find a package using find_package(LibA) but I cannot 
do a get_target_property on the package as I get the error:

get_target_property() called with non-existent target "LibA"

How do I go about the target properties for a package?

- Saad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] find_package and get_target_property

[CHEVRIER, Marc]

The creation of “imported” target is the responsibility of the package. May be 
the package “LibA” does not create a such target.
In this case, you have to rely on variables (like LibA_LIBRARIES and so on…). 
The documentation of the package, if any, generally describe how to use the 
package.


From: CMake  on behalf of Saad Khattak 

Date: Friday 13 April 2018 at 05:29
To: Cmake Mailing List 
Subject: [CMake] find_package and get_target_property

Hi,

I am successfully able to find a package using find_package(LibA) but I cannot 
do a get_target_property on the package as I get the error:

get_target_property() called with non-existent target "LibA"

How do I go about the target properties for a package?

- Saad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Generator expression for "is in list"?

[CHEVRIER, Marc]

Operator IN_LIST in generator expressions will be available in CMake version 
3.12, (i.e. the next version).
In the meantime, I am afraid there is no solution in the context of generator 
expressions. However, you can directly use the contents of the property in your 
CMakeLists.txt.
Example:
get_property (link_libs TARGET mytarget PROPERTY LINK_LIBRARIES)
if (“mylib” IN_LIST link_libs)
   …
endif()

The only difference is the evaluation time:

  *   Generator expressions are evaluated after all CMakeLists.txt processing, 
so any changes to the target done AFTER the use of 
$ will be taken into account.
  *   Using get_property: evaluation is done at the point where the command is 
used, so any changes done AFTER will NOT be taken into account




From: CMake  on behalf of Sam Edwards 

Date: Saturday 7 April 2018 at 23:35
To: "cmake@cmake.org" 
Subject: [CMake] Generator expression for "is in list"?

Hello list!

I'm trying to write a generator expression that only evaluates if my target is 
directly (not transitively) linked into the consuming target. I figured the 
easiest way to do that would be to test if the target's name appears in 
$, however I'm not seeing a generator 
expression for substring or "string in list" tests.

What is the preferred way to accomplish this?

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

Re: [cmake-developers] Is the "cmake_policy (VERSION 3.11)" statement in the latest UseSWIG.cmake correct?

[CHEVRIER, Marc]

Yes, the "cmake_policy" command is here on purpose because the "new" module 
rely on features (mainly source properties) introduced in CMake version 3.11.

On 04/04/2018 21:18, "cmake-developers on behalf of Alan W. Irwin" 
 
wrote:

According to
, an
important side effect of "cmake_policy (VERSION 3.11)" is that no user
with cmake version less than 3.11.0 can use the latest version of
UseSWIG.cmake.

Was that change intended (i.e., does the latest version of
UseSWIG.cmake use policies AND CMake logic that is only available for
3.11.0 and higher)? If so, fair enough.  But if not (i.e., the latest
version of UseSWIG.cmake would work fine for earlier versions of
CMake) I suggest you adjust the above VERSION 3.11 to the actual
minimum version of CMake that will work with this module to advertise
what range of older versions of CMake can use it as a replacement for
the buggy official UseSWIG.cmake that they would otherwise be using.

This reason this issue has come up for me is that I had to copy the
3.9.1 UseSWIG.cmake module to PLplot to give our users that use older
versions of CMake such as 3.6.2 access to an important bug fix in that
version. And that copy has worked fine for us ever since for those
using, e.g., cmake version 3.6.2.  So as a result I became interested
in the official further development of UseSWIG.cmake module after
3.9.1 in case there were any further bug fixes that would be important
to our users.  And that investigation left me wondering whether that
"cmake_policy (VERSION 3.11)" statement actually states the correct
minimum version of cmake that would work with this module.

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


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] find_package() for static only / shared only

[CHEVRIER, Marc]

Yes. Seems OK.
For Windows, if libraries are all your owns, you can manage this by relaying on 
a specific prefix for static libraries.
A commonly adopted naming is to add prefix "lib" for static libraries.

Now, if you add to rely on external libraries, I don't see any general solution.

On 22/03/2018 12:15, "Mario Emmenlauer" <ma...@emmenlauer.de> wrote:


Dear Marc,

this is a pretty neat idea! Let me quickly recapitulate: the
library prefixes and suffixes for multiple platforms are:

 |  static|   shared
 |   prefix|suffix|   prefix| suffix
-
 Linux   | lib |  .a  | lib |  .so
 MacOSX  | lib |  .a  | lib | .dylib
 MinGW   | lib |  .a  | lib |   .dll.a/.dll
 MSVC|  -  | .lib |  -  |.lib/.dll

Is that about correct? So it should work mostly everywhere with the note-
worthy exception of MSVC, where the shared import library is not easily
discriminated from the static library.

Is there a good solution for MSVC too?

All the best,

   Mario




On 22.03.2018 09:41, CHEVRIER, Marc wrote:
> Another possibility is to customize the variable 
CMAKE_FIND_LIBRARY_SUFFIXES.
> For example, on linux:
> * shared only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".so")
> * static only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".a")
> 
> On Windows, it is more problematic because static and "import" shared 
libraries have same extension: ".lib".
> But, if, by chance, you have different prefixes to distinguish them, you  
can rely on variable CMAKE_FIND_LIBRARY_PREFIXES to manage that.
> 
> 
> On 21/03/2018 10:56, "CMake on behalf of Mario Emmenlauer" 
<cmake-boun...@cmake.org on behalf of ma...@emmenlauer.de> wrote:
> 
> 
> I've googled this issue for a while now but found only few
> references (1,2) and no solution. I'd like to enforce that
> find_package() will only accept static or shared libraries.
> I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF).
> 
> I.e. I'd love to have something like:
> if(BUILD_SHARED_LIBS)
> BUILD_TYPE="SHARED"
> else()
> BUILD_TYPE="STATIC"
> endif()
> find_package(XXX ${BUILD_TYPE})
> find_package(YYY ${BUILD_TYPE})
> find_package(ZZZ ${BUILD_TYPE})
> ...
> 
> 
> It seems that this does not exist? I could also not find a
> good workaround. The best I can find is to use 'NAMES' and
> add the static or shared library names manually.
> 
> This is not very suitable, because I have a project with more
> than 30 dependencies. The project should either build (fully)
> static or (fully) shared. I can not easily maintain lists of
> 30 static and shared library names on several platforms.
> 
> Is there a solution or good workaround?
> 
> All the best,
> 
> Mario Emmenlauer
> 
> 
> (1) https://cmake.org/pipermail/cmake/2012-September/052059.html
> (2) https://cmake.org/pipermail/cmake/2010-December/041326.html
> 
> 
> --
> 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


--
BioDataAnal

Re: [CMake] find_package() for static only / shared only

[CHEVRIER, Marc]

Another possibility is to customize the variable CMAKE_FIND_LIBRARY_SUFFIXES.
For example, on linux:
* shared only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".so")
* static only: set (CMAKE_FIND_LIBRARY_SUFFIXES ".a")

On Windows, it is more problematic because static and "import" shared libraries 
have same extension: ".lib".
But, if, by chance, you have different prefixes to distinguish them, you  can 
rely on variable CMAKE_FIND_LIBRARY_PREFIXES to manage that.


On 21/03/2018 10:56, "CMake on behalf of Mario Emmenlauer" 
 wrote:


I've googled this issue for a while now but found only few
references (1,2) and no solution. I'd like to enforce that
find_package() will only accept static or shared libraries.
I would then set this option based on BUILD_SHARED_LIBS=(ON|OFF).

I.e. I'd love to have something like:
if(BUILD_SHARED_LIBS)
BUILD_TYPE="SHARED"
else()
BUILD_TYPE="STATIC"
endif()
find_package(XXX ${BUILD_TYPE})
find_package(YYY ${BUILD_TYPE})
find_package(ZZZ ${BUILD_TYPE})
...


It seems that this does not exist? I could also not find a
good workaround. The best I can find is to use 'NAMES' and
add the static or shared library names manually.

This is not very suitable, because I have a project with more
than 30 dependencies. The project should either build (fully)
static or (fully) shared. I can not easily maintain lists of
30 static and shared library names on several platforms.

Is there a solution or good workaround?

All the best,

Mario Emmenlauer


(1) https://cmake.org/pipermail/cmake/2012-September/052059.html
(2) https://cmake.org/pipermail/cmake/2010-December/041326.html


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


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] MSYS2 broken CMAKE_PREFIX_PATH

[CHEVRIER, Marc]

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

Re: [CMake] How to add files to Visual Studio 'Utility' project

[CHEVRIER, Marc]

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  on behalf of "J. Caleb Wherry" 

Date: Thursday 1 February 2018 at 19:30
To: CMake ML 
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
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Source file property INCLUDE_DIRECTORIES

[CHEVRIER, Marc]

Sure. APPEND keyword is handled at a high level (i.e. regardless the property 
evolved).

From: J Decker <d3c...@gmail.com>
Date: Friday 12 January 2018 at 15:03
To: "CHEVRIER, Marc" <marc.chevr...@sap.com>
Cc: CMake Mail List <cmake@cmake.org>
Subject: Re: [CMake] Source file property INCLUDE_DIRECTORIES



On Fri, Jan 12, 2018 at 5:26 AM, CHEVRIER, Marc 
<marc.chevr...@sap.com<mailto:marc.chevr...@sap.com>> wrote:
Because this property is not yet supported for source files (see 
#17507<https://gitlab.kitware.com/cmake/cmake/issues/17507>).
FYI, I worked on this support and the merge request is under process… (see 
!1596<https://gitlab.kitware.com/cmake/cmake/merge_requests/1596>).


Okay :) Glad someone is on it.

Will also work for set_property( SOURCE ... APPEND PROPERTY INCLUDE_DIRECTORIES 
) ?


From: CMake <cmake-boun...@cmake.org<mailto:cmake-boun...@cmake.org>> on behalf 
of J Decker <d3c...@gmail.com<mailto:d3c...@gmail.com>>
Date: Friday 12 January 2018 at 14:22
To: CMake Mail List <cmake@cmake.org<mailto:cmake@cmake.org>>
Subject: [CMake] Source file property INCLUDE_DIRECTORIES

Why can't I set INCLUDE_DIRECTORIES for a source file?

https://cmake.org/cmake/help/v3.0/manual/cmake-properties.7.html

I can probably use COMPILE_FLAGS ; but how to guarantee that -I is the proper 
option for every compiler?


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Source file property INCLUDE_DIRECTORIES

[CHEVRIER, Marc]

Because this property is not yet supported for source files (see 
#17507).
FYI, I worked on this support and the merge request is under process… (see 
!1596).


From: CMake  on behalf of J Decker 
Date: Friday 12 January 2018 at 14:22
To: CMake Mail List 
Subject: [CMake] Source file property INCLUDE_DIRECTORIES

Why can't I set INCLUDE_DIRECTORIES for a source file?

https://cmake.org/cmake/help/v3.0/manual/cmake-properties.7.html

I can probably use COMPILE_FLAGS ; but how to guarantee that -I is the proper 
option for every compiler?

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Get find_package to choose INSTALLed libraries instead of libraries in the build folder

[CHEVRIER, Marc]

Hi,

During install step, installed libraries and executables are relinked to 
generate binaries without absolute paths so installed artifacts are independent 
from your build tree.

During build step, build binaries are used as well as absolute paths so 
produced binaries can be used during build step (i.e. launching an executable 
produced) without requirements regarding paths settings (i.e. PATH or 
LD_LIBRARY_PATH).


From: CMake  on behalf of Saad Khattak 

Date: Thursday 11 January 2018 at 19:44
To: Cmake Mailing List 
Subject: [CMake] Get find_package to choose INSTALLed libraries instead of 
libraries in the build folder

Hi,

I would like find_package(MyLib) to link find the libraries found in the 
INSTALL folder instead of the build folder.

Currently, when I do a find_package(MyLib) and then 
target_link_libraries(target MyLib) the paths all point to MyLib's build folder 
and not the folder where MyLib's library/headers were installed.

Thank you,
Saad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] configure_file: escaping (single) quotes

[CHEVRIER, Marc]

Yes, you have to rewrite your line as:
CMD="mpirun -n @MPIEXEC_PREFLAGS@ @MPIEXEC_NUMPROC_FLAG@ @MPIEXEC_MAX_NUMPROCS@ 
@MPIEXEC_POSTFLAGS@"


From: Franck Houssen <franck.hous...@inria.fr>
Date: Tuesday 9 January 2018 at 11:23
To: "CHEVRIER, Marc" <marc.chevr...@sap.com>
Cc: CMake Mail List <cmake@cmake.org>
Subject: Re: [CMake] configure_file: escaping (single) quotes


De: "Marc CHEVRIER" <marc.chevr...@sap.com>
À: "Franck Houssen" <franck.hous...@inria.fr>, "CMake Mail List" 
<cmake@cmake.org>
Envoyé: Mardi 9 Janvier 2018 10:29:30
Objet: Re: [CMake] configure_file: escaping (single) quotes

The problem comes from CMake evaluating variable VAR (i.e. expression ${VAR…}) 
and detect wrong syntax.
The solution is to specify option @ONLY to command configure_file to avoid ${} 
evaluation.

The line after VAR is something like:

VAR="${VAR//'#'/}"

CMD="mpirun -n ${MPIEXEC_PREFLAGS} ${MPIEXEC_NUMPROC_FLAG} 
${MPIEXEC_MAX_NUMPROCS} ${MPIEXEC_POSTFLAGS}"



I need MPIEXEC_* to be replaced. So, I need to use @ONLY and set all MPIEXEC 
variables with @ (but not $). Correct ?




From: CMake <cmake-boun...@cmake.org> on behalf of Franck Houssen 
<franck.hous...@inria.fr>
Date: Tuesday 9 January 2018 at 10:24
To: CMake Mail List <cmake@cmake.org>
Subject: [CMake] configure_file: escaping (single) quotes
VAR="${VAR//'#'/}"

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] configure_file: escaping (single) quotes

[CHEVRIER, Marc]

The problem comes from CMake evaluating variable VAR (i.e. expression ${VAR…}) 
and detect wrong syntax.
The solution is to specify option @ONLY to command configure_file to avoid ${} 
evaluation.


From: CMake  on behalf of Franck Houssen 

Date: Tuesday 9 January 2018 at 10:24
To: CMake Mail List 
Subject: [CMake] configure_file: escaping (single) quotes

VAR="${VAR//'#'/}"
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

[CHEVRIER, Marc]

Hi,

Your assumption is erroneous. INTERFACE keyword is related to dependencies 
behavior against target (see 
target_link_libraries<https://cmake.org/cmake/help/git-master/command/target_link_libraries.html>
 documentation). It do not specify type of target, so IMPORTED libraries will 
work as well.


From: Saad Khattak <saadrus...@gmail.com>
Date: Saturday 16 December 2017 at 00:39
To: "CHEVRIER, Marc" <marc.chevr...@sap.com>
Cc: Craig Scott <craig.sc...@crascit.com>, Cmake Mailing List <cmake@cmake.org>
Subject: Re: [CMake] Using SET_TARGET_PROPERTIES and 
IMPORTED_LINK_INTERFACE_LIBRARIES

Thank you Marc. I found that the following also works:

target_link_libraries(LibD INTERFACE LibA LibB)

However, my guess is that in the future the above may break as it is assuming 
LibD is an INTERFACE instead of an IMPORTED library. I'll switch to your 
version instead as it seems to be more correct.

On Thu, Dec 14, 2017 at 3:40 AM CHEVRIER, Marc 
<marc.chevr...@sap.com<mailto:marc.chevr...@sap.com>> wrote:
I think you can fill a bug about erroneous behaviour when a list is specified 
with command set_target_properties for property 
IMPORTED_LINK_INTERFACE_LIBRARIES.

Another way to specify the property is to use command set_property which 
supports multiple values for a property:
set_property(TARGET LibD PROPERTY IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB)


From: CMake <cmake-boun...@cmake.org<mailto:cmake-boun...@cmake.org>> on behalf 
of Saad Khattak <saadrus...@gmail.com<mailto:saadrus...@gmail.com>>
Date: Thursday 14 December 2017 at 03:20
To: Craig Scott <craig.sc...@crascit.com<mailto:craig.sc...@crascit.com>>
Cc: Cmake Mailing List <cmake@cmake.org<mailto:cmake@cmake.org>>
Subject: Re: [CMake] Using SET_TARGET_PROPERTIES and 
IMPORTED_LINK_INTERFACE_LIBRARIES

Thanks Craig for your reply.

The issue is that both "LibA" and "LibB" have been set using "add_library(LibA 
STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and both have some 
properties that are being set.

Ultimately, CMake recognizes LibA and LibB as CMake library projects, and they 
have their own include and link directories and other library dependencies.

The nice thing about using LibA directly is then LibD inherits all the include 
and link directories of LibA and LibB which then get inherited by any library 
or executable that includes LibD (and ultimately, the whole point of modern 
CMake):

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as IMPORTED 
CMake libraries
)

If I use "LibA;LibB" then first, I have to manually extract the library names 
of the imported CMake libraries LibA and LibB. Then, I have to call 
"target_include_directories" and "target_link_libraries" for all dependencies 
of LibA and LibB, even though these dependencies were defined in their own 
respective CMake files when calling "add_library(LibA STATIC IMPORTED)"

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer recognizes 
LibA and LibB as IMPORTED CMake libraries
)

Regards,
Saad

On Wed, Dec 13, 2017 at 4:32 PM Craig Scott 
<craig.sc...@crascit.com<mailto:craig.sc...@crascit.com>> wrote:
On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak 
<saadrus...@gmail.com<mailto:saadrus...@gmail.com>> wrote:
Hi,

I have several imported libraries:

LibA
LibB
LibC

Where each imported library has been populated by (where ${LIB_NAME} is either 
LibA, LibB or LibC):

add_library(${LIB_NAME} STATIC IMPORTED)

And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set 
properly:

set_target_properties(${LIB_NAME}
PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
   "location/of/library.lib"
)

Now let's say I have another imported library LibD that depends on LibA and 
LibB such that any executable that uses LibD must also link with LibA and LibB. 
To do that, I use:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
  )

You probably want this instead:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
)

Note that if the property value is a list, you have to provide it as a single 
string (i.e. "LibA;LibB" rather than LibA LibB)



--
Craig Scott
Melbourne, Australia
https://crascit.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

Re: [CMake] Using SET_TARGET_PROPERTIES and IMPORTED_LINK_INTERFACE_LIBRARIES

[CHEVRIER, Marc]

I think you can fill a bug about erroneous behaviour when a list is specified 
with command set_target_properties for property 
IMPORTED_LINK_INTERFACE_LIBRARIES.

Another way to specify the property is to use command set_property which 
supports multiple values for a property:
set_property(TARGET LibD PROPERTY IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB)


From: CMake  on behalf of Saad Khattak 

Date: Thursday 14 December 2017 at 03:20
To: Craig Scott 
Cc: Cmake Mailing List 
Subject: Re: [CMake] Using SET_TARGET_PROPERTIES and 
IMPORTED_LINK_INTERFACE_LIBRARIES

Thanks Craig for your reply.

The issue is that both "LibA" and "LibB" have been set using "add_library(LibA 
STATIC IMPORTED)" and "add_library(LibB IMPORTED)" and both have some 
properties that are being set.

Ultimately, CMake recognizes LibA and LibB as CMake library projects, and they 
have their own include and link directories and other library dependencies.

The nice thing about using LibA directly is then LibD inherits all the include 
and link directories of LibA and LibB which then get inherited by any library 
or executable that includes LibD (and ultimately, the whole point of modern 
CMake):

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES LibA #cmake recognizes LibA as IMPORTED 
CMake libraries
)

If I use "LibA;LibB" then first, I have to manually extract the library names 
of the imported CMake libraries LibA and LibB. Then, I have to call 
"target_include_directories" and "target_link_libraries" for all dependencies 
of LibA and LibB, even though these dependencies were defined in their own 
respective CMake files when calling "add_library(LibA STATIC IMPORTED)"

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB" #cmake no longer recognizes 
LibA and LibB as IMPORTED CMake libraries
)

Regards,
Saad

On Wed, Dec 13, 2017 at 4:32 PM Craig Scott 
> wrote:
On Thu, Dec 14, 2017 at 8:22 AM, Saad Khattak 
> wrote:
Hi,

I have several imported libraries:

LibA
LibB
LibC

Where each imported library has been populated by (where ${LIB_NAME} is either 
LibA, LibB or LibC):

add_library(${LIB_NAME} STATIC IMPORTED)

And each library has the properties IMPORT_LOCATION_${CONFIGURATION} set 
properly:

set_target_properties(${LIB_NAME}
PROPERTIES IMPORTED_LOCATION_DEBUG # same for release
   "location/of/library.lib"
)

Now let's say I have another imported library LibD that depends on LibA and 
LibB such that any executable that uses LibD must also link with LibA and LibB. 
To do that, I use:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES LibA LibB
  )

You probably want this instead:

set_target_properties(LibD
  PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES "LibA;LibB"
)

Note that if the property value is a list, you have to provide it as a single 
string (i.e. "LibA;LibB" rather than LibA LibB)



--
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding compile and build type tests to CMake/CTest

[CHEVRIER, Marc]

Yes, exactly.
I think so…

On 07/09/2017, 16:04, "CMake on behalf of Edward Diener" 
<cmake-boun...@cmake.org on behalf of eldlistmaili...@tropicsoft.com> wrote:

On 9/7/2017 3:32 AM, CHEVRIER, Marc wrote:
> Rather than building a STATIC library, you can build an OBJECT library. 
In this case only compilation step is done.

So your are saying that:

add_library(foo_compile_test OBJECT EXCLUDE_FROM_ALL foo_compile_test.cpp)
add_test(NAME foo_compile_test
  COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test 
--config $
  WORKING_DIRECTORY ${CMAKE_BINARY_DIR})

should work properly ?

> 
> On 07/09/2017, 08:59, "CMake on behalf of Edward Diener" 
<cmake-boun...@cmake.org on behalf of 
eldlistmailingz-5p0dqD/c5lgwd6l5hs3...@public.gmane.org> wrote:
> 
>  On 9/6/2017 11:39 PM, P F via CMake wrote:
>  > The `add_test` function can run whatever command you want it to, 
including compiling a target:
>  >
>  > add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL 
foo_compile_test.cpp)
>  > add_test(NAME foo_compile_test
>  >  COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test 
--config $
>  >  WORKING_DIRECTORY ${CMAKE_BINARY_DIR})
>  >
>  > Then you set cmake to expect failure:
>  >
>  > set_tests_properties(foo_compile_test PROPERTIES WILL_FAIL TRUE)
>  >
>  > You can also check for output instead of just expecting failure:
>  >
>  > set_tests_properties(mytest PROPERTIES
>  >PASS_REGULAR_EXPRESSION "foo failed"
>  > )
>  >
>  > This is especially useful to make sure that the error is from the 
static_assert message and not from another compile error.
>  >
>  > Of course, cmake could provide a module which provides a function 
to do this, which additionally could help workaround the caveats of this 
approach. This is essentially what `bcm_test` in the boost cmake modules do. > 
> Hopefully, in the future this module could be merged upstream into cmake.
>  
>  It seems like a hack to have to build a CMake target, with the
>  add_library call, just to compile a source file as a test. You end up
>  creating libraries, even if they are static libraries, just to test a
>  compile. I understand that it might be seen that creating static
>  libraries is no different than creating object files, but this 
technique
>  appears to me a limitation of CMake. I should be able to add a test
>  which just attempts to compile source file(s) into object file(s), 
not
>  create static libraries.
>  
>  >
>  >
>  >> On Sep 5, 2017, at 11:44 AM, Edward Diener 
<eldlistmaili...@tropicsoft.com> wrote:
>  >>
>  >> On 9/5/2017 2:47 AM, Dvir Yitzchaki wrote:
>  >>> There's already CheckCXXSourceCompiles and friends.
>  >>> The only problem is that try_compile is not scriptable otherwise 
you could let the test invoke
>  >>> ${CMAKE_COMMAND} -P check_source_compiles.cmake.
>  >>
>  >> To put it succinctly CMake should adding compile-time testing so 
that when some compilation succeeds the test is successful and if the 
compilation fails the test is not successful, with the proviso that you can 
reverse the result as a compile should fail type of test. Similarly a build 
type testing, without having to run anything should be added along the same 
lines.
>  >>
>  >> In modern C++ it is perfectly feasible, especially with template 
programming, to do compile time testing, invoking a compile-time static assert 
as a compile-time failure. Boost has had this for years and modern C++ has it 
as part of the latest version of the C++ standard. CMake needs to update itself 
to the reality that pure compile-time testing is a reality for modern C++ and 
should update itself accordingly. Only having run-time testing is an artifact 
of the past. Hopefully CMake developers will get the message and make the 
necessary update to CMake/CTest.
>  >>
>  >>> -Original Message-
>  >>> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Roger 
Leigh
>  >>> Sent: Monday, September 4, 2017 16:51
>  >>> To: cmake@cmake.org
>  >>> Subject: Re: [CMake] Adding compile and build type tests to 
CMake/CTest
>  >>> On 04/09/17 14:40, Edward Diener wrote:

Re: [CMake] Adding compile and build type tests to CMake/CTest

[CHEVRIER, Marc]

Rather than building a STATIC library, you can build an OBJECT library. In this 
case only compilation step is done.

On 07/09/2017, 08:59, "CMake on behalf of Edward Diener" 
 wrote:

On 9/6/2017 11:39 PM, P F via CMake wrote:
> The `add_test` function can run whatever command you want it to, 
including compiling a target:
> 
> add_library(foo_compile_test STATIC EXCLUDE_FROM_ALL foo_compile_test.cpp)
> add_test(NAME foo_compile_test
>  COMMAND ${CMAKE_COMMAND} --build . --target foo_compile_test 
--config $
>  WORKING_DIRECTORY ${CMAKE_BINARY_DIR})
> 
> Then you set cmake to expect failure:
> 
> set_tests_properties(foo_compile_test PROPERTIES WILL_FAIL TRUE)
> 
> You can also check for output instead of just expecting failure:
> 
> set_tests_properties(mytest PROPERTIES
>PASS_REGULAR_EXPRESSION "foo failed"
> )
> 
> This is especially useful to make sure that the error is from the 
static_assert message and not from another compile error.
> 
> Of course, cmake could provide a module which provides a function to do 
this, which additionally could help workaround the caveats of this approach. 
This is essentially what `bcm_test` in the boost cmake modules do. > > 
Hopefully, in the future this module could be merged upstream into cmake.

It seems like a hack to have to build a CMake target, with the 
add_library call, just to compile a source file as a test. You end up 
creating libraries, even if they are static libraries, just to test a 
compile. I understand that it might be seen that creating static 
libraries is no different than creating object files, but this technique 
appears to me a limitation of CMake. I should be able to add a test 
which just attempts to compile source file(s) into object file(s), not 
create static libraries.

> 
> 
>> On Sep 5, 2017, at 11:44 AM, Edward Diener 
 wrote:
>>
>> On 9/5/2017 2:47 AM, Dvir Yitzchaki wrote:
>>> There's already CheckCXXSourceCompiles and friends.
>>> The only problem is that try_compile is not scriptable otherwise you 
could let the test invoke
>>> ${CMAKE_COMMAND} -P check_source_compiles.cmake.
>>
>> To put it succinctly CMake should adding compile-time testing so that 
when some compilation succeeds the test is successful and if the compilation 
fails the test is not successful, with the proviso that you can reverse the 
result as a compile should fail type of test. Similarly a build type testing, 
without having to run anything should be added along the same lines.
>>
>> In modern C++ it is perfectly feasible, especially with template 
programming, to do compile time testing, invoking a compile-time static assert 
as a compile-time failure. Boost has had this for years and modern C++ has it 
as part of the latest version of the C++ standard. CMake needs to update itself 
to the reality that pure compile-time testing is a reality for modern C++ and 
should update itself accordingly. Only having run-time testing is an artifact 
of the past. Hopefully CMake developers will get the message and make the 
necessary update to CMake/CTest.
>>
>>> -Original Message-
>>> From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Roger Leigh
>>> Sent: Monday, September 4, 2017 16:51
>>> To: cmake@cmake.org
>>> Subject: Re: [CMake] Adding compile and build type tests to CMake/CTest
>>> On 04/09/17 14:40, Edward Diener wrote:
 Boost Build has tests for running an application successfully or not,
 for compiling one or more source files successfully or not, and for
 building one or more source files into an exe or not. These tests in
 Boost Build are the run/run-fail, compile/compile-fail, and
 link/link-fail rules.

 CMake/CTest has the exact equivalent to the run/run-fail rule in its
 add_test framework, but there is not add_test equivalent to the other
 two sets of rules. It sure would be nice, when Boost transitions to
 using CMake/CTest instead of Boost Build, if CMake/CTest had the
 equivalent of the other two sets of types of test in its add_test
 framework.

 Is there any consensus that these other two types of tests might be
 valuable for CMake/CTest, or any way to make this happen ?
>>> I've certainly wished for them.  Particularly when testing templated 
code where you want to test that certain things fail correctly, e.g. via 
static_assert or simply being invalid.
>>> I understand it's possible to make this work partially, by creating 
targets which aren't built by default, and then add tests which invoke the 
targets.  But this appears to have some caveats, such as potential misbehaviour 
with parallel 

Re: [CMake] setting environment variable for ctest

[CHEVRIER, Marc]

Use the ENVIRONMENT property of your tests (see 
https://cmake.org/cmake/help/v3.7/prop_test/ENVIRONMENT.html).

On 05/05/2017, 16:29, "CMake on behalf of Juan E. Sanchez" 
 wrote:

Hello,

It appears that when I invoke ctest through cmake, the environment 
variables I export from my bash shell are being ignored:
DYLD_INSERT_LIBRARIES
PATH

Is there a way to tell cmake to pass the user environment all the way 
down to the environment for my tested application.

This is on Mac OS X (El Capitan) with the latest cmake binary download 
3.8.1.

Regards,

Juan

-- 

Powered by www.kitware.com

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

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

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

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

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


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Feature request: file globbing in ADDITIONAL_MAKE_CLEAN_FILES

[CHEVRIER, Marc]

A more generic approach for cleanup actions is to add a new property which 
enables to specify a cmake script. And, in the script, everyone is free to do 
what he wants…
Example: set_directory_properties (PROPERTIES ADDITIONAL_MAKE_CLEAN_SCRIPT 
"my_clean_script.cmake")

From: cmake-developers  on behalf of Steve 
Lorimer 
Date: Friday 2 September 2016 at 01:32
To: "cmake-developers@cmake.org" 
Subject: [cmake-developers] Feature request: file globbing in 
ADDITIONAL_MAKE_CLEAN_FILES

As part of our build process we tag certain binary files with version 
information such as git branch, number of commits, build variant etc.

Eg, for a binary called "app" we could install a file in the local source 
directory with the name "app.branch_foo.91.debug"

The shell globbing pattern that matches is "app.*[0-9]*"

I need a globbing pattern because the tag can change without the makefiles 
changing, so the tag can't be hardcoded into the makefile.

If I specify a globbing pattern for ADDITIONAL_MAKE_CLEAN_FILES it specifies 
this as an actual file

set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES app.*[0-9]*)

This results in

file(REMOVE_RECURSE
"../../../app/app.*[0-9]*"
...
)

That doesn't work, because it's not a real file, it's a globbing pattern

I've tried adding a nested file(GLOB ...) into the set_directory_properties but 
that doesn't work either.

Is this a feature worthy of addition?

- the ability to specify a globbing pattern in 
set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES ...)?
- the ability to specify a globbing pattern in file(REMOVE_RECURSE ...)?

TIA
Steve
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] add_compile_options query

[CHEVRIER, Marc]

Specify flags as strings rather than lists (i.e. add quotes):
add_compile_options("--param l1-cache-size=24")
add_compile_options("--param l1-cache-line-size=64")
add_compile_options("--param l2-cache-size=512")



On 12/08/16 11:08, "CMake on behalf of Alex Biddulph"  wrote:

Hi,

I am trying to add some GCC compiler optimisation flags using the 
add_compile_options directive but am running into some issues due to the nature 
of the flags.

There are 3 flags that I am trying to set:
--param l1-cache-size=24
--param l1-cache-line-size=64
--param l2-cache-size=512

If I try to add these as:
add_compile_options(--param l1-cache-size=24)
add_compile_options(--param l1-cache-line-size=64)
add_compile_options(--param l2-cache-size=512)

Then the resulting portion of the command line is: 
--param l1-cache-size=24 l1-cache-line-size=64 l2-cache-size=512

That is, only one of the '--param's is maintained, but all 3 need to be 
maintained in order for GCC to understand the flags.

Is it possible to use add_compile_options to set these flags? Or is there 
another more effective method? I would like to avoid adding them to CFLAGS and 
CXXFLAGS if at all possible.

Thanks in advance,
Alex
-- 

Powered by www.kitware.com

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

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

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

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

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


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Use GLOB to generate filelist for install package

[CHEVRIER, Marc]

Remove the quotes around the variable MY_INCLUDES_H in the INSTALL command 
because this is a list. Using quotes, you pass it as a single string.

On 11/08/16 11:03, "CMake on behalf of Patrik Lehmann"  wrote:

Hello,

I try to use GLOB to collect the files for my install package, but 
unfortunately I got the message

'file INSTALL cannot find 
"C:/Project/include/test1.h;C:/Project/include/test2.h;...'

My code:

FILE(GLOB MY_INCLUDES_H "${PROJECT_SOURCE_DIR}/include/*.h")

INSTALL(FILES "${MY_INCLUDES_H}"
  DESTINATION "include"
  COMPONENT CPP_INCLUDES)


Is there a way to collect the files this way or is it needed to add 
every file manually?

Kind Regards,
Patrik Lehmann
-- 

Powered by www.kitware.com

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

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

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

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

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


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] project command not working, when used via macro (from an included file)

[CHEVRIER, Marc]

May be using keyword NO_POLICY_SCOPE in include command will solve your problem…

From: CMake > on behalf 
of Chuck Atkins >
Date: Tuesday 26 April 2016 at 20:04
To: aj neu >
Cc: "cmake@cmake.org" 
>
Subject: Re: [CMake] project command not working, when used via macro (from an 
included file)

ajneu,

The call to project(...) needs to be explicit.  See 
https://cmake.org/cmake/help/v3.5/command/project.html:

The top-level CMakeLists.txt file for a project must contain a literal, direct 
call to the 
project()
 command; loading one through the 
include()
 command is not sufficient.

- Chuck

On Tue, Apr 26, 2016 at 1:57 PM, aj neu 
> wrote:
Hi,

when calling `project`
...as seen here
... 
https://github.com/ajneu/cmake_project_via_macro/blob/5972c7362e11fdbaa09d9defe8cca2dcea79e606/CMakeLists.txt#L33
everything is ok.


BUT when calling `project` via a macro (that was included)
... as seen here
... 
https://github.com/ajneu/cmake_project_via_macro/blob/master/CMakeLists.txt#L33
the behaviour is not as expected.

Why?

(Details are here: https://github.com/ajneu/cmake_project_via_macro)


Is this a bug?

Thanks
ajneu


--

Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] File names with unbalanced square brackets

[CHEVRIER, Marc]

I think you can resolve your problem with the following syntax for foreach 
command:
Foreach (FILE IN LISTS FILES)

In this case the list is not expanded in your source so square brackets is no 
longer interpreted…


From: CMake > on behalf 
of Petr Kmoch >
Date: Friday 18 March 2016 at 08:17
To: Allen Barnett >
Cc: "cmake@cmake.org" 
>
Subject: Re: [CMake] File names with unbalanced square brackets

Hi Allen.

I'm not sure whether it's documented, but CMake interprets square brackets as 
escaping the semi-colon character (which means a semi-colon in square brackets 
will not work as a list item separator). You will probably have to translate 
the file names for CMake processing by replacing [ and ] with a different 
string, and replacing it back just before use outside of CMake.

Petr

On Thu, Mar 17, 2016 at 5:38 PM, Allen Barnett 
> wrote:
I inherited a set of files with somewhat unusual file names. In particular, 
there were a couple of files whose names included a single square bracket 
character. I processed these files with the file( GLOB ...) command and then 
iterated over the resulting list with foreach. However, the foreach command 
does not seem to break the resulting list apart correctly. To make this 
concrete, I have a directory with files named "a", "b[", and "c". file( GLOB 
FILES "*" ) returns the list:

/home/allen/test/b[;/home/allen/test/c;/home/allen/test/a

However,

foreach( FILE ${FILES} )
  message( ${FILE} )
endforeach()

just prints the same thing. That is, foreach does not split FILES into separate 
pieces. If I rename "b[" to "b]" I see the same behavior. If I rename "b[" to 
"b[]" (or even "b]["), then foreach successfully splits FILES into the 
individual file names.

I'm using CMake 3.3.2. I see the same thing on linux and windows.

Thanks,
Allen

--

Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CTest Usage

[CHEVRIER, Marc]

Hi,

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

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

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

Is there a way to get a AND on the labels specified?
If not, I think it will be very valuable to introduce this enhancement to be 
able to manage labels when a lot are created. In my example the direct solution 
is to create LABEL3 for tests2 but it become rapidly impossible to manage a 
specific label per subset tests when number of labels increase.

Marc

-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] CTest usage

[CHEVRIER, Marc]

Hi,

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

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

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

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

Marc

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Build from Source on Solaris

[CHEVRIER, Marc]

Not only: see 
http://public.kitware.com/pipermail/cmake-developers/2015-September/026565.html 
for bootstrap.

From: Matthew Gidden <matthew.gid...@gmail.com<mailto:matthew.gid...@gmail.com>>
Date: Wednesday 2 March 2016 at 10:17
To: Marc CHEVRIER <marc.chevr...@sap.com<mailto:marc.chevr...@sap.com>>
Cc: "cmake@cmake.org<mailto:cmake@cmake.org>" 
<cmake@cmake.org<mailto:cmake@cmake.org>>
Subject: Re: [CMake] Build from Source on Solaris

Hi Marc,

Thanks for the swift reply. To the best that I can tell, that thread is dealing 
with trying to build a project using cmake. I'm trying to build cmake (i.e., 
./bootstrap && make && make install). To note, I get something like the 
following errors (which are available in the gist).

```
"/usr/include/iso/math_c99.h", line 697: Error: The function 
"__builtin_signbitl" must have a prototype.
"/opt/solarisstudio12.4/lib/compilers/CC-gcc/include/c++/4.8.2/cmath", line 
562: Error: std::fpclassify(float) already had a body defined.
```

Cheers,
Matt


On Wed, Mar 2, 2016 at 9:54 AM, CHEVRIER, Marc 
<marc.chevr...@sap.com<mailto:marc.chevr...@sap.com>> wrote:
Hi,

Some help can be found in this thread: 
http://public.kitware.com/pipermail/cmake-developers/2015-September/026550.html

Marc

From: CMake <cmake-boun...@cmake.org<mailto:cmake-boun...@cmake.org>> on behalf 
of Matthew Gidden <matthew.gid...@gmail.com<mailto:matthew.gid...@gmail.com>>
Date: Wednesday 2 March 2016 at 09:44
To: "cmake@cmake.org<mailto:cmake@cmake.org>" 
<cmake@cmake.org<mailto:cmake@cmake.org>>
Subject: [CMake] Build from Source on Solaris

Hi all,

I just tried to install from source on Solars 10 (sparc), on which make failed. 
I have a gist here: https://gist.github.com/gidden/7b9dc2d793ef3411debf

My system info is:

```
t501:gidden> uname -a
SunOS t501 5.11 11.3 sun4v sparc sun4v
```

Any suggestions? I wasn't able to find sparc binaries... did I not look hard 
enough?

Thanks!

Matt Gidden

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Build from Source on Solaris

[CHEVRIER, Marc]

Hi,

Some help can be found in this thread: 
http://public.kitware.com/pipermail/cmake-developers/2015-September/026550.html

Marc

From: CMake > on behalf 
of Matthew Gidden >
Date: Wednesday 2 March 2016 at 09:44
To: "cmake@cmake.org" 
>
Subject: [CMake] Build from Source on Solaris

Hi all,

I just tried to install from source on Solars 10 (sparc), on which make failed. 
I have a gist here: https://gist.github.com/gidden/7b9dc2d793ef3411debf

My system info is:

```
t501:gidden> uname -a
SunOS t501 5.11 11.3 sun4v sparc sun4v
```

Any suggestions? I wasn't able to find sparc binaries... did I not look hard 
enough?

Thanks!

Matt Gidden
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Support of Scala language

[CHEVRIER, Marc]

I agree. The right approach is to do an integration of Java in the same way as 
C or C++.
But I don’t have currently enough CMake skills to do this work.

Do you have some documentation explaining how language support is done in CMake 
? And how specific behaviours of Java/Scala can be supported in CMake:
* All sources composing a jar must be compiled all at once
* A source file can produce an arbitrary number of binary files (.class) with 
various (and unpredictable) names.

Marc




On 18/02/16 16:06, "Brad King" <brad.k...@kitware.com> wrote:

>On 02/18/2016 06:28 AM, CHEVRIER, Marc wrote:
>> Currently, there is a module UseJava.cmake which mix two aspects:
>
>This module is not a good example of how to do a language in CMake.
>It somehow became the way to do Java in CMake because the builtin
>support for enable_language(Java) was never really made to work right.
>(It tries to do separate compilation which is not really generally
>possible in Java due to circular dependencies of nested classes.)
>
>If we're starting with support for a new language then we should
>add it properly as a first-class language.  Eric and Michael (in Cc)
>have been working on this for Swift and C# recently.  Likely there
>is some overlap in design space.
>
>-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Support of Scala language

[CHEVRIER, Marc]

Hi,

I have just started to work to extend CMake to support Scala language.
This language is very similar to Java regarding compilation (scala compiler 
generates .class (java byte code)) and packaging  (binary files can be packaged 
in jar files) and is running as part of JVM infrastructure.

Currently, there is a module UseJava.cmake which mix two aspects:

  *   Jar management: add_jar, install_jar and find_jar
  *   Java specific stuff: doc, etc…

Now, regarding jar management, currently only Java language is supported but, 
with only very few changes, Scala can be supported as well. So it would be very 
nice to avoid to duplicate jar management for Scala support.

So, I submit the following proposal, regarding current Java and Scala support, 
to the discussion:

  *   Split current module UseJava.cmake into 2 modules:
 *   UseJar.cmake which will be in charge of jar management, including 
sources compilation (Java and Scala)
 *   UseJava.cmake, keep Java specific stuff and also include, for 
compatibility, module UseJar.cmake
  *   For Scala support, provide modules:
 *   FindScala.cmake (same functionality as FindJava.cmake)
 *   UseScala.cmake which can include UseJar.cmake and provides specific 
stuff (like create_scaladoc)

Comments are welcome…

Marc


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] string regexp replace removes the semicolons

[CHEVRIER, Marc]

Hi,

Command file(GLOB) returns a CMake list (in a CMake list, items are separated 
by ;)

Now you pass to command string the content of the list, so the list is 
expanded: in your example,
string(REGEX REPLACE "foo.*cc" " " COMPILE_ONLY ${ALL_SOURCES})

Is equivalent to:
string(REGEX REPLACE "foo.*cc" " " COMPILE_ONLY a.cc b.cc foo_u.cc foo_v.cc 
c.cc y.cc)

So, command string will concatenate all the input strings in a single string.

To keep semi colons, you have to pass ALL_SOURCES as a string, not a list:
string(REGEX REPLACE "foo.*cc" " " COMPILE_ONLY “${ALL_SOURCES}")






On 22/01/16 12:29, "CMake on behalf of Vania Joloboff"  wrote:

>Hi
>
>I want to remove from a list of sources those that start with 'foo'
>So I have
>
>file(GLOB ALL_SOURCES "*.cc")
># this gives ALL_SOURCES = "a.cc;b.cc;foo_u.cc;foo_v.cc;c.cc;y.cc"
># separated by semicolons
>
>string(REGEX REPLACE "foo.*cc" " " COMPILE_ONLY ${ALL_SOURCES})
>
>But in the COMPILE_ONLY variable the semicolons are removed !
>and then
>add_library(lib ${COMPILE_ONLY}) fails
>
>why is it removing the semicolons ?
>Vania
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding definitions to compile one file ?

[CHEVRIER, Marc]

Use APPEND keyword:
set_property(
   SOURCE source.cpp
APPEND PROPERTY COMPILE_DEFINITIONS
 VAR1=${MY_VAR1} VAR2=${MY_VAR2}
)






On 21/01/16 15:26, "CMake on behalf of Vania Joloboff"  wrote:

>HI Petr
>
>Thanks for the suggestion.
>But this will erase the existing compile definitions, won't it ?
>So may be I should do a get_property first,
>append my new definitions and reset the property ?
>I'll try anyway...
>
>Vania
>
>On 01/21/2016 03:21 PM, Petr Kmoch wrote:
>> Hi Vania.
>>
>> For your case, it's best to forget about the 
>> not-as-convenient-as-they-could-be convenience functions 
>> set_*_properties, and just invoke set_property:
>>
>> set_property(
>>   SOURCE source.cpp
>>   PROPERTY COMPILE_DEFINITIONS
>> VAR1=${MY_VAR1} VAR2=${MY_VAR2}
>> )
>>
>> Petr
>>
>> On Thu, Jan 21, 2016 at 3:14 PM, Vania Joloboff 
>> > wrote:
>>
>> Hi
>>
>> I want to add two definitions to compile one specific files
>> in addition to the global definitions.
>> I have the following problem. If I use
>>
>> set_source_files_properties(source.cpp
>> PROPERTIES
>> COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} )
>>
>> then I get error message incorrect number of arguments for
>> set_source_files_properties
>>
>> If I put
>> set_source_files_properties(source.cpp
>> PROPERTIES COMPILE_DEFINITIONS "VAR1=${MY_VAR1} VAR2=${MY_VAR2}" )
>>
>> then it generates strangely enough the compile command
>>
>> /usr/bin/c++ -DVAR1="path1 VAR2=path2" ... source.cpp
>>
>> with the double quotes as above, which gives a weird value to VAR1
>> and no value to VAR2
>>
>> If I use twice set_source_files_properties
>> the first one is overwritten by the second
>> and I only get the definition of VAR2
>>
>> What am I supposed to do ?
>>
>> Thankx
>>
>> PS I am using cmake 3.2.2 on Linux Mint.
>>
>> -- 
>>
>> Powered by www.kitware.com 
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community.
>> For more information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>>
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMAKE][PATCH] fix create_javah on Windows

[CHEVRIER, Marc]

Hi,

Attached is a patch fixing erroneous handling of CLASSPATH parameter for 
function create_javah (module UseJava).
Update tests accordingly.

Marc



0001-Fix-create_javah-CLASSPATH-handling-on-Windows.patch
Description: 0001-Fix-create_javah-CLASSPATH-handling-on-Windows.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] find_library

[CHEVRIER, Marc]

Defining a variable using -D option does not put this one in the environment 
(i.e. system environment) so using ENV will fails...




On 14/01/16 10:28, "CMake on behalf of Vania Joloboff"  wrote:

>I am running cmake 3.2.2 on Linux 64 bits
>
>I run cmake with
>
>  cmake -G "Unix Makefiles" -DSYSTEMC_PATH=$HOME/systemc-2.3.1/
>
>In my CMakeLists.txt,
>
>If I put
>
>  find_library(SYSC_LIB systemc PATHS "${SYSTEMC_PATH}"
>   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>
>it works.
>
>If I put
>  find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
>   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>
>which I think should be identical, I get error
>CMake Error at CMakeLists.txt:28 (message):
>   ERROR: SYSC_LIB-NOTFOUND
>
>Can anyone explain the difference and why the second does not work ?
>
>btw
>
>find_library(SYSC_LIB NAMES systemc foobar PATHS "${SYSTEMC_PATH}"
>PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64)
>
>  also works
>and
> find_library(SYSC_LIB systemc PATHS ENV SYSTEMC_PATH
>   PATH_SUFFIXES lib-linux64 lib64-linux lib64-linux64
>   NO_DEFAULT_PATH)
>also fails
>
>At least it is consistent :-(
>
>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:
>http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] test endian ness

[CHEVRIER, Marc]

Hi,

May be to include the module before using it:

include (TestBigEndian)




On 13/01/16 15:25, "CMake on behalf of Vania Joloboff"  wrote:

>Hi
>
>I am familiar with autoconf and trying to migrate our project to cmake.
>Thus newbie. I am running cmake 3.2.2 on Linux Mint 17
>
>I have seen in the documentation the macro
>https://cmake.org/cmake/help/v3.2/module/TestBigEndian.html?highlight=endian#module:TestBigEndian
>
>which seems very convenient for our purpose.
>I have added to my CMakeLists.txt
>
>TEST_BIG_ENDIAN(HOST_IS_BIG_ENDIAN)
>
>But when I run
> > cmake -G "Unix Makefiles"
>
>I get
>
>CMake Error at CMakeLists.txt:11 (TEST_BIG_ENDIAN):
>   Unknown CMake command "TEST_BIG_ENDIAN".
>
>What am I missing ?
>
>Thanks for clues...
>
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] ExternalProject_Add and inheritance

[CHEVRIER, Marc]

The problem is not a CMake one but a runtime environment one.
You built an executable with a specific environment (GCC 5) but try to execute 
it in a different environment (default platform): When an executable is built, 
system libraries paths are not stored as part of the executable so without 
specific env, wrong library is used. You can solve this problem using, as you 
already found, LD_LIBRARY_PATH or, may be (not tried), using various CMake 
related RPATH variables and properties to force storage of system library path.


From: Cedric Doucet >
Date: Friday 11 December 2015 at 10:05
To: SAP SAP >
Cc: "cmake@cmake.org" 
>
Subject: Re: [CMake] ExternalProject_Add and inheritance


Hello Marc,

thank you very much for your answer!

I am not sure to understand how to overcome my problem with these variables.
I can explain my problem further.

I have a toy example of the problem which contains:
- a call to ExternalProject_Add to install boost and yaml-ccp (the latter 
depends on the former)
- a main function which loads a file with yaml-cpp (just one line of code)

Everything compiles with GCC 5 and I obtain an executable file (called 
gcc_example).
However, when I run this executable file, I get the following error message :

./gcc_example: relocation error: ./gcc_example: symbol 
_ZTVNSt7__cxx1118basic_stringstreamIcSt11char_traitsIcESaIcEEE, version 
GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference

And I can overcome this problem by setting LD_LIBRARY_PATH to the right value:

LD_LIBRARY_PATH=/home/libraries/gcc/5.2.0/lib64/ ./gcc_example

The origin of the problem is that the definition of strings is different since 
GCC 5.
Unfortunately, the default behavior is to call the C++ standard library of my 
Ubuntu system, and the version of this library is older than the version of GCC 
5.

I can check it with 'ldd ./gcc_example':

linux-vdso.so.1 =>  (0x7ffd02ef7000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x003a7140)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x003d03a0)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x003a7100)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x003d02e0)
/lib64/ld-linux-x86-64.so.2 (0x003d02a0)

But I don't understand why I have still this problem since I put these lines in 
my CMakeLists file (of course the right value of GCC_ROOT is passed to the 
cmake command at configuration step):

link_directories(${GCC_ROOT}/lib64)
target_link_libraries(gcc_example ${GCC_ROOT}/lib64/libstdc++.so)

I can provide my simple toy example if it helps to understand.
You just need to compile it with GCC 5 to see the problem (with older versions 
of GCC, everything works fine because strings are defined in the "classical" 
way).


Best,


Cédric






De: "Marc CHEVRIER" >
À: "Cedric Doucet" >, 
cmake@cmake.org
Envoyé: Vendredi 11 Décembre 2015 08:44:38
Objet: Re: [CMake] ExternalProject_Add and inheritance

With CMake, you can control compilation and link flags with the following 
environment variables:

  *   CC: specify C compiler
  *   CFLAGS: C compiler flags
  *   CXX: specify C++ compiler
  *   CXXFLAGS: C++ compiler flags
  *   LDFLAGS: linker flags

And to finish you can overload make command for generation using CMAKE_COMMAND 
option of ExternalProject_Add:
CMAKE_CMMAND “${CMAKE_COMMAND}” -E env CXX=${CMAKE_CXX_COMPILER} LDFLAGS=“…” 
“${CMAKE_COMMAND}”




From: CMake > on behalf 
of Cedric Doucet >
Date: Thursday 10 December 2015 at 18:21
To: "cmake@cmake.org" 
>
Subject: [CMake] ExternalProject_Add and inheritance


Hello,

I use the ExternalProject_Add command to manage third-party libraries.
In the same time, I need to overcome some compatibility problems between GCC 4 
and GCC 5 (strings are not defined in the same way in the STL).
The solution I use is the one given here:
http://stackoverflow.com/questions/33500337/how-to-handle-dual-abi-in-gcc-5
It allows me to force to use the libstdc++.so given by the GCC repository given 
to the cmake command.

The problem is that trick does not work with the ExternalProject_Add command 
because configuration steps of third-party libraries are autonomous.
Do you know how to solve the problem?

For example, if I use the ExternalProject_Add command to manage a third-library 
whose configuration also depends on a cmake script, how could I tell this 
script to use the compilers and the libstdc++.so I provided to my own cmake 

[cmake-developers] [CMake][PATCH] Fix support of policy 0065 on AIX

[CHEVRIER, Marc]

Hi,

Attached is a patch to handle correctly policy 0065 and avoid lost of some 
required link flags (I.e. -bnoipath)

Marc



0001-Fix-support-of-policy-0065-on-AIX.patch
Description: 0001-Fix-support-of-policy-0065-on-AIX.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

[CHEVRIER, Marc]

Hi,

I identify the root of the problem: if I specify version 3.4 in 
cmake_minimum_required, generated link command (stored in file link.txt) for an 
executable does not contains value specified in variable 
CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem. So 
this is a regression introduced in 3.4.

Problem can be reproduced using this very simple CMakeLists.txt:
cmake_minimum_required (VERSION 3.4)

project (TEST LANGUAGES CXX)

file (WRITE test.cpp "// empty\n")

add_executable (test_exe test.cpp)

This problem occurs on all platforms (tested on AIX and Linux).

Marc




On 09/12/15 15:41, "cmake-developers on behalf of CHEVRIER, Marc" 
<cmake-developers-boun...@cmake.org on behalf of marc.chevr...@sap.com> wrote:

>
>Oops !
>You are right, on a simple example, all is OK. So the problem seems on my side.
>I will investigate this curious behaviour…
>
>Sorry for the noise.
>
>Marc
>
>
>
>
>On 09/12/15 15:15, "Brad King" <brad.k...@kitware.com> wrote:
>
>>On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote:
>>> You are right. I missed this capability.
>>> My first idea was to apply to exec the same approach as for shared lib but 
>>> I didn’t found appropriate variable: something like 
>>> CMAKE_EXE_CREATE__FLAGS
>>> Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the 
>>> usage of the *_INIT variables.
>>
>>Actually the old code has it in two places:
>>
>>> - set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS "-G -Wl,-bnoipath") # 
>>> -shared
>>> - set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS 
>>> "-Wl,-brtl,-bnoipath,-bexpall") # +s, flag for exe link to use shared lib
>>
>>The CREATE_ value is used when linking a shared library itself.
>>The LINK_ value is used to link executables.  Both should already
>>be getting the flag with no changes.
>>
>>-Brad
>>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

[CHEVRIER, Marc]

Ok. I see the problem. Thanks for your investigation.
I will work on that and submit a patch to solve this problem.

Marc





On 10/12/15 14:42, "Brad King" <brad.k...@kitware.com> wrote:

>On 12/10/2015 04:03 AM, CHEVRIER, Marc wrote:
>> I identify the root of the problem: if I specify version 3.4 in
>> cmake_minimum_required, generated link command (stored in file link.txt)
>> for an executable does not contains value specified in variable
>> CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS. Specifying 3.3 fix the problem.
>> So this is a regression introduced in 3.4.
>
>It is not technically a backward incompatibility because project code
>that worked in 3.3 will still work the same way in 3.4.  Only after
>modifying the code to require 3.4 does the behavior change, but the
>new behavior is a regression.  This is policy CMP0065:
>
> https://cmake.org/cmake/help/v3.4/policy/CMP0065.html
>
>introduced here:
>
> CMP0065: Restrict the use of CMAKE_SHARED_LIBRARY_LINK__FLAGS
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9784af1b
>
>The bug is that CMAKE_SHARED_LIBRARY_LINK__FLAGS is intended
>to be equivalent to "-rdynamic" on Linux, but the AIX platform file
>is using it for other flags too:
>
>> set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-brtl,-bnoipath,-bexpall")
>
>This should be just
>
> set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS "-Wl,-bexpall")
>
>and the `-Wl,-brtl,-bnoipath` flags should move elsewhere.  One could
>add them directly to the CMAKE_${lang}_LINK_EXECUTABLE command line,
>for example.
>
>Thanks,
>-Brad
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] ExternalProject_Add and inheritance

[CHEVRIER, Marc]

With CMake, you can control compilation and link flags with the following 
environment variables:

  *   CC: specify C compiler
  *   CFLAGS: C compiler flags
  *   CXX: specify C++ compiler
  *   CXXFLAGS: C++ compiler flags
  *   LDFLAGS: linker flags

And to finish you can overload make command for generation using CMAKE_COMMAND 
option of ExternalProject_Add:
CMAKE_CMMAND “${CMAKE_COMMAND}” -E env CXX=${CMAKE_CXX_COMPILER} LDFLAGS=“…” 
“${CMAKE_COMMAND}”



From: CMake > on behalf 
of Cedric Doucet >
Date: Thursday 10 December 2015 at 18:21
To: "cmake@cmake.org" 
>
Subject: [CMake] ExternalProject_Add and inheritance


Hello,

I use the ExternalProject_Add command to manage third-party libraries.
In the same time, I need to overcome some compatibility problems between GCC 4 
and GCC 5 (strings are not defined in the same way in the STL).
The solution I use is the one given here:
http://stackoverflow.com/questions/33500337/how-to-handle-dual-abi-in-gcc-5
It allows me to force to use the libstdc++.so given by the GCC repository given 
to the cmake command.

The problem is that trick does not work with the ExternalProject_Add command 
because configuration steps of third-party libraries are autonomous.
Do you know how to solve the problem?

For example, if I use the ExternalProject_Add command to manage a third-library 
whose configuration also depends on a cmake script, how could I tell this 
script to use the compilers and the libstdc++.so I provided to my own cmake 
script?

Best,

Cédric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

[CHEVRIER, Marc]

Oops !
You are right, on a simple example, all is OK. So the problem seems on my side.
I will investigate this curious behaviour…

Sorry for the noise.

Marc




On 09/12/15 15:15, "Brad King" <brad.k...@kitware.com> wrote:

>On 12/09/2015 09:09 AM, CHEVRIER, Marc wrote:
>> You are right. I missed this capability.
>> My first idea was to apply to exec the same approach as for shared lib but I 
>> didn’t found appropriate variable: something like 
>> CMAKE_EXE_CREATE__FLAGS
>> Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the 
>> usage of the *_INIT variables.
>
>Actually the old code has it in two places:
>
>> - set(CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS "-G -Wl,-bnoipath") # -shared
>> - set(CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS 
>> "-Wl,-brtl,-bnoipath,-bexpall") # +s, flag for exe link to use shared lib
>
>The CREATE_ value is used when linking a shared library itself.
>The LINK_ value is used to link executables.  Both should already
>be getting the flag with no changes.
>
>-Brad
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake][PATCH] AIX RPATH handling

[CHEVRIER, Marc]

You are right. I missed this capability.
My first idea was to apply to exec the same approach as for shared lib but I 
didn’t found appropriate variable: something like CMAKE_EXE_CREATE__FLAGS
Or may be CMAKE_EXE_LINKER_FLAGS_INIT can be used but I am not sure of the 
usage of the *_INIT variables.

Marc




On 09/12/15 15:00, "Brad King" <brad.k...@kitware.com> wrote:

>On 12/09/2015 08:02 AM, CHEVRIER, Marc wrote:
>> Attached is a patch for AIX enabling correct generation of executables
>> regarding runtime path handling (currently, build paths could be stored
>> as part of installed executables): option -bnoipath is required for
>> executables link command (currently, only shared libs link command
>> get -bnoipath option).
>
>Thanks.  I agree that -bnoipath should be used for all linking because
>we never want the path to a library file to be encoded in its dependents.
>However, the proposed patch moves the flag over to the flags used to
>specify the RPATH.  These may not be used if CMAKE_SKIP_RPATH or similar
>options are enabled.  We should find another place for the flag that
>is always used for both shared libraries and executables.
>
>Thanks,
>-Brad
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMake and a simple java example

[CHEVRIER, Marc]

Hi,

You didn’t specify nothing in variable JAVA_SOURCE_DIRECTORY, so java source 
path is effectively /HelloWorld.java.

By the way, you can specify relative paths to the CMakeLists.txt directory for 
java sources, so:

set(JAVA_SOURCE_FILES HelloWorld.java)
add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES})

Should do the work.


Or alternately:

set(JAVA_SOURCE_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
set(JAVA_SOURCE_FILES ${JAVA_SOURCE_DIRECTORY}/HelloWorld.java)
add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES})

is also OK.






On 07/12/15 22:52, "CMake on behalf of Kristian"  wrote:

>Dear All,
>
>I am learning CMake, and one of my personal lessons is combine Java
>and CMake. I made a small example (HelloWorld.java):
>
>==
>
>public class HelloWorld
>{
>   public static void main(String[] args)
>   {
>  System.out.println("Hey :)");
>   }
>}
>
>==
>
>And a CMakeLists.txt file:
>
>==
>
>cmake_minimum_required(VERSION 2.8)
>project(HelloWorld)
>
>find_package(Java REQUIRED)
>include(UseJava)
>
>set(JAR_NAME HelloWorld)
>set(JAVA_SOURCE_DIRECTORY )
>set(JAVA_SOURCE_FILES ${JAVA_SOURCE_DIRECTORY}/HelloWorld.java)
>add_jar(${JAR_NAME} ${JAVA_SOURCE_FILES})
>
>==
>
>Then I go into that directory where the CMakeLists.txt is and start the command
>
>==
>cmake --target=HelloWorld --build .
>==
>
>Output is:
>
>==
>
>-- The C compiler identification is GNU 4.8.4
>-- The CXX compiler identification is GNU 4.8.4
>-- Check for working C compiler: /usr/bin/cc
>-- Check for working C compiler: /usr/bin/cc -- works
>-- Detecting C compiler ABI info
>-- Detecting C compiler ABI info - done
>-- Check for working CXX compiler: /usr/bin/c++
>-- Check for working CXX compiler: /usr/bin/c++ -- works
>-- Detecting CXX compiler ABI info
>-- Detecting CXX compiler ABI info - done
>-- Found Java: /usr/bin/java (found version "1.8.0.66")
>-- Jar file /home/some/Downloads/HelloWorld/HelloWorld.jar
>-- Class compiled to /home/some/Downloads/HelloWorld/CMakeFiles/HelloWorld.dir
>-- Configuring done
>-- Generating done
>-- Build files have been written to: /home/some/Downloads/HelloWorld
>
>==
>
>But when I start the command "make", then I get the following output:
>
>==
>
>Scanning dependencies of target HelloWorld
>make[2]: *** No rule to make target `/HelloWorld.java', needed by
>`CMakeFiles/HelloWorld.dir/java_compiled_HelloWorld'.  Stop.
>make[1]: *** [CMakeFiles/HelloWorld.dir/all] Error 2
>make: *** [all] Error 2
>
>==
>
>Can you tell me, what I am doing wrong?
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to generate for Ninja + MSVC?

[CHEVRIER, Marc]

Alternate solution is to define following environment variables:
* CC=cl.exe
* CXX=cl.exe

In this case, CMake will search these compilers rather than the standard 
choices (starting with c++ and g++ for C++ language).

And you don’t have any longer constraints about your environment.
 
Marc




On 02/12/15 20:39, "CMake on behalf of Robert Dailey"  wrote:

>On Wed, Dec 2, 2015 at 1:37 PM, Robert Dailey  wrote:
>> On Wed, Dec 2, 2015 at 1:29 PM, Nils Gladitz  wrote:
>>> On 02.12.2015 20:18, Robert Dailey wrote:

 Is there a way to generate for Ninja using MSVC toolchain? If so, how
 do I do that? Do I need a toolchain file?
>>>
>>>
>>> You can select the Ninja generator (e.g. cmake -G Ninja) while running cmake
>>> from the desired Visual Studio command line environment.
>>
>> This doesn't work unfortunately; it still finds GNU 4.8.3 compiler somehow.
>
>For some reason Strawberry Perl installed gcc/g++ to my PATH. I
>removed this and it's finding MSVC 19 now. Thanks.
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to link archives (.a) into shared object (.so) with cmake ?

[CHEVRIER, Marc]

Hi,

Shared libraries required position independent code (PIC) for objects.
By default, in CMake, static libraries objects are not compiled with this mode… 
So your problem.

The easiest solution is to add this line to your CMakeLists.txt file:
Set (CMAKE_POSITION_INDEPENDENT_CODE ON)

Marc




On 17/11/15 11:44, "CMake on behalf of houssen"  wrote:

>Hello,
>
>How to link archives (.a) into shared object (.so) with cmake ?
>
>I have an archive:
>ADD_LIBRARY ( myArchive STATIC ${SRC} )
>That I need to link with a shared object:
>ADD_LIBRARY ( mySharedObject SHARED ${SRC} )
>TARGET_LINK_LIBRARIES ( mySharedObject PUBLIC myArchive )
>I get a compilation error that says "you need to compile with -fPIC !"
>
>As far as I understand, I need to use "-Wl,--whole-archive" : 
>http://stackoverflow.com/questions/7935421/linking-archives-a-into-shared-object-so...
> 
>But I can't figure out how to do that with CMake. Could someone help ?
>
>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:
>http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How to link archives (.a) into shared object (.so) with cmake ?

[CHEVRIER, Marc]

Set of variable CMAKE_POSITION_INDEPENDENT_CODE must be done BEFORE add_library 
(… STATIC…).

Are you sure you re-generate makefiles?

This approach works perfectly for me on Linux with GNU compiler.

Marc



On 17/11/15 13:48, "CMake on behalf of houssen" <cmake-boun...@cmake.org on 
behalf of hous...@ipgp.fr> wrote:

>Unfortunately, that does not work !... But indeed, for me, it should 
>have ?!...
>
>Franck
>
>Le 2015-11-17 12:34, CHEVRIER, Marc a écrit :
>> Hi,
>>
>> Shared libraries required position independent code (PIC) for 
>> objects.
>> By default, in CMake, static libraries objects are not compiled with
>> this mode… So your problem.
>>
>> The easiest solution is to add this line to your CMakeLists.txt file:
>> Set (CMAKE_POSITION_INDEPENDENT_CODE ON)
>>
>> Marc
>>
>>
>>
>>
>> On 17/11/15 11:44, "CMake on behalf of houssen"
>> <cmake-boun...@cmake.org on behalf of hous...@ipgp.fr> wrote:
>>
>>>Hello,
>>>
>>>How to link archives (.a) into shared object (.so) with cmake ?
>>>
>>>I have an archive:
>>>ADD_LIBRARY ( myArchive STATIC ${SRC} )
>>>That I need to link with a shared object:
>>>ADD_LIBRARY ( mySharedObject SHARED ${SRC} )
>>>TARGET_LINK_LIBRARIES ( mySharedObject PUBLIC myArchive )
>>>I get a compilation error that says "you need to compile with -fPIC 
>>> !"
>>>
>>>As far as I understand, I need to use "-Wl,--whole-archive" :
>>>http://stackoverflow.com/questions/7935421/linking-archives-a-into-shared-object-so...
>>>But I can't figure out how to do that with CMake. Could someone help 
>>> ?
>>>
>>>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:
>>>http://public.kitware.com/mailman/listinfo/cmake
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [PATCH][CMAKE] C sources must use C Style comments

[CHEVRIER, Marc]

Hi,

Attached is a small patch ensuring that c source is compiling even if C 
compiler (AIX xlc for example) does not support C++ Style comments.

Marc



0001-Use-C-Style-comments-in-C-sources.patch
Description: 0001-Use-C-Style-comments-in-C-sources.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CXX_STANDARD and linking

[CHEVRIER, Marc]

No problem for me to keep broken behavior of SolarisStudio.
Let me know when C++ Standard support including linking part is implemented, I 
can help you to validate it on Solaris SPARC.

Thanks.

Marc




On 08/10/15 19:24, "cmake-developers on behalf of Brad King" 
 wrote:

>On 10/08/2015 11:38 AM, Brad King wrote:
>> On 10/07/2015 03:22 PM, Stephen Kelly wrote:
>>> The CMake 3.3 behavior of this is the same as it has always been since 
>>> introducing compile-features for SolarisStudio. 
>> 
>> Well that behavior was broken.  We never had a nightly dashboard for it.
>> Now I got nightly testing set up and it fails many tests without my changes.
>
>OTOH I should not have rushed in this change for 3.4.  We can just let
>it act as 3.3 did and no one will be worse off.  Then we can pick this
>up in post-3.4 development.  Reverted for now:
>
> Revert topic 'compiler-features-solaris'
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=340d0897
>
>I've scheduled this for the 'release' branch for 3.4.0-rc2.
>
>-Brad
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] How to check if test exists

[CHEVRIER, Marc]

Hi,

What is the best way to check if a test is already defined using function 
add_test?
My initial though was that if() can be used for that purpose but, 
unfortunately, if (TEST ) is not supported for now.

Thanks.

Marc


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CXX_STANDARD and linking

[CHEVRIER, Marc]

Seems OK for me… But my personal situation is even worst now! :)

The situation evolved from a buggy support of C++11 on Solaris to no support at 
all. Do you have any idea (and schedule) for re-introduction of this feature, 
knowing that the key point is the lack of propagating of c++11 compile option 
to the link command. 

Thank you for your help.

Marc




On 30/09/15 16:01, "Brad King"  wrote:

>On 09/28/2015 03:20 PM, Brad King wrote:
>> for now we should look at turning off all language standard and
>> compile feature support for SolarisStudio when not hosted on Linux.
>
>Done here:
>
> Features: Disable support for Oracle SolarisStudio on non-Linux
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61bc0f73
>
> Tests: Suppress WriteCompilerDetectionHeader failure on SunPro
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fdf7594
>
>I also made a fix for Linux:
>
> Features: Fix C++98 flags on Oracle SolarisStudio 12.4 on Linux
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c824b23d
>
>Steve, please review these changes.
>
>Thanks,
>-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CXX_STANDARD and linking

[CHEVRIER, Marc]

On Solaris, activating C++11 standard switch the compiler into a completely 
different mode:
* Mangling is different
* C++ runtime is the GNU one, delivered as part of SolarisStudio 12.4 (Sun C++ 
runtime is no longer supported)

This is why the flag -std=c++11 must be passed to the link step to enable 
compiler to select the correct runtime…

Marc




On 28/09/15 21:20, "cmake-developers on behalf of Brad King" 
 wrote:

>On 09/28/2015 02:34 PM, Stephen Kelly wrote:
>>> Steve?  According to cmake-compile-features(7) you tested this with
>>> Oracle SolarisStudio version 12.4.
>> 
>> Yes, I tested it on SolarisStudio 12.4, but on linux (Ubuntu). Perhaps 
>> that's a relevant difference from 'real' Solaris.
>
>That seems to be the case.  The interaction with C++ runtime library
>selection may differ.
>
>Although we had dashboard builds for SolarisStudio 12.3 on SunOS the
>compiler feature/standard logic is enabled only for SunPro 5.13 and
>above which do not appear until SolarisStudio 12.4.
>
>On 09/28/2015 01:42 PM, Brad King wrote:
>> The logic in cmLocalGenerator::AddCompileOptions that selects the final
>> _STANDARD level and adds a flag for it may need to be factored
>> out into a separate step (in Compute?) that selects the level.  Then
>> AddCompileOptions can continue to add the compiler flag and we'll need
>> new code to add link-time compiler-driver flags based on the selected
>> standard level.
>
>Steve, does using _STANDARD to put -std= flags on the link line
>seem like the right approach to fix this?
>
>This won't be done before CMake 3.4 so for now we should look at
>turning off all language standard and compile feature support for
>SolarisStudio when not hosted on Linux.
>
>Thanks,
>-Brad
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CXX_STANDARD and linking (was: C++11 support broken for SolarisStudio 12.4)

[CHEVRIER, Marc]

Hi,

Bootstrapping CMake with the flags you specify and SOlarisStudio 12.4 enable to 
generate a usable Cmake but some tests are failing with error related to CXX 
standard.
For example, test 32, CompileFeatures generates error:
32: CMake Error: Error required internal CMake variable not set, cmake may be 
not be built correctly.
32: Missing variable is:
32: CMAKE_CXX98_EXTENSION_COMPILE_OPTION

In the meantime, I am using SolarisStudio 12.2 for CMake bootstrapping.

Anyway, the main problem is the fact that, currently, C++ standard handling is 
not usable on Solaris. Do have any plan to fix this problem anytime soon?


After this problem fixed, I hope CMake bootstrapping will be solved as well…

Thank you for your help.

Marc


On 25/09/15 17:24, "Brad King" <brad.k...@kitware.com> wrote:

>Steve,
>
>On 09/25/2015 03:58 AM, CHEVRIER, Marc wrote:
>> * If I add option -std=c++11 in the file .../Test.dir/link.txt,
>>   link is successful 
>
>Compiling with a -std= flag should link with such a flag too.
>Flags like this are why CMake has always passed CMAKE_CXX_FLAGS
>to the C++ compiler when using it to drive the linker.  This does
>not appear to be the case anywhere right now when the flag is added
>via CXX_STANDARD.
>
>Marc, meanwhile you should be able to bootstrap CMake with
>
> bootstrap ... -- -DCMake_NO_C_STANDARD=1 -DCMake_NO_CXX_STANDARD
>
>to skip trying to use any -std= flags.
>
>-Brad
>
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake][BUG] C++11 support broken for SolarisStudio 12.4

[CHEVRIER, Marc]

Hi,

Currently, it is not possible to use C++11 mode on Solaris with SolarisStudio 
12.4 (test done on Solaris 11.2 sparc).
If I try a simple executable (see attached file), compilation is OK (option 
–std=c++11 is correctly passed to compiler) but link failed because, with 
SolarisStudio compiler, option –std=c++11 is also required at link time and is 
currently missed.
And unfortunately, it seems there is no equivalent to compile configuration 
variable CMAKE_CXX11_STANDARD_COMPILE_OPTION for the linker so no so easy to 
fix this problem…

Here is the log (see red lines):
/opt/solarisstudio12.4/bin/CC-std=c++11 -o CMakeFiles/Test.dir/test.cpp.o 
-c /usr/u/i051466/tests/cmake/build/test.cpp
[100%] Linking CXX executable Test
/usr/u/i051466/INSTALL.122/bin/cmake -E cmake_link_script 
CMakeFiles/Test.dir/link.txt --verbose=1
/opt/solarisstudio12.4/bin/CC  CMakeFiles/Test.dir/test.cpp.o  -o Test
Undefined   first referenced
 symbol in file
std::ctype::_M_widen_init()constCMakeFiles/Test.dir/test.cpp.o
std::ostream::put(char) CMakeFiles/Test.dir/test.cpp.o
std::__throw_bad_cast() CMakeFiles/Test.dir/test.cpp.o
__SUNW_ABIG3_cpp_personalityCMakeFiles/Test.dir/test.cpp.o
__cxxabiv1::register_exit_code(void (*)(void)extern"C") 
CMakeFiles/Test.dir/test.cpp.o
std::ostream::flush()   CMakeFiles/Test.dir/test.cpp.o
std::cout   CMakeFiles/Test.dir/test.cpp.o
[Hint: static member std::cout must be defined in the program]

std::ios::clear(std::_Ios_Iostate) CMakeFiles/Test.dir/test.cpp.o
std::ios_base::Init::~Init() CMakeFiles/Test.dir/test.cpp.o
std::ios_base::Init::Init() CMakeFiles/Test.dir/test.cpp.o
std::ostream & std::__ostream_insert(std::ostream &,const char*,int) CMakeFiles/Test.dir/test.cpp.o
ld: fatal: symbol referencing errors

FYI:
* If I add option –std=c++11 in the file …/Test.dir/link.txt, link is successful
* I built CMake using version 12.2 of SolarisStudio because if I use 
SolarisStudio 12.4, cmake tool is unsuable (I will sent another mail describing 
this problem).

Marc



cmake_minimum_required (VERSION 3.3.2)

project (Test LANGUAGES CXX)

file (WRITE ${CMAKE_BINARY_DIR}/test.cpp "#include \nint main 
()\n{std::cout <<\"Hello\"<

[cmake-developers] [CMake][BUG] Unable to build CMake with SolarisStudio 12.4

[CHEVRIER, Marc]

Hi,

Attached is a patch fixing compilation error which prevent building CMake with 
SolarisStudio 12.4.

Marc



0001-SolarisStudio-12.4-cmake-compilation-fix.patch
Description: 0001-SolarisStudio-12.4-cmake-compilation-fix.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES

[CHEVRIER, Marc]

Hi Domen,

Good news! With your patch, packaging on Windows is now working as expected.
Thank you.

Marc




On 25/09/15 10:34, "Domen Vrankar" <domen.vran...@gmail.com> wrote:

>2015-09-24 9:06 GMT+02:00 Domen Vrankar <domen.vran...@gmail.com>:
>> 2015-09-23 17:00 GMT+02:00 CHEVRIER, Marc <marc.chevr...@sap.com>:
>>> Any comments about this problem?
>
>There was a bug in file creation time handling. Fix is in cmake git
>repository on next branch:
>http://cmake.org/gitweb?p=cmake.git;a=commit;h=39347d3
>
>Could you check if it works for you?
>
>Thanks,
>Domen
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake][BUG] Ensure C based tests do not used C++ syntax

[CHEVRIER, Marc]

Hi,

I encountered some problems validating a CMake build on AIX using IBM xlc/xlC 
compilers. The problem comes from the fact that, by default, C compiler does 
not recognized C++-Style comments.
So, attached is a patch ensuring that sources compiling with a C compiler have 
C-Style comments only.

Marc



0001-Use-C-Style-comments-in-C-sources-and-headers.patch
Description: 0001-Use-C-Style-comments-in-C-sources-and-headers.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CMake][BUG] ProcessorCount is broken on current SunOS systems

[CHEVRIER, Marc]

Hi,

Attached is a patch to ensure that ProcessorCount returns correct information 
on recent SunOS systems (tested on Sunos 5.11 (i.e. Solaris 11.2)).

Marc



0001-Update-ProcessorCount-module-for-recent-SunOS.patch
Description: 0001-Update-ProcessorCount-module-for-recent-SunOS.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [CPack][BUG] Fail to package with CPACK_INSTALLED_DIRECTORIES

[CHEVRIER, Marc]

Hi,

To enable to handle various packages as part of the same project and to avoid 
to execute preinstall target before packaging, I rely on CPack variables 
CPACK_INSTALLED_DIRECTORIES and CPACK_INSTALL_COMMANDS.

Unfortunately, packaging is failing in the following conditions:

  *   Platform Windows (regardless generator: test done with “Visual Studio” 
and "Ninja”)
  *   Install command with PERMISSIONS read-only (like OWNER_READ)
  *   PROJECT command with LANGUAGES CXX (specifying LANGUAGES NONE is OK !??)

In this case, installed read-only files cannot be copied by CPack.

Attached is a CMakeLists.txt showing the problem:

  *   Target package-OK generates the expected package (no read-only 
permissions)
  *   Target package-KO fails to generate the package (same as previous one 
except read-only permissions)

Marc


cmake_minimum_required (VERSION 3.1)

project (TEST LANGUAGES CXX)

install (FILES file.h PERMISSIONS OWNER_READ GROUP_READ WORLD_READ DESTINATION 
include COMPONENT KO)

install (FILES file.h DESTINATION include COMPONENT OK)


set (CPACK_GENERATOR "TGZ")

set (install_prefix ${CMAKE_SOURCE_DIR}/INSTALL)

set (KO_install_command "${CMAKE_COMMAND} 
-DCMAKE_INSTALL_PREFIX=${install_prefix} -DCOMPONENT=KO -DBUILD_TYPE=$ 
-P ${CMAKE_BINARY_DIR}/cmake_install.cmake")

add_custom_target (package-KO COMMAND "${CMAKE_CPACK_COMMAND}" -C $ -D 
CPACK_COMPONENTS_ALL=KO -D CPACK_INSTALL_COMMANDS=${KO_install_command} -D 
CPACK_INSTALLED_DIRECTORIES=${install_prefix}$. --config 
./CPackConfig.cmake)


set (OK_install_command "${CMAKE_COMMAND} 
-DCMAKE_INSTALL_PREFIX=${install_prefix} -DCOMPONENT=OK -DBUILD_TYPE=$ 
-P ${CMAKE_BINARY_DIR}/cmake_install.cmake")

add_custom_target (package-OK COMMAND "${CMAKE_CPACK_COMMAND}" -C $ -D 
CPACK_COMPONENTS_ALL=OK -D CPACK_INSTALL_COMMANDS=${OK_install_command} -D 
CPACK_INSTALLED_DIRECTORIES=${install_prefix}$. --config 
./CPackConfig.cmake)

include (CPack)
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

[CHEVRIER, Marc]

I completely agree. Seems reasonable to disallow exporting ALIAS targets.

Marc




On 14/09/15 19:34, "cmake-developers on behalf of Stephen Kelly" 
 wrote:

>Michael Scott wrote:
>
>> Hi,
>> 
>> I'm planning on having a look at the CMake issue "Allow ALIAS of
>> IMPORTED targets", 0015569. After reading the thread between yourself
>> and Marc, I wanted to ask a couple of things before I start going
>> further with it.
>
>Thanks for working on this.
>
>> The proposed change would be for the add_library and add_executable
>> commands only right?
>
>Yes, I guess so.
>
>> Having a quick look at the code for those two commands, they
>> specifically check for a combination of ALIAS and IMPORTED and don't
>> allow it. I'm guessing that the required changes to allow both
>> simultaneously wouldn't be to just remove this check, there would be
>> other areas to modify as well right?
>
>Perhaps. Finding that out is the real task :). I don't have all the answers 
>to it. The specific disallowing of ALIAS and IMPORTED together by issuing an 
>error was a way to defer finding those answers while not being required to 
>maintain compatibility with a particular behavior. I didn't want finding 
>those answers to delay getting the ALIAS feature in, because it was useful 
>already as it was.
>
>Now, we have time to consider all of the implications of allowing this as 
>part of the design.
>
>For example, if an ALIAS can be IMPORTED, does it makes sense that it can be 
>exported with export() and install(EXPORT)?
>
>If we have 
>
> add_library(CoreStatic ${Core_SRCS})
> add_library(MyNS::Core ALIAS CoreStatic)
>
>and I export both of them with the NAMESPACE 'MyNS::', do I end up with 
>
> MyNS::MyNS::Core 
>
>?
>
>Or would the exporting code strip of everything before a '::' in the alias 
>name?
>
>Or should exporting ALIAS targets still be disallowed?
>
>The two use cases described in 
> 
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52452
>
>seem like they would not benefit from exporting ALIAS targets.
>
>A reasonable way forward might be:
>
>* Keep the restriction that ALIAS targets may not be exported.
>* Remove the code disallowing ALIAS IMPORTED targets.
>* Remove the unit test proving it is not allowed
>* Add new unit tests that it basically works
>* Add a unit test for using an ALIAS with try_compile(LINK_LIBRARIES)
>* (Anything else that comes up along the way)
>
>Thanks,
>
>Steve.
>
>
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

[CHEVRIER, Marc]

Hi Michael,

If this feature can be supported for libraries and executables, it will be 
perfect for me.
Thank you.

Marc



On 12/09/15 23:48, "cmake-developers on behalf of Michael Scott" 
 
wrote:

>Hi,
>
>I'm planning on having a look at the CMake issue "Allow ALIAS of 
>IMPORTED targets", 0015569. After reading the thread between yourself 
>and Marc, I wanted to ask a couple of things before I start going 
>further with it.
>
>The proposed change would be for the add_library and add_executable 
>commands only right?
>
>Having a quick look at the code for those two commands, they 
>specifically check for a combination of ALIAS and IMPORTED and don't 
>allow it. I'm guessing that the required changes to allow both 
>simultaneously wouldn't be to just remove this check, there would be 
>other areas to modify as well right?
>
>Cheers,
>Michael
>-- 
>
>Powered by www.kitware.com
>
>Please keep messages on-topic and check the CMake FAQ at: 
>http://www.cmake.org/Wiki/CMake_FAQ
>
>Kitware offers various services to support the CMake community. For more 
>information on each offering, please visit:
>
>CMake Support: http://cmake.org/cmake/help/support.html
>CMake Consulting: http://cmake.org/cmake/help/consulting.html
>CMake Training Courses: http://cmake.org/cmake/help/training.html
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] find_program HINTS no longer preferred over PATH

[CHEVRIER, Marc]

Any news on this subject?
I think it is a critical bug because behaviour is broken. So I cannot rely on 
find_executable anymore to get the expected program!

Marc



On 09/09/15 20:20, "Brad King"  wrote:

>On 09/09/2015 11:50 AM, Chuck Atkins wrote:
>> From what I can tell, the search order is still preserved as expected.
>
>The example Marc attached earlier shows that the problem is when
>ENV{PATH} contains one of the *same* values that is one of the HINTS.
>The fact that a path appears in ENV{PATH} somehow causes it to be
>dropped from the list of HINTS or otherwise ordered after the other
>hints.
>
>-Brad
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] CMAKE_CXX_COMPILE_OBJECT not set with ADD_SUBDIRECTORY

[CHEVRIER, Marc]

PROJECT instruction MUST BE the first one after CMAKE_MINIMUM_REQUIRED:
-- lib
   CMakeLists.txt
   {
   CMAKE_MINIMUM_REQUIRED (VERSION 2.8.8)
   PROJECT(lib)
   ADD_SUBDIRECTORY(libtest)
   }


From: CMake on behalf of Emmanuel HOUITTE
Date: Friday 11 September 2015 15:26
To: "cmake@cmake.org"
Subject: [CMake] CMAKE_CXX_COMPILE_OBJECT not set with ADD_SUBDIRECTORY

I’m working with cmake version 2.8.12.2 on CentOS6.
I’ve got a very simple project with one subdirectory.
Each directory has a CMakeLists.txt file.
The ADD_SUBDIRECTORY seems to remove the default generated CMAKE rule variables 
in the generation step.
Is it normal? How to get an example without generation errors?
If I replace the ADD_SUBDIRECTORY by the code of the second CMakeLists.txt, 
there is no problem.

This is the content of my project:

-- lib
   CMakeLists.txt
   {
   CMAKE_MINIMUM_REQUIRED (VERSION 2.8.8)
   ADD_SUBDIRECTORY(libtest)
   PROJECT(lib)
   }
   -- libtest
  CMakeLists.txt
  {
  FILE(WRITE "empty.cpp" "")
  ADD_LIBRARY(test STATIC empty.cpp )
  }

And the results:

$ cmake -DCMAKE_BUILD_TYPE=Release
-- Configuring done
CMake Error: Error required internal CMake variable not set, cmake may be not 
be built correctly.
Missing variable is:
CMAKE_CXX_COMPILE_OBJECT
CMake Error: Error required internal CMake variable not set, cmake may be not 
be built correctly.
Missing variable is:
CMAKE_CXX_CREATE_STATIC_LIBRARY
-- Generating done
-- Build files have been written to: /home/test/lib
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [BUG] HINTS not correctly handled in find_program

[CHEVRIER, Marc]

Hi,

Attached is a minimal example.
To use it:
1. Build phase. Under find_program.BUG/build, use CMakeLists.txt to prepare 
runtime part
2. Test phase. Under find_program.BUG/runtime, use CMakeLists.txt to show the 
bug.

Here is the result on my SuSE Linux with CMake 3.3.1 (binaries retrieved from 
CMake web site):

-- The C compiler identification is GNU 4.3.4
-- The CXX compiler identification is GNU 4.3.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
Test1: Fail to found correct exe: 
/home/marc/tests/find_program.BUG/runtime/dir2/exe
Test2: Found correct exe: /home/marc/tests/find_program.BUG/runtime/dir1/exe
-- Configuring done
-- Generating done
-- Build files have been written to: 
/home/marc/tests/find_program.BUG/runtime/gen

Marc





On 02/09/15 17:44, "Brad King" <brad.k...@kitware.com> wrote:

>On 09/02/2015 09:09 AM, CHEVRIER, Marc wrote:
>> On 02/09/15 14:58, "Brad King" wrote:
>>> On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote:
>>>> find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3)
>>>
>>> find_program (MY_EXE
>>>   NAMES my_exe
>>>   HINTS PATH1 PATH2 PATH3
>>>   )
>> Same problem. HINTS which are also defined in the environment
>> variable PATH are ignored.
>
>I'm having trouble reproducing this.  Please provide a tarball
>with a full CMakeLists.txt and supporting files that demonstrate
>this.  You can "set(ENV{PATH} ...)" if needed.
>
>Thanks,
>-Brad


find_program.BUG.tar.gz
Description: find_program.BUG.tar.gz
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Patch on Windows?

[CHEVRIER, Marc]

FYI, the latest version (2.5.1) of git for Windows (available 
https://github.com/git-for-windows/git/releases and http://git-scm.com/) 
includes again the patch tool.

Marc

From: CMake on behalf of "Macumber, Daniel"
Date: Tuesday 1 September 2015 17:51
To: "cmake@cmake.org"
Subject: [CMake] Patch on Windows?

There was a thread back in January of 2014 about “It would be great if CMake 
implemented a "cmake -E patch".”.  This feature would really help us out, 
especially since the patch tool was removed from the Git for Windows 
distribution (I have no idea why).  Did anything ever happen with this request?

Thanks a lot,
Dan

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] [BUG] HINTS not correctly handled in find_program

[CHEVRIER, Marc]

Hi,

I discovered a curious problem regarding handling of argument HINTS.
If I use the following command:

find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3)

And my_exe is available in various paths. In this case, paths specified in 
HINTS AND also defined in environment variable PATH are ignored !
For example, with environment variable PATH=PATH1:PATH2, find_program will 
gives PATH3/my_exe as result.

This problem occurs on Windows and Linux (at least) in versions 3.2.1 and 
3.3.1. The behavior is correct with version 3.1.3.

Marc
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [BUG] HINTS not correctly handled in find_program

[CHEVRIER, Marc]

Same problem. HINTS which are also defined in the environment variable PATH are 
ignored.



On 02/09/15 14:58, "Brad King" <brad.k...@kitware.com> wrote:

>On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote:
>> find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3)
>
>Try it with
>
> find_program (MY_EXE
>   NAMES my_exe
>   HINTS PATH1 PATH2 PATH3
>   )
>
>-Brad
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[CHEVRIER, Marc]

Offering generator-expressions is a very good idea because it offers a global 
solution to this problem.

Now regarding the name of the generator, may be TO_NATIVE_PATH is not 
judicious, (even if problems explained in 
http://www.cmake.org/Bug/view.php?id=5939 are, in my point of view, linked to 
platforms not well handled rather than wrong semantic of TO_NATIVE_PATH) but 
PATH_FOR_SHELL is, as well, ambiguous at least for two reasons:
* commands defined in add_custom_command, for example, are directly executed 
without any shell evolved
* A system can have multiple shells supporting different paths syntax. For 
example, on windows, my shell is tcsh which handle paths with ‘/‘ rather than 
‘\'

May be, TO_SYSTEM_PATH or TO_HOST_SYSTEM_PATH make more sense…

Marc




On 27/08/15 17:18, cmake-developers on behalf of Brad King 
cmake-developers-boun...@cmake.org on behalf of brad.k...@kitware.com wrote:

On 08/27/2015 10:06 AM, James Johnston wrote:
 I would vote naming it TO_NATIVE_PATH instead of PATH_FOR_SHELL, for
 consistency with the existing parameter in the file command.

The file(TO_NATIVE_PATH) command is hopelessly ill-defined:

 http://www.cmake.org/Bug/view.php?id=5939

See also existing discussion about a genex for such conversions:

 http://www.cmake.org/Bug/view.php?id=15509

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] generator expression for path slash conversion (was: ExternalProject: Use native paths as substitute for directory tokens)

[CHEVRIER, Marc]

Sorry for the false assertion.
I assumed, wrongly, that add_custom_command had same behaviour as 
execute_process for which the doc clearly explains that System API are used (no 
shell used).
So, adding some precisions on how add_custom_command (and add_custom_target I 
presume) launch specified commands should be a nice enhancement.

Marc





On 28/08/15 15:59, cmake-developers on behalf of Brad King 
cmake-developers-boun...@cmake.org on behalf of brad.k...@kitware.com wrote:

On 08/28/2015 04:06 AM, CHEVRIER, Marc wrote:
 Offering generator-expressions is a very good idea because it offers
 a global solution to this problem.
 
 Now regarding the name of the generator, may be TO_NATIVE_PATH is
 not judicious, (even if problems explained in
 http://www.cmake.org/Bug/view.php?id=5939 are, in my point of view,
 linked to platforms not well handled rather than wrong semantic of
 TO_NATIVE_PATH) but PATH_FOR_SHELL is, as well, ambiguous at least
 for two reasons:
 * commands defined in add_custom_command, for example, are directly
   executed without any shell evolved

No, add_custom_command results in a generated build system rule for
the specified command, and that always runs in a shell at build time.
One can see the conversions done properly internally to CMake for
generating references to source and object files on toolchain command
lines, for example.

 * A system can have multiple shells supporting different paths syntax.
   For example, on windows, my shell is tcsh which handle paths with '/'
   rather than '\'

It would be defined as the shell in which the build system will run
the commands.  We should choose a name accordingly.

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[CHEVRIER, Marc]

I agree with David.

Offering the possibility to manage native paths in an easy way is a very good 
enhancement (Today, I rely on some specific actions when I am on Win32 to 
manage native path for ONE specific step of ExternalProject) BUT, offering only 
the alternative to have NONE or ALL paths in native form is, by far, too 
restrictive.
So I am for the solution providing new patterns as alternative to current ones 
to manage native paths, i.e. Adding *_NATIVE_DIR for all already available 
*_DIR patterns.

Marc



On 25/08/15 17:31, cmake-developers on behalf of David Cole via 
cmake-developers cmake-developers-boun...@cmake.org on behalf of 
cmake-developers@cmake.org wrote:

I'm going to let other CMake developers chime in on this one.

It's better than the first patch, because it's opt-in, and you have to
add something to get different than previous behavior, but I'm still
of the opinion that this is very command specific, and you won't
always want all _DIR references as native. In my opinion, it's better
left to the person constructing the ExternalProject_Add call. But I am
curious to hear other CMake devs give their opinions.


David C.



On Tue, Aug 25, 2015 at 3:18 AM, Kislinskiy, Stefan
s.kislins...@dkfz-heidelberg.de wrote:
 Dear CMake developers,

 any thoughts on the fix? :)

 Best regards,
 Stefan Kislinskiy
 
 Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
 Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de]
 Gesendet: Freitag, 21. August 2015 23:56
 An: David Cole; James Johnston
 Cc: cmake-developers@cmake.org
 Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens

 What do you think about the new patch I attached to this mail? It adds an 
 option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake 
 script file which tests/shows this feature.

 Stefan Kislinskiy
 
 Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
 David Cole via cmake-developers [cmake-developers@cmake.org]
 Gesendet: Donnerstag, 20. August 2015 23:20
 An: James Johnston
 Cc: cmake-developers@cmake.org
 Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens

 It's exactly what I am concerned about:

 You're asking to change the behavior of something for EVERYONE to
 solve a problem which you have encountered. If you change it the way
 you have proposed, you will cause problems for others. It has worked
 the way it is now since ExternalProject_Add was introduced in CMake
 2.8. Changing it unconditionally the way you propose is simply not
 feasible for backwards compatibility.

 I think commands that take native paths ought NOT to use the *_DIR
 replacement values, and instead, ought to pass in variables that
 contain the native paths in the first place.


 David C.



 On Thu, Aug 20, 2015 at 2:58 PM, James Johnston
 johnstonj.pub...@codenest.com wrote:
 Hi,

 Funny you are mailing the list about this, since I just ran into this same 
 issue today building something totally different from Boost...  In this 
 case it's a build tool that thinks the /U in C:/Users is a new command 
 line argument, that isn't recognized - and then the subsequent s also 
 ends up unrecognized... and it all fails...  And it has nothing to do with 
 the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible 
 workaround for me.

 I think the issue with globally making this change to the existing tokens 
 is that there could be some external tool/program that is EXPECTING to get 
 CMake paths, not native paths.  Who knows?  I am guessing that is what 
 David Cole was concerned about.

 Maybe the right answer is to introduce some NEW tokens while leaving the 
 behavior of the old ones unchanged.  E.g. BINARY_DIR_NATIVE etc.  It 
 would be good if the patch updates the documentation of ExternalProject and 
 clearly states the path format of BINARY_DIR vs BINARY_DIR_NATIVE.  
 Then the user can pick whichever one suits them best, depending on the tool 
 being invoked.

 Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with 
 a CMake path, not native path.  For example, if the token is being found in 
 a property like WORKING_DIRECTORY that eventually gets passed to 
 add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a 
 CMake path.  I am guessing this is what David Cole was also concerned about.

 I still think your original method of building Boost is a bit unusual and 
 would be better served by _Add_Step with a custom working directory - 
 because that's the publicly documented/standard way of changing the working 
 directory, but that is up to you.  :)

 Best regards,

 James Johnston


  On Thu, 20 Aug 2015 14:37:08 +  Stefan Kislinskiy 
 s.kislins...@dkfz-heidelberg.de wrote 

   Hi,
  
   thank you for our suggestions. I am aware 

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[CHEVRIER, Marc]

I didn’t even think about switches. I don’t think they are required.
Adding the capability to handle paths in native format seems enough.

Example: I want to use a specific tool for the build step which supports only 
native paths
ExternalProjet_add (
….
SOURCE_DIR c:/sources/my_project
….
BUILD_COMMAND ${MY_CUSTOM_COMMAND} -IN SOURCE_NATIVE_DIR -OUT 
BINARY_NATIVE_DIR
…
)

With this approach, the previous behaviour is ensured and it is easy, for 
specify cases, to use native paths.





On 26/08/15 09:35, Kislinskiy, Stefan s.kislins...@dkfz-heidelberg.de wrote:

Would you prefer to have a switch for each *_DIR variable for all target 
steps, or a common switch but for each target step, like the new USE_TERMINAL 
switches in the master?

Von: CHEVRIER, Marc [marc.chevr...@sap.com]
Gesendet: Mittwoch, 26. August 2015 08:49
An: David Cole; Kislinskiy, Stefan
Cc: cmake-developers@cmake.org
Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
substitute for directory tokens

I agree with David.

Offering the possibility to manage native paths in an easy way is a very good 
enhancement (Today, I rely on some specific actions when I am on Win32 to 
manage native path for ONE specific step of ExternalProject) BUT, offering 
only the alternative to have NONE or ALL paths in native form is, by far, too 
restrictive.
So I am for the solution providing new patterns as alternative to current ones 
to manage native paths, i.e. Adding *_NATIVE_DIR for all already available 
*_DIR patterns.

Marc



On 25/08/15 17:31, cmake-developers on behalf of David Cole via 
cmake-developers cmake-developers-boun...@cmake.org on behalf of 
cmake-developers@cmake.org wrote:

I'm going to let other CMake developers chime in on this one.

It's better than the first patch, because it's opt-in, and you have to
add something to get different than previous behavior, but I'm still
of the opinion that this is very command specific, and you won't
always want all _DIR references as native. In my opinion, it's better
left to the person constructing the ExternalProject_Add call. But I am
curious to hear other CMake devs give their opinions.


David C.



On Tue, Aug 25, 2015 at 3:18 AM, Kislinskiy, Stefan
s.kislins...@dkfz-heidelberg.de wrote:
 Dear CMake developers,

 any thoughts on the fix? :)

 Best regards,
 Stefan Kislinskiy
 
 Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
 Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de]
 Gesendet: Freitag, 21. August 2015 23:56
 An: David Cole; James Johnston
 Cc: cmake-developers@cmake.org
 Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens

 What do you think about the new patch I attached to this mail? It adds an 
 option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake 
 script file which tests/shows this feature.

 Stefan Kislinskiy
 
 Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
 David Cole via cmake-developers [cmake-developers@cmake.org]
 Gesendet: Donnerstag, 20. August 2015 23:20
 An: James Johnston
 Cc: cmake-developers@cmake.org
 Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
 substitute for directory tokens

 It's exactly what I am concerned about:

 You're asking to change the behavior of something for EVERYONE to
 solve a problem which you have encountered. If you change it the way
 you have proposed, you will cause problems for others. It has worked
 the way it is now since ExternalProject_Add was introduced in CMake
 2.8. Changing it unconditionally the way you propose is simply not
 feasible for backwards compatibility.

 I think commands that take native paths ought NOT to use the *_DIR
 replacement values, and instead, ought to pass in variables that
 contain the native paths in the first place.


 David C.



 On Thu, Aug 20, 2015 at 2:58 PM, James Johnston
 johnstonj.pub...@codenest.com wrote:
 Hi,

 Funny you are mailing the list about this, since I just ran into this same 
 issue today building something totally different from Boost...  In this 
 case it's a build tool that thinks the /U in C:/Users is a new command 
 line argument, that isn't recognized - and then the subsequent s also 
 ends up unrecognized... and it all fails...  And it has nothing to do with 
 the working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible 
 workaround for me.

 I think the issue with globally making this change to the existing tokens 
 is that there could be some external tool/program that is EXPECTING to get 
 CMake paths, not native paths.  Who knows?  I am guessing that is what 
 David Cole was concerned about.

 Maybe the right answer is to introduce some NEW tokens while leaving the 
 behavior of the old ones unchanged.  E.g. BINARY_DIR_NATIVE etc.  It 
 would be good

Re: [CMake] Prefix header for Makefiles

[CHEVRIER, Marc]

Hi,

You are wrong. CMake, during configuration/generation phase generates 
dependencies over C/C++ files.
So, the simple approach to handle dependency between Cpp and h files is to let 
CMake handle it:

add_executable (my_exe Main.cpp)

And, that it! By default current source directory is passed to the compiler for 
resolving #include directives.
And for adding other directories, use command target_include_directories.

Marc

From: CMake on behalf of Jakob van Bethlehem
Date: Wednesday 26 August 2015 15:10
To: cmake@cmake.orgmailto:cmake@cmake.org
Subject: Re: [CMake] Prefix header for Makefiles

Hej Andrew,

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

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

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

Sincerely, Jakob

On 26 Aug 2015, at 11:48, Andrew Shaitorov 
andrew.shaito...@gmail.commailto:andrew.shaito...@gmail.com wrote:

Hi All!

I have a very annoying problem with CMake Makefiles generator.

I'm using prefix header (see attached archive for minimized test).

There is one source file named Main.cpp and two header files: Prefix.h and 
DependHeader.h. Prefix.h includes DependHeader.h and Main.cpp includes Prefix.h 
by using prefix header compiler flag (-include for GCC/Clang and /FI for MSVC):

set_source_files_properties(Main.cpp PROPERTIES
COMPILE_FLAGS -include Prefix.h
OBJECT_DEPENDS ${CMAKE_CURRENT_LIST_DIR}/Prefix.h)

When I change Prefix.h, then make recompiles Main.cpp as needed. But when I 
make a change in DependHeader.h, then no recompilation happens. Its clear for 
me that I have to specify all depend files in OBJECT_DEPENDS option, but in 
real project there may be a lot of depend files with nested includes. And the 
most annoying thing is that the project compiles without any errors and may 
just crash because of struct layout or other critical changes in depend headers.

I seems like the following script have the same problem when using 
FORCE_INCLUDE option:

https://github.com/larsch/cmake-precompiled-header/blob/master/PrecompiledHeader.cmake

I looked in CMake source code and didn't find a way to add Prefix.h in a list 
for dependency scanning. Also I don't know how to run depend scanner on 
Prefix.h in CMake script to generate a list of all depend files for 
OBJECT_DEPENDS option.

Any advise?

Best,
Andrew.

CMakePrefixHeaderTest.zip--

Powered by www.kitware.comhttp://www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

Thank you.
Unfortunately I don’t have access to an HP-UX system.
From what I remember, HP-UX expect shared libraries with same name pattern as 
Linux except that extension is .sl rather than .so.





Marc

On 14/08/15 15:45, Brad King brad.k...@kitware.com wrote:

On 08/07/2015 04:04 AM, CHEVRIER, Marc wrote:
 New version of patch attached.

Thanks.  Applied with a few tweaks:

 UseJava: Add support for javah tool
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cae7bef9

However, it fails on some HP-UX machines because Java does not know
how to load the native library we produce.  Does anyone know what
name HP-UX is expecting (I don't have access to it myself)?

-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

Hi,

New version of patch attached.
I added a check on java tool to execute test only if java and shared library 
built by test have same architecture (32 or 64bit).

Marc




On 05/08/15 17:49, Brad King brad.k...@kitware.com wrote:

On 08/05/2015 03:15 AM, CHEVRIER, Marc wrote:
 For point 2., The best approach is to install 32 and 64bit
 versions of Java SDK (Windows versions, not some cygwin or
 MSYS versions) and ensure JAVA_HOME is NOT set in the
 environment nor referenced in the PATH. In this case, CMake
 FindJava.cmake module will look at the registry to retrieve
 the correct java version.

CMake's test suite needs to adapt to the environment in which
it is run and not run this test unless the architecture of
java and the toolchain match.  Certainly we can set up an
environment in which it works but we should not fail just
because that hasn't been done.

On 08/05/2015 06:24 AM, CHEVRIER, Marc wrote:
 Again, a new version for patch 4.

Thanks.  I'd prefer not to enable CXX as a language in the
project() command such that it affects the other Java tests.
Please create a separate source tree for the new test.  Sorry
I didn't notice this earlier.

Meanwhile the other three patches now tested cleanly.

Thanks,
-Brad


0004-Add-support-for-javah-tool.patch
Description: 0004-Add-support-for-javah-tool.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

Hi,

For point 1. I completely forgot to test with VS generators… I will work on 
that ASAP.
For point 2., The best approach is to install 32 and 64bit versions of Java SDK 
(Windows versions, not some cygwin or MSYS versions) and ensure JAVA_HOME is 
NOT set in the environment nor referenced in the PATH. In this case, CMake 
FindJava.cmake module will look at the registry to retrieve the correct java 
version.





Marc

On 04/08/15 17:42, Brad King brad.k...@kitware.com wrote:

On 08/04/2015 04:45 AM, CHEVRIER, Marc wrote:
 Attached is a new version of patch 4 tested successfully
 on Linux (SuSE 11.3), Windows (7 64bit) and MacOS (10.10.4)

Thanks.  This still fails for me on Windows with a VS generator
for two reasons:

1.  The java.library.path setting points at the build directory
but not at the per-configuration subdirectory in which VS
generators place the .dll file.  I was able to hack around
this locally by extending Tests/Java/CMakeLists.txt with:

set_property(TARGET B PROPERTY RUNTIME_OUTPUT_DIRECTORY_DEBUG .)

though more work may be needed to work with other configs.

2.  With the above hack it still fails because java produces
32-bit binaries but I was using a 64-bit toolchain so the
plugin cannot load.

How are we to control the architecture for which java compiles?

Meanwhile I revised the other three commits:

 FindJava: Add support for idlj and jarsigner tools
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e72806fb

 UseJava: Teach add_jar to support file syntax for sources
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d287de4

 UseJava: Teach install_jar new DESTINATION and COMPONENT options
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cc23f0e9

We need to run the tests each in their own build tree or they
try to clobber each other during parallel testing.

-Brad
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

Hi,

Again, a new version for patch 4. I hope I didn’t miss anything this time. :)
To handle VS generators, I am relying on generator-expressions supported by 
add_test function.

Marc




On 04/08/15 17:42, Brad King brad.k...@kitware.com wrote:

On 08/04/2015 04:45 AM, CHEVRIER, Marc wrote:
 Attached is a new version of patch 4 tested successfully
 on Linux (SuSE 11.3), Windows (7 64bit) and MacOS (10.10.4)

Thanks.  This still fails for me on Windows with a VS generator
for two reasons:

1.  The java.library.path setting points at the build directory
but not at the per-configuration subdirectory in which VS
generators place the .dll file.  I was able to hack around
this locally by extending Tests/Java/CMakeLists.txt with:

set_property(TARGET B PROPERTY RUNTIME_OUTPUT_DIRECTORY_DEBUG .)

though more work may be needed to work with other configs.

2.  With the above hack it still fails because java produces
32-bit binaries but I was using a 64-bit toolchain so the
plugin cannot load.

How are we to control the architecture for which java compiles?

Meanwhile I revised the other three commits:

 FindJava: Add support for idlj and jarsigner tools
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e72806fb

 UseJava: Teach add_jar to support file syntax for sources
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3d287de4

 UseJava: Teach install_jar new DESTINATION and COMPONENT options
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cc23f0e9

We need to run the tests each in their own build tree or they
try to clobber each other during parallel testing.

-Brad


0004-Add-support-for-javah-tool.patch
Description: 0004-Add-support-for-javah-tool.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

Thanks.

I will have a look for the patch 4.

Marc




On 03/08/15 22:17, Brad King brad.k...@kitware.com wrote:

On 07/31/2015 04:08 AM, CHEVRIER, Marc wrote:
 New version of patches.

Thanks.

I applied the first three with minor tweaks and merged to 'next'
for testing:

 FindJava: Add support for idlj and jarsigner tools
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e499264

 UseJava: Teach add_jar to support file syntax for sources
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=244e9364

 UseJava: Teach install_jar new DESTINATION and COMPONENT options
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8f8d824d

The 0004 patch (create_javah) fails testing for me on Linux:

 $ ctest -R Java.Javah -V
 ...
 261: Running test command: /usr/lib/jvm/java-7-openjdk-amd64/bin/java 
 -classpath hello3.jar HelloWorld2
 261: Test command failed: /usr/lib/jvm/java-7-openjdk-amd64/bin/java
 261: Native code library failed to load.
 261: java.lang.UnsatisfiedLinkError: no B in java.library.path
 ...

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

Attached is a new version of patch 4 tested successfully on Linux (SuSE 11.3), 
Windows (7 64bit) and MacOS (10.10.4)

Marc



On 03/08/15 22:17, Brad King brad.k...@kitware.com wrote:

On 07/31/2015 04:08 AM, CHEVRIER, Marc wrote:
 New version of patches.

Thanks.

I applied the first three with minor tweaks and merged to 'next'
for testing:

 FindJava: Add support for idlj and jarsigner tools
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e499264

 UseJava: Teach add_jar to support file syntax for sources
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=244e9364

 UseJava: Teach install_jar new DESTINATION and COMPONENT options
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8f8d824d

The 0004 patch (create_javah) fails testing for me on Linux:

 $ ctest -R Java.Javah -V
 ...
 261: Running test command: /usr/lib/jvm/java-7-openjdk-amd64/bin/java 
 -classpath hello3.jar HelloWorld2
 261: Test command failed: /usr/lib/jvm/java-7-openjdk-amd64/bin/java
 261: Native code library failed to load.
 261: java.lang.UnsatisfiedLinkError: no B in java.library.path
 ...

Thanks,
-Brad



0004-Add-support-for-javah-tool.patch
Description: 0004-Add-support-for-javah-tool.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

OK.
New version of patches. There is now a component per extra tool (for now IdlJ 
and JarSigner as suggested by Brad) to ensure future extensibility.

Marc 




On 30/07/15 16:49, Brad King brad.k...@kitware.com wrote:

On 07/30/2015 09:55 AM, CHEVRIER, Marc wrote:
 here is the correct version.

Thanks.  The component name Extra sounds too generic and we won't
be able to extend it in the future with other extra parts for the
same reason these tools could not be made part of Development.
Perhaps instead we should have components named IdlJ and JarSigner
that applications can use to enforce that they are found.

Thanks,
-Brad



0001-Add-support-for-idlj-and-jarsigner-tools.patch
Description: 0001-Add-support-for-idlj-and-jarsigner-tools.patch


0002-add_jar-now-supports-file-syntax-for-sources.patch
Description: 0002-add_jar-now-supports-file-syntax-for-sources.patch


0003-install_jar-add-options-DESTINATION-and-COMPONENT.patch
Description: 0003-install_jar-add-options-DESTINATION-and-COMPONENT.patch


0004-Add-support-for-javah-tool.patch
Description: 0004-Add-support-for-javah-tool.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

I just detected a small error introduced in patch 0001, here is the correct 
version.
Sorry for the noise...





On 30/07/15 11:32, cmake-developers on behalf of CHEVRIER, Marc 
cmake-developers-boun...@cmake.org on behalf of marc.chevr...@sap.com wrote:


New version of patches taking into account Brad’ remarks.

Marc




On 29/07/15 15:47, Brad King brad.k...@kitware.com wrote:

On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote:
 here is an updated list of patches.

Great.

find_package_handle_standard_args(Java
  REQUIRED_VARS Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE 
 Java_JAVAC_EXECUTABLE
Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE
 +  Java_IDLJ_EXECUTABLE Java_JARSIGNER_EXECUTABLE
  VERSION_VAR Java_VERSION
  )

Are idlj and jarsigner reliably available whenever the other tools are?
Even for older versions?  Do these need to be REQUIRED_VARS?  I'm
concerned this could make a case that previously found java not report
it found anymore.

 -  --build-project hello
 +  --build-target hello

The tests should still have --build-project as this corresponds to
the .sln file name in Visual Studio builds.  The --build-target
option can be added in addition to it.

Thanks,
-Brad



0001-Add-support-for-idlj-and-jarsigner-tools.patch
Description: 0001-Add-support-for-idlj-and-jarsigner-tools.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

New version of patches taking into account Brad’ remarks.

Marc




On 29/07/15 15:47, Brad King brad.k...@kitware.com wrote:

On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote:
 here is an updated list of patches.

Great.

find_package_handle_standard_args(Java
  REQUIRED_VARS Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE 
 Java_JAVAC_EXECUTABLE
Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE
 +  Java_IDLJ_EXECUTABLE Java_JARSIGNER_EXECUTABLE
  VERSION_VAR Java_VERSION
  )

Are idlj and jarsigner reliably available whenever the other tools are?
Even for older versions?  Do these need to be REQUIRED_VARS?  I'm
concerned this could make a case that previously found java not report
it found anymore.

 -  --build-project hello
 +  --build-target hello

The tests should still have --build-project as this corresponds to
the .sln file name in Visual Studio builds.  The --build-target
option can be added in addition to it.

Thanks,
-Brad



0001-Add-support-for-idlj-and-jarsigner-tools.patch
Description: 0001-Add-support-for-idlj-and-jarsigner-tools.patch


0002-add_jar-now-supports-file-syntax-for-sources.patch
Description: 0002-add_jar-now-supports-file-syntax-for-sources.patch


0003-install_jar-add-options-DESTINATION-and-COMPONENT.patch
Description: 0003-install_jar-add-options-DESTINATION-and-COMPONENT.patch


0004-Add-support-for-javah-tool.patch
Description: 0004-Add-support-for-javah-tool.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

Hi,

You are right. @ must be matching at the beginning of the item. But I need .* 
in the expression because I use regex matching group to retrieve filename.

Anyway, here is an updated list of patches.

Marc




On 29/07/15 09:25, cmake-developers on behalf of Rolf Eike Beer 
cmake-developers-boun...@cmake.org on behalf of e...@sf-mail.de wrote:

Am Dienstag, 28. Juli 2015, 08:15:01 schrieb CHEVRIER, Marc:
 Hi,
 
 0002 (UseJava.cmake): Extends add_jar command to support @file syntax for
 java sources specification.

You do not need leading or trailing .* in regular expressions. In fact I think 
your expression should simply be ^@, otherwise you would match an @ at any 
position in the argument name, which does not look intended.

Greetings,

Eike


0001-Add-support-for-idlj-and-jarsigner-tools.patch
Description: 0001-Add-support-for-idlj-and-jarsigner-tools.patch


0002-add_jar-now-supports-file-syntax-for-sources.patch
Description: 0002-add_jar-now-supports-file-syntax-for-sources.patch


0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch
Description: 0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch


0004-Add-support-for-javah-tool.patch
Description: 0004-Add-support-for-javah-tool.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Java support

[CHEVRIER, Marc]

Thanks for your comments.
To address your first remark, I propose to introduce a new component (‘Extra', 
for example) to manage these new tools.
For example: find_package (Java COMPONENTS Development Extra)
I think it is better than removing new variables as required because this 
approach will require some explicit check to ensure these tools are found 
before usage.

Regarding your second remark, I will update my patches.

Marc



On 29/07/15 15:47, Brad King brad.k...@kitware.com wrote:

On 07/29/2015 04:01 AM, CHEVRIER, Marc wrote:
 here is an updated list of patches.

Great.

find_package_handle_standard_args(Java
  REQUIRED_VARS Java_JAVA_EXECUTABLE Java_JAR_EXECUTABLE 
 Java_JAVAC_EXECUTABLE
Java_JAVAH_EXECUTABLE Java_JAVADOC_EXECUTABLE
 +  Java_IDLJ_EXECUTABLE Java_JARSIGNER_EXECUTABLE
  VERSION_VAR Java_VERSION
  )

Are idlj and jarsigner reliably available whenever the other tools are?
Even for older versions?  Do these need to be REQUIRED_VARS?  I'm
concerned this could make a case that previously found java not report
it found anymore.

 -  --build-project hello
 +  --build-target hello

The tests should still have --build-project as this corresponds to
the .sln file name in Visual Studio builds.  The --build-target
option can be added in addition to it.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Java support

[CHEVRIER, Marc]

Hi,

Here are some patches to enhance Java support.
0001 (FindJava.cmake): Defines now two new variables for idlj and jar signer 
tools: Java_IDLJ_EXECUTABLE and Java_JARSIGNER_EXECUTABLE
0002 (UseJava.cmake): Extends add_jar command to support @file syntax for java 
sources specification.
0003 (UseJava.cmake): Extends install_jar and install_jni_symlink commands to 
support options DESTINATION and COMPONENT as alternative to actual syntax.
0004 (UseJava.cmake): Add new command create_javah to wrap java tool javah.

I also extends tests to support these extensions.

This is my first contribution, so be indulgent if something is wrong… ;)

Marc Chevrier



0001-Add-support-for-idlj-and-jarsigner-tools.patch
Description: 0001-Add-support-for-idlj-and-jarsigner-tools.patch


0002-add_jar-now-supports-file-syntax-for-sources.patch
Description: 0002-add_jar-now-supports-file-syntax-for-sources.patch


0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch
Description: 0003-install_jar-Add-options-DESTINATION-and-COMPONENT.patch


0004-Add-support-for-javah-tool.patch
Description: 0004-Add-support-for-javah-tool.patch
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Setting install dir based on Debug or Release

[CHEVRIER, Marc]

Multi-configurations is a bit complex to handle regarding install directories 
but it is doable.

Here is my solution:

  1.  Handle various possibilities (multi-configs or mono-config). In case of 
multi-config, you have to rely on variable CMAKE_CFG_INTDIR which be contains 
information enabling to instantiate the current configuration at runtime. I 
also force definition of a default config (Debug) if none is specified (in case 
of mono config) to avoid bad behaviours.

if (DEFINED CMAKE_CONFIGURATION_TYPES)
  # multi-config handling
  set (CMAKE_BUILD_CONFIG \${BUILD_TYPE})
  set (CMAKE_CFG_BUILD_CONFIG ${CMAKE_CFG_INTDIR})
else()
  # mono config handling
  if (CMAKE_BUILD_TYPE)
set (CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING Choose the type of 
build, options are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release 
RelWithDebInfo MinSizeRel FORCE)
  else()
set (CMAKE_BUILD_TYPE Debug CACHE STRING Choose the type of build, options 
are: None(CMAKE_CXX_FLAGS or CMAKE_C_FLAGS used) Debug Release RelWithDebInfo 
MinSizeRel FORCE)
  endif()
  set (CMAKE_BUILD_CONFIG ${CMAKE_BUILD_TYPE})
  set (CMAKE_CFG_BUILD_CONFIG ${CMAKE_BUILD_TYPE})
endif()

2. Now you can use variables CMAKE_BUILD_CONFIG or CMAKE_CFG_BUILD_CONFIG  to 
define your install prefix. There is two different variables because depending 
of the context of use, one or the other must be used. Here is an example:
add_custom_command (OUTPUT 
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_CFG_BUILD_CONFIG}/output_file
COMMAND ${CMAKE_COMMAND} -DBUILD_TYPE=$CONFIG -P 
script.cmake
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
COMMENT Generating output_file)

OUTPUT parameter does not support generator expressions so pattern $CONFIG 
cannot be used. You have to rely on CMAKE_CFG_INTDIR in case of multi-config 
but on CMAKE_BUILD_TYPE for mono-config. So use wrapper CMAKE_CFG_BUILD_CONFIG.

install (FILES ${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_BUILD_CONFIG}/output_file 
DESTINATION ${CMAKE_BUILD_CONFIG})

In case of install command, CMAKE_CFG_INTDIR must not be used in multi-config… 
So use wrapper CMAKE_BUILD_CONFIG.

This is why I have two different variables!

Hope this is helpful.

Marc

From: CMake on behalf of Scott Aron Bloom
Date: Tuesday 19 May 2015 19:42
To: cmake@cmake.orgmailto:cmake@cmake.org
Subject: [CMake] Setting install dir based on Debug or Release

We use the install system, and love it.

However, since our install include copies of 3rd party debug libraries that are 
named the same as the release counterparts (not our call ;() I would like to 
just have a the path be install.deb rather than “install”
We set the CMAKE_INSTLL_PREFIX variable, but all the configurations get set to 
the same install…

The problem I see, is the code only gets executed once, and at that point the 
CMAKE_BUILD_TYPE isn’t set yet..  Yes I realize this for windows, so it is a 
multi-config system.. but I cant believe Im the only one with this issue.

This is is what Im trying…

IF( ${CMAKE_BUILD_TYPE} STREQUAL RelWithDebInfo)
SET(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/Install)
message( STATUS CMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX} )
ELSEIF( ${CMAKE_BUILD_TYPE} STREQUAL Debug)
SET(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/Install.deb)
message( STATUS CMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX} )
ELSE()
MESSAGE( STATUS CMAKE_BUILD_TYPE not set yet ${CMAKE_BUILD_TYPE} )
ENDIF()


Any help would be most appreciated
Thanks

Scott
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] How URL_MD5 is computed in ExternalProject_Add?

[CHEVRIER, Marc]

You can use FILE (MD5 file variable) command to compute MD5 value.

From: CMake on behalf of Cedric Doucet
Date: Tuesday 19 May 2015 13:14
To: cmake@cmake.orgmailto:cmake@cmake.org
Subject: Re: [CMake] How URL_MD5 is computed in ExternalProject_Add?


I managed to obtain the same MD5 code by running the md5sum command on the 
downloaded file.
However, I would like to write an automatic way of downloading third-party 
libraries.
Is it possible to let CMake compute the MD5 of the downloaded file?

Cédric




De: Cedric Doucet cedric.dou...@inria.frmailto:cedric.dou...@inria.fr
À: cmake@cmake.orgmailto:cmake@cmake.org
Envoyé: Mardi 19 Mai 2015 12:37:03
Objet: [CMake] How URL_MD5 is computed in ExternalProject_Add?

Hello,

I use the URL_MD5 variable to avoid downloading more than once a library with 
the ExternalProject_Add command.
However, I don't manage to get the same MD5 code as CMake when I try to get one 
with generators available on the internet.

How could I get the same one for an URL written in the form 
http://www.mywebsite.myext/mypath/myfile?
I have already tried the MD5 of the URL and of myfile but I don't get the same 
MD5 as CMake.

Thanks!

Cédric

--

Powered by www.kitware.com

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

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

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

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

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

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Alias of imported target

[CHEVRIER, Marc]

My need is the following:
I have two imported targets, let say, IMPORTED::TARGET and 
IMPORTED::STATIC::TARGET


And I have a project which can be customised, through an option, by selecting 
which imported target will be used (shared or static).

So I tried, at first place:
if (USE_IMPORTED_STATIC)
  add_library (MY_IMPORTED_TARGET ALIAS IMPORTED::STATIC::TARGET)
else()
  add_library (MY_IMPORTED_TARGET ALIAS IMPORTED::TARGET)
endif()

So, after, I do not longer take care of which imported target is selected!

For now, I rely on a variable storing selected imported target but it is, by 
far, less elegant and coherent with target handling.

On 05/05/15 19:01, Stephen Kelly steve...@gmail.com wrote:

CHEVRIER, Marc wrote:

 
 Hi,
 
 Currently it is not possible to create an alias target for an imported
 target (I.e. add_library with ALIAS keyword). But I don’t understand what
 is the technical constraint or semantic reason behind this limitation. If
 anybody can explain this limitation, it will be nice.

It was designed with as many restrictions as I could think of (everything 
which was not part of the need to add it at all):

 http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=370bf554

The restrictions are there because they are easy to lift later when a need 
arises without breaking user code. It also means that design considerations 
which were not known or understood two years ago can be considered in 
designing new interfaces.

Do you have a need for ALIAS IMPORTED libraries? Can you describe it?

Thanks,

Steve.


-- 

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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

[CMake] Alias of imported target

[CHEVRIER, Marc]

Hi,

Currently it is not possible to create an alias target for an imported target 
(I.e. add_library with ALIAS keyword). But I don’t understand what is the 
technical constraint or semantic reason behind this limitation.
If anybody can explain this limitation, it will be nice.


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] [cmake-developers] Identify used source files

[CHEVRIER, Marc]

May be more clean and efficient to use CMake property SOURCES:
For example:
add_library (MY_LIB src1.cpp src2.cpp)
get_target_property (lib_sources MY_LIB SOURCES)

And variable lib_sources now contains list of sources associated with target.






On 28/04/15 10:30, Roman Wüger roman.wue...@gmx.at wrote:

If someone is interessted in this solution:

 
set(FilenameUsedFiles ${CMAKE_BINARY_DIR}/UsedFiles.lst)
file(WRITE ${FilenameUsedFiles} )
 
function (parseArguments)
set(options)
set(oneValueArgs)
set(multiValueArgs)
cmake_parse_arguments(CFG ${options}${oneValueArgs} 
 ${multiValueArgs}${ARGN} )
 
foreach(file ${ARGN})
get_filename_component(tempPath ${file} DIRECTORY)
string(FIND ${file} ${CMAKE_BINARY_DIR}buildPathFoundPos)
string(FIND ${file} ${CMAKE_SOURCE_DIR}sourcePathFoundPos)
 
if ((NOT ${file} STREQUALIMPORTED) AND
(NOT ${file} STREQUAL MODULE)AND
(NOT ${file} STREQUAL STATIC)AND
(NOT ${file} STREQUAL SHARED)AND
(NOT ${file} STREQUAL WIN32)AND
${buildPathFoundPos} EQUAL -1)
if (${sourcePathFoundPos} EQUAL -1)
file(APPEND ${FilenameUsedFiles} 
 ${CMAKE_CURRENT_SOURCE_DIR}/${file}\n)
else()
file(APPEND ${FilenameUsedFiles} ${file}\n)
endif()
endif()
endforeach()
endfunction(parseArguments)
 
function(add_library name)
  parseArguments(${ARGN})
  _add_library(${name} ${ARGN})
endfunction()
 
function(add_executable name)
  parseArguments(${ARGN})
  _add_executable(${name} ${ARGN})
endfunction()

Best Regards 
Roman

 Am 28.04.2015 um 07:00 schrieb Roman Wüger roman.wue...@gmx.at:
 
 Hello,
 
 is there a proper solution to get all used source files for all defined 
 librarys and executables?
 
 My first idea was to overload the main functions such as add_executable() 
 and add_library() temporarily in the main CMakeLists.txt and write a text 
 file or whatever, but I thought there were a better way.
 
 Did anybody know a better way?
 
 Maybe CMake has a way to get a list of used files?
 
 The reason is to clean a big old source tree.
 
 Thanks in advance
 
 Best regards
 Roman
 -- 
 
 Powered by www.kitware.com
 
 Please keep messages on-topic and check the CMake FAQ at: 
 http://www.cmake.org/Wiki/CMake_FAQ
 
 Kitware offers various services to support the CMake community. For more 
 information on each offering, please visit:
 
 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html
 
 Visit other Kitware open-source projects at 
 http://www.kitware.com/opensource/opensource.html
 
 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

Powered by www.kitware.com

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

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

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

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

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