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

[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

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

[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

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

[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

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

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