Re: [CMake] 3.4.1 installer overwrites Windows PATH system var

[Vasily Vladimirovich Vylkov]

Thanks all -- that worked.  The key:
  regedit.exe --> HKLM\SYSTEM\ControlSet001\Control\Environment\Path

had a backup of the path var before the CMake install nuked it.


> How long was your PATH before?

Just my luck, it was 1028 chars long (just 4 over the threshold).



> The installer is produced with NSIS.

Is there a bug filed with NSIS to address this?  Also, there should be
a very prominent warning about this on the CMake download/install page
next to the Windows installer.  Extremely unpleasant from a user
perspective.

On Thu, Dec 3, 2015 at 10:02 AM, Tamás Kenéz  wrote:
> about recovering the path see
> http://superuser.com/questions/523688/deleted-path-environment-variable-how-to-restore
>
> On Thursday, December 3, 2015, Brad King  wrote:
>>
>> On 12/03/2015 11:04 AM, Vasily Vladimirovich Vylkov wrote:
>> > Installing CMake on Windows (7, 64-bit) with the "add cmake to system
>> > PATH for all users" option overwrote the contents of my PATH variable,
>> > instead of appending to it.  This is horrible!  I don't know of any
>> > way to recover my previous PATH value.
>> >
>> > It also looks like this has been an issue in several previous versions:
>> >   * https://cmake.org/Bug/view.php?id=10257
>> >   * https://cmake.org/Bug/view.php?id=12875
>> >
>> > Shouldn't there be a regression / sanity test case for this prior to
>> > publishing a new version of the installer?
>>
>> For every new release binary we run the installer by hand to verify
>> that the interaction works.  This doesn't happen to us.
>>
>> The installer is produced with NSIS.  I wonder if this is a case of:
>>
>>
>> http://stackoverflow.com/questions/21897103/nsis-envvarupdate-overwrites-system-path-when-path-is-too-long-is-there-a-wor
>>
>> How long was your PATH before?
>>
>> -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
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] 3.4.1 installer overwrites Windows PATH system var

[Vasily Vladimirovich Vylkov]

> For every new release binary we run the installer by hand
> to verify that the interaction works.  This doesn't happen to us.


Do you run it on a machine with PATH set to a string >1024 chars long?
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, master, updated. v3.4.1-615-g7410e2e

[Kitware Robot]

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

The branch, master has been updated
   via  7410e2ed61851385d0c06dd174a4782a54c44ab0 (commit)
  from  4ffeab0e3c451854a4a9d424b47b2179c6cf6c6b (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7410e2ed61851385d0c06dd174a4782a54c44ab0
commit 7410e2ed61851385d0c06dd174a4782a54c44ab0
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Dec 4 00:01:09 2015 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Dec 4 00:01:09 2015 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 141015d..81d33c2 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 4)
-set(CMake_VERSION_PATCH 20151203)
+set(CMake_VERSION_PATCH 20151204)
 #set(CMake_VERSION_RC 1)

---

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


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

Re: [cmake-developers] Fw: Please comment on ios-universal topic

[Bartosz Kosiorek]

Hello Ruslan

The Android supports both Universal Apk and Multi Apk.
 
https://androidbycode.wordpress.com/2015/07/07/android-ndk-a-guide-to-deploying-apps-with-native-libraries/
 
 http://developer.android.com/google/play/publishing/multiple-apks.html

It is necessary for deploy applications which support both armv7 (32bit) and 
armv8 (64bit).
There is also Intel's implementation of Android (x86)
All supported architectures you could found at:
   http://developer.android.com/ndk/guides/abis.html

It is possible to create universal library for Linux (FatElf), but it is not 
widely used:
http://stackoverflow.com/questions/10167821/why-are-universal-binaries-fatelf-not-part-of-linux-kernel

I don't know how it works with Universal Windows Platform:
https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx
https://msdn.microsoft.com/en-us/library/mt186162.aspx
But I suspect that it will be similar.

Best Regards
Bartosz


From: Ruslan Baratov 
Sent: Thursday, December 3, 2015 11:06 AM
To: Bartosz Kosiorek
Cc: Gregor Jasny; cmake-developers@cmake.org
Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic

On 03-Dec-15 14:57, Bartosz Kosiorek wrote:
> Thanks Ruslan for feedback.
>
> I think that this new property should work also for FRAMEWORK and should 
> support both OSX and iOS
> In that way it is already done for:
>   -  for SHARED library adding FRAMEWORK property produce correct Framework 
> for iOS or OSX (for Cmake 3.5 the documentation was already updated), and 
> standard library for other platforms
>   - for MACOSX_BUNDLE (the name of property is very confusing). It will 
> produce BUNDLE for OSX or iOS.
>   - even standard SHARED library produce different results according to 
> platform (.so file on Linux, .dll on Windows, .dylib on OSX)
>
> I strongly believe that this new CMake's property should follow this 
> convention.
>
> Currently I'm working in project which must support multiple platforms 
> (Linux, Windows, OSX, iOS, Android, QNX etc.).
> And I very like CMake for automagicaly adopting to platform/architecture/OS.
>
> Because "Universal Library" is generic name, which is applicable for all 
> platforms (Fat library is used on Apple machines),
> I would like to propose following  property name:
>  INSTALL_UNIVERSAL_LIBRARY
>
> For now it will be applicable only on iOS (OS X?), but it could be extended 
> to other platforms (Android).
> Of course all supported platforms should be noticed in documentation.
>
> What do you think about that idea:
> Adding one property which will adopt to platform on which is build?
Actually it make sense to me. We just need to add a note to the
documentation that only Xcode + iOS libs supported for now and add new
types/platforms in future.

By the way does any other platform except Apple's OSX and iOS support
fat libraries? You've mentioned Android (?) I've found this link about
Linux:
https://en.wikipedia.org/wiki/Fat_binary#FatELF:_Universal_Binaries_for_Linux
(quote: `developer Ryan Gordon declared FatELF to be dead`)

Ruslo

>
>
> Best Regards
> Bartosz
>
> 
> From: Ruslan Baratov 
> Sent: Thursday, December 3, 2015 4:09 AM
> To: Bartosz Kosiorek
> Cc: Gregor Jasny; cmake-developers@cmake.org
> Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic
>
> On 02-Dec-15 19:44, Bartosz Kosiorek wrote:
>> Hi.
>>
>> Currently we already support similar target properties:
>> - INSTALL_NAME_DIR
>> - INSTALL_RPATH
>> - INSTALL_RPATH_USE_LINK_PATH
>>
>> It will be great to follow the same name convention.
>>
>> Because this new property is only applicable for INSTALL step, I would like 
>> to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS.
>>
>> What do you think about that idea?
> It's hard for me to decide what is better because
> IOS_INSTALL_UNIVERSAL_LIBS just came from my mind and I've used it for a
> while already. So now it looks solid for no reason :)
>
> However first note:
> INSTALL_RPATH can be read as when we do INSTALL change RPATH to ...
> (any platform)
> ANDROID_API -//- when we are on ANDROID use next API ...
> WIN32_EXECUTABLE -//- when we are on WIN32 use bla-bla for EXECUTABLE
> OSX_ARCHITECTURES -//- when we are on OSX use ARCHITECTURES
> MACOSX_BUNDLE -//- when we are on MACOSX create BUNDLE
>
> So new property can be read as:
> IOS_INSTALL_UNIVERSAL_LIBS when we are on IOS do INSTALL_UNIVERSAL_LIBS
> INSTALL_IOS_UNIVERSAL_LIBS when we do INSTALL make IOS_UNIVERSAL_LIBS
> (does it mean that when we are on Linux we can install iOS libs? does it
> mean that when we are on OSX without iOS toolchain we can do iOS libs?)
>
> Second note is about future improvements of this feature, installing
> universal libs on OSX or installing universal frameworks, pattern
> _INSTALL_UNIVERSAL_:
>
>  IOS_INSTALL_UNIVERSAL_LIBS
>  

Re: [cmake-developers] Fw: Please comment on ios-universal topic

[Bartosz Kosiorek]

Hi again.

I get through link:
https://en.wikipedia.org/wiki/Fat_binary

and I think it will be better to name this property:
   INSTALL_UNIVERSAL_BINARY

Later such property name could be used also for Executables/Bundles etc.
And the result for both Libraries and Executables will be the same.

Best Regads
Bartosz



From: Bartosz Kosiorek
Sent: Thursday, December 3, 2015 12:45 PM
To: Ruslan Baratov
Cc: Gregor Jasny; cmake-developers@cmake.org
Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic

Hello Ruslan

The Android supports both Universal Apk and Multi Apk.
 
https://androidbycode.wordpress.com/2015/07/07/android-ndk-a-guide-to-deploying-apps-with-native-libraries/
 http://developer.android.com/google/play/publishing/multiple-apks.html

It is necessary for deploy applications which support both armv7 (32bit) and 
armv8 (64bit).
There is also Intel's implementation of Android (x86)
All supported architectures you could found at:
   http://developer.android.com/ndk/guides/abis.html

It is possible to create universal library for Linux (FatElf), but it is not 
widely used:
http://stackoverflow.com/questions/10167821/why-are-universal-binaries-fatelf-not-part-of-linux-kernel

I don't know how it works with Universal Windows Platform:
https://msdn.microsoft.com/en-us/library/windows/apps/dn894631.aspx
https://msdn.microsoft.com/en-us/library/mt186162.aspx
But I suspect that it will be similar.

Best Regards
Bartosz


From: Ruslan Baratov 
Sent: Thursday, December 3, 2015 11:06 AM
To: Bartosz Kosiorek
Cc: Gregor Jasny; cmake-developers@cmake.org
Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic

On 03-Dec-15 14:57, Bartosz Kosiorek wrote:
> Thanks Ruslan for feedback.
>
> I think that this new property should work also for FRAMEWORK and should 
> support both OSX and iOS
> In that way it is already done for:
>   -  for SHARED library adding FRAMEWORK property produce correct Framework 
> for iOS or OSX (for Cmake 3.5 the documentation was already updated), and 
> standard library for other platforms
>   - for MACOSX_BUNDLE (the name of property is very confusing). It will 
> produce BUNDLE for OSX or iOS.
>   - even standard SHARED library produce different results according to 
> platform (.so file on Linux, .dll on Windows, .dylib on OSX)
>
> I strongly believe that this new CMake's property should follow this 
> convention.
>
> Currently I'm working in project which must support multiple platforms 
> (Linux, Windows, OSX, iOS, Android, QNX etc.).
> And I very like CMake for automagicaly adopting to platform/architecture/OS.
>
> Because "Universal Library" is generic name, which is applicable for all 
> platforms (Fat library is used on Apple machines),
> I would like to propose following  property name:
>  INSTALL_UNIVERSAL_LIBRARY
>
> For now it will be applicable only on iOS (OS X?), but it could be extended 
> to other platforms (Android).
> Of course all supported platforms should be noticed in documentation.
>
> What do you think about that idea:
> Adding one property which will adopt to platform on which is build?
Actually it make sense to me. We just need to add a note to the
documentation that only Xcode + iOS libs supported for now and add new
types/platforms in future.

By the way does any other platform except Apple's OSX and iOS support
fat libraries? You've mentioned Android (?) I've found this link about
Linux:
https://en.wikipedia.org/wiki/Fat_binary#FatELF:_Universal_Binaries_for_Linux
(quote: `developer Ryan Gordon declared FatELF to be dead`)

Ruslo

>
>
> Best Regards
> Bartosz
>
> 
> From: Ruslan Baratov 
> Sent: Thursday, December 3, 2015 4:09 AM
> To: Bartosz Kosiorek
> Cc: Gregor Jasny; cmake-developers@cmake.org
> Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic
>
> On 02-Dec-15 19:44, Bartosz Kosiorek wrote:
>> Hi.
>>
>> Currently we already support similar target properties:
>> - INSTALL_NAME_DIR
>> - INSTALL_RPATH
>> - INSTALL_RPATH_USE_LINK_PATH
>>
>> It will be great to follow the same name convention.
>>
>> Because this new property is only applicable for INSTALL step, I would like 
>> to propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS.
>>
>> What do you think about that idea?
> It's hard for me to decide what is better because
> IOS_INSTALL_UNIVERSAL_LIBS just came from my mind and I've used it for a
> while already. So now it looks solid for no reason :)
>
> However first note:
> INSTALL_RPATH can be read as when we do INSTALL change RPATH to ...
> (any platform)
> ANDROID_API -//- when we are on ANDROID use next API ...
> WIN32_EXECUTABLE -//- when we are on WIN32 use bla-bla for EXECUTABLE
> OSX_ARCHITECTURES -//- when we are on OSX use ARCHITECTURES
> MACOSX_BUNDLE -//- when we are on MACOSX 

Re: [CMake] generator expression for set_target_properties

[Lloyd]

I mean the latter, changing the build type in ide

On Thu, Dec 3, 2015 at 1:15 PM, Attila Krasznahorkay <
attila.krasznahor...@gmail.com> wrote:

> Hi Lloyd,
>
> You mean like:
>
> if( ${CMAKE_BUILD_TYPE} STREQUAL "Release" )
>set_target_properties( myexec PROPERTIES WIN32_EXECUTABLE TRUE )
> endif()
>
> ?
>
> Or would you like the build configuration to change in this respect when
> you change the build type in the IDE? This latter may not be possible to
> do. But others may very well correct me.
>
> Cheers,
> Attila
>
> > On 03 Dec 2015, at 07:32, Lloyd  wrote:
> >
> > Hi,
> >
> > We have a cmake file for Qt project. We want to hide the console from
> release build. For that we are using
> >
> > ADD_EXECUTABLE(myexec ${MYEXEC_SRC} )
> > SET_TARGET_PROPERTIES(myexec PROPERTIES WIN32_EXECUTABLE true)
> >
> > Is it possible for me to set this property only for the release build?
> >
> > I am using cmake 2.8, Windows 7, VS 2013
> >
> > Thanks,
> >   Lloyd
> > --
> >
> > Powered by www.kitware.com
> >
> > Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
> >
> > Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
> >
> > CMake Support: http://cmake.org/cmake/help/support.html
> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
> > CMake Training Courses: http://cmake.org/cmake/help/training.html
> >
> > Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/cmake
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Fw: Please comment on ios-universal topic

[Ruslan Baratov via cmake-developers]

On 03-Dec-15 14:57, Bartosz Kosiorek wrote:

Thanks Ruslan for feedback.

I think that this new property should work also for FRAMEWORK and should 
support both OSX and iOS
In that way it is already done for:
  -  for SHARED library adding FRAMEWORK property produce correct Framework for 
iOS or OSX (for Cmake 3.5 the documentation was already updated), and standard 
library for other platforms
  - for MACOSX_BUNDLE (the name of property is very confusing). It will produce 
BUNDLE for OSX or iOS.
  - even standard SHARED library produce different results according to 
platform (.so file on Linux, .dll on Windows, .dylib on OSX)

I strongly believe that this new CMake's property should follow this convention.

Currently I'm working in project which must support multiple platforms (Linux, 
Windows, OSX, iOS, Android, QNX etc.).
And I very like CMake for automagicaly adopting to platform/architecture/OS.

Because "Universal Library" is generic name, which is applicable for all 
platforms (Fat library is used on Apple machines),
I would like to propose following  property name:
 INSTALL_UNIVERSAL_LIBRARY

For now it will be applicable only on iOS (OS X?), but it could be extended to 
other platforms (Android).
Of course all supported platforms should be noticed in documentation.

What do you think about that idea:
Adding one property which will adopt to platform on which is build?
Actually it make sense to me. We just need to add a note to the 
documentation that only Xcode + iOS libs supported for now and add new 
types/platforms in future.


By the way does any other platform except Apple's OSX and iOS support 
fat libraries? You've mentioned Android (?) I've found this link about 
Linux: 
https://en.wikipedia.org/wiki/Fat_binary#FatELF:_Universal_Binaries_for_Linux 
(quote: `developer Ryan Gordon declared FatELF to be dead`)


Ruslo




Best Regards
Bartosz


From: Ruslan Baratov 
Sent: Thursday, December 3, 2015 4:09 AM
To: Bartosz Kosiorek
Cc: Gregor Jasny; cmake-developers@cmake.org
Subject: Re: Fw: [cmake-developers] Please comment on ios-universal topic

On 02-Dec-15 19:44, Bartosz Kosiorek wrote:

Hi.

Currently we already support similar target properties:
- INSTALL_NAME_DIR
- INSTALL_RPATH
- INSTALL_RPATH_USE_LINK_PATH

It will be great to follow the same name convention.

Because this new property is only applicable for INSTALL step, I would like to 
propose to rename property name to INSTALL_IOS_UNIVERSAL_LIBS.

What do you think about that idea?

It's hard for me to decide what is better because
IOS_INSTALL_UNIVERSAL_LIBS just came from my mind and I've used it for a
while already. So now it looks solid for no reason :)

However first note:
INSTALL_RPATH can be read as when we do INSTALL change RPATH to ...
(any platform)
ANDROID_API -//- when we are on ANDROID use next API ...
WIN32_EXECUTABLE -//- when we are on WIN32 use bla-bla for EXECUTABLE
OSX_ARCHITECTURES -//- when we are on OSX use ARCHITECTURES
MACOSX_BUNDLE -//- when we are on MACOSX create BUNDLE

So new property can be read as:
IOS_INSTALL_UNIVERSAL_LIBS when we are on IOS do INSTALL_UNIVERSAL_LIBS
INSTALL_IOS_UNIVERSAL_LIBS when we do INSTALL make IOS_UNIVERSAL_LIBS
(does it mean that when we are on Linux we can install iOS libs? does it
mean that when we are on OSX without iOS toolchain we can do iOS libs?)

Second note is about future improvements of this feature, installing
universal libs on OSX or installing universal frameworks, pattern
_INSTALL_UNIVERSAL_:

 IOS_INSTALL_UNIVERSAL_LIBS
 IOS_INSTALL_UNIVERSAL_FRAMEWORKS

OSX_INSTALL_UNIVERSAL_LIBS
OSX_INSTALL_UNIVERSAL_FRAMEWORKS

INSTALL_UNIVERSAL_LIBS # on both OSX and iOS
INSTALL_UNIVERSAL_FRAMEWORKS # on both OSX and iOS

IOS_INSTALL_UNIVERSAL # both libs and frameworks
OSX_INSTALL_UNIVERSAL # both libs and frameworks

INSTALL_UNIVERSAL # both libs and frameworks, both OSX and iOS

?

Ruslo


From: cmake-developers  on behalf of Gregor Jasny 
via cmake-developers 
Sent: Tuesday, December 1, 2015 3:22 PM
To: CMake Developers; Ruslan Baratov
Subject: [cmake-developers] Please comment on ios-universal topic

Hello,

During the last days I worked on the iOS Universal Install topic which
now would benefit from a review. Especially the core changes could need
a third pair of eyes:

https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=8fb23b42cfc2fb7490e8645fff328add9c231713

I will now concentrate on adding more tests during the next days.

Thank you,
Gregor

--

Powered by www.kitware.com

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

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

CMake Support: 

Re: [CMake] Best way to handle application data path for local run vs. installation

[Johannes Zarl-Zierl]

> > I.e. it could be replaced with a string of the same length or a
> > shorter one, but not a longer one.
> > 
> > CMake works around this by extending the build RPATH artificially with
> > ":" at the end I think, patchelf works around this by making the whole
> > executable one page bigger if the new entry is longer.
> 
> Just an implementation notes, doesn't change the fact that it can be
> done and it's designed to be modifiable.

This is only nitpicking about a side-topic, but: Just because it can be done 
does not mean that it was designed for that purpose.
You argument is like saying that a wrench was designed to be used as a hammer 
(after all, you can hit a nail with it).

If one were to follow that argument, it would be very hard *not* to design 
something for a given purpose.

> > If RPATH was _designed_ to be patchable, tools could just do it,
> > instead of having to implement workarounds for longer strings. E.g.
> > the linker would support a command line argument how much space it
> > should reserve for the RPATH entry, or something like that.
> 
> I think it's not possible. As far as I know there is no limitation for
> path size on Linux for example. Hence it's not possible to predict what
> size for path to library user want to use by setting RPATH.

If RPATH were *designed* to be modifiable, it would need provisions to account 
for arbitrary path lengths.
One possible solution (not necessarily the best, or even a good one) would be 
to make RPATH a fixed-length field, part of which is a pointer to the next 
entry, if any.

Regards,
  Johannes
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Ruslan Baratov via CMake]

On 03-Dec-15 16:59, Johannes Zarl-Zierl wrote:

I.e. it could be replaced with a string of the same length or a
shorter one, but not a longer one.

CMake works around this by extending the build RPATH artificially with
":" at the end I think, patchelf works around this by making the whole
executable one page bigger if the new entry is longer.

Just an implementation notes, doesn't change the fact that it can be
done and it's designed to be modifiable.

This is only nitpicking about a side-topic, but: Just because it can be done
does not mean that it was designed for that purpose.
If it succeed it doesn't break the things. And for every C++ string 
changing trick can be created counter-example (yes, synthetic, but 
anyway) that violates logic or even crash an application. At least in 
the form how I see it will be implemented.



You argument is like saying that a wrench was designed to be used as a hammer
(after all, you can hit a nail with it).
I've never seen manual to the wrench but if one exists I doubt there is 
a section "how to hit a nail with wrench". But I see chrpath tool on 
Linux and install_name_tool on OSX.


Will you be okay if I change "designed" to "can be done correctly"?

Ruslo
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

[Taylor Braun-Jones]

Perhaps the Paris Climate talks would be good inspiration for tackling
this feature. How many pounds of CO2 are emitted each year due to
needless header compilation CPU cycles? :-)

On Fri, Oct 30, 2015 at 1:48 AM, James Johnston
 wrote:
>> -Original Message-
>
>> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
>
>> On Behalf Of Daniel Pfeifer
>
>> Sent: Wednesday, October 28, 2015 08:57
>
>> To: Taylor Braun-Jones
>
>> Cc: CMake Developers
>
>> Subject: Re: [cmake-developers] RFC: CMake precompiled header support
>
>> and custom compiler based implementation
>
>>
>
>> On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones 
>> jones.org> wrote:
>
>> > What's the status of this PCH feature? Does it need testers? More
>
>> > design input? I'd love to see this feature in a future CMake release.
>
>> > Willing to help.
>
>>
>
>> I haven't worked on it for quite some time as I currently don't have a
>
> project
>
>> which needs it.
>
>> But I agree that we should get it into CMake, even if it does not
>
>> support
>
> all
>
>> generators yet.
>
>> Support for additional generators can be added successively.
>
>>
>
>> I will rebase my branch to master on the weekend, ie port it to
>
>> cmGeneratorTarget.
>
>> Then you are free to help with review, testing, and additional generators.
>
>>
>
>> Which generators are the most important for you?
>
>
>
> I'd also love to see some progress on PCH support, though I haven't had much
> time recently... I'd be quite happy to test however with the below compilers
> and generators - all of which we would use PCH support with:
>
>
>
> Generators:
>
>
>
> * Ninja
>
> * Visual Studio 2008 (eventually 2015)
>
> * Although we're not currently using it, CMake would be pretty broken
> without supporting: Unix Makefiles
>
>
>
> Compilers:
>
>
>
> * Visual C++ 2008 (eventually 2015): both Ninja and VS generators
>
> * Embarcadero bcc32 compiler: Ninja
>
> * GCC: Ninja
>
>
>
> Best regards,
>
>
>
> James Johnston
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1572-g4d1d9c6

[Brad King]

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

The branch, next has been updated
   via  4d1d9c62c5bb26fdf202e6fa5f302bee254ab77c (commit)
   via  56c11eee13604e163eb5a5d9092df405be0e9a5c (commit)
  from  d8ac93fff8a91c77294d2c5b062765ebdafdbe1e (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d1d9c62c5bb26fdf202e6fa5f302bee254ab77c
commit 4d1d9c62c5bb26fdf202e6fa5f302bee254ab77c
Merge: d8ac93f 56c11ee
Author: Brad King 
AuthorDate: Thu Dec 3 09:24:54 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 3 09:24:54 2015 -0500

Merge topic 'UseJava-relative-manifest' into next

56c11eee UseJava: Allow relative path to manifest file just as with other 
sources


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56c11eee13604e163eb5a5d9092df405be0e9a5c
commit 56c11eee13604e163eb5a5d9092df405be0e9a5c
Author: Marc Chevrier 
AuthorDate: Thu Dec 3 12:35:37 2015 +0100
Commit: Brad King 
CommitDate: Thu Dec 3 09:24:26 2015 -0500

UseJava: Allow relative path to manifest file just as with other sources

diff --git a/Modules/UseJava.cmake b/Modules/UseJava.cmake
index dced6ec..6146d78 100644
--- a/Modules/UseJava.cmake
+++ b/Modules/UseJava.cmake
@@ -444,7 +444,7 @@ function(add_jar _TARGET_NAME)
 
 if (_add_jar_MANIFEST)
 set(_MANIFEST_OPTION m)
-set(_MANIFEST_VALUE ${_add_jar_MANIFEST})
+get_filename_component (_MANIFEST_VALUE "${_add_jar_MANIFEST}" 
ABSOLUTE)
 endif ()
 
 if (LIBRARY_OUTPUT_PATH)

---

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


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

Re: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files

[Brad King]

On 12/02/2015 07:05 PM, Bartosz Kosiorek wrote:
> This patch allows to use multiple files in commands "copy" and 
> "copy_if_different".

Good, thanks.  Please also extend the Tests/RunCMake/CommandLine test to
cover this these operations.

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] [PATCH] Fix Resource directory structure for iOS Bundles (Framework and Application), update Tests and Help

[Brad King]

On 12/02/2015 04:45 PM, Bartosz Kosiorek wrote:
> Patch in attachment allows to place resources in main Bundle directory
> (iOS specification), instead to always place in Resource directory.
> 
> https://public.kitware.com/Bug/view.php?id=15848

Thanks, applied:

 iOS: Fix framework resource directory layout (#15848)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e76ee2c0

-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] Adding required source files to a custom target

[Attila Krasznahorkay]

Dear All,

Is it possible to add additional source files to an already existing custom 
target?

My project needs to generate a number of "different things", which it does by 
setting up many custom commands. In order to trigger the generation of 
everything, I currently need to set up an inconvenient number of custom targets 
as well. Would it be possible to attach multiple custom commands to an already 
existing custom target?

Unfortunately it's not really an option to only set up the custom target once 
all the custom commands are already configured, and all their outputs are 
already known.

I guess my question is, what property of a custom target I need to append file 
names to? What internal property gets set with the values passed to the SOURCES 
argument of add_custom_target? (That I could then append additional file names 
to.)

Cheers,
   Attila
-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1566-gb0cc082

[Brad King]

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

The branch, next has been updated
   via  b0cc082ad6c6619653afbceca0ac2888d944e9e2 (commit)
   via  e76ee2c006777e268715b39ad71f49e3d18b11a4 (commit)
  from  1c27e7df4e033f981dde15f7731913ffd6750b03 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b0cc082ad6c6619653afbceca0ac2888d944e9e2
commit b0cc082ad6c6619653afbceca0ac2888d944e9e2
Merge: 1c27e7d e76ee2c
Author: Brad King 
AuthorDate: Thu Dec 3 09:06:59 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 3 09:06:59 2015 -0500

Merge topic 'ios-framework-resource-layout' into next

e76ee2c0 iOS: Fix framework resource directory layout (#15848)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e76ee2c006777e268715b39ad71f49e3d18b11a4
commit e76ee2c006777e268715b39ad71f49e3d18b11a4
Author: Bartosz Kosiorek 
AuthorDate: Wed Dec 2 22:34:25 2015 +0100
Commit: Brad King 
CommitDate: Thu Dec 3 08:52:09 2015 -0500

iOS: Fix framework resource directory layout (#15848)

A typical iOS application bundle (also Framework Bundle) contains the
application executable and any resources used by the application (for
instance, the application icon, other images, and localized content) in
the top-level bundle directory.  The same rule applies to Framework
Bundles.

diff --git a/Help/prop_tgt/MACOSX_BUNDLE.rst b/Help/prop_tgt/MACOSX_BUNDLE.rst
index 8d7d914..7cd8046 100644
--- a/Help/prop_tgt/MACOSX_BUNDLE.rst
+++ b/Help/prop_tgt/MACOSX_BUNDLE.rst
@@ -3,7 +3,7 @@ MACOSX_BUNDLE
 
 Build an executable as an Application Bundle on OS X or iOS.
 
-When this property is set to true the executable when built on OS X
+When this property is set to ``TRUE`` the executable when built on OS X
 or iOS will be created as an application bundle.  This makes it
 a GUI executable that can be launched from the Finder.  See the
 :prop_tgt:`MACOSX_FRAMEWORK_INFO_PLIST` target property for information about
diff --git a/Help/prop_tgt/MACOSX_RPATH.rst b/Help/prop_tgt/MACOSX_RPATH.rst
index 41bb8cc..1f9a036 100644
--- a/Help/prop_tgt/MACOSX_RPATH.rst
+++ b/Help/prop_tgt/MACOSX_RPATH.rst
@@ -3,8 +3,8 @@ MACOSX_RPATH
 
 Whether this target on OS X or iOS is located at runtime using rpaths.
 
-When this property is set to true, the directory portion of
-the "install_name" field of this shared library will be ``@rpath``
+When this property is set to ``TRUE``, the directory portion of
+the ``install_name`` field of this shared library will be ``@rpath``
 unless overridden by :prop_tgt:`INSTALL_NAME_DIR`.  This indicates
 the shared library is to be found at runtime using runtime
 paths (rpaths).
@@ -18,6 +18,6 @@ can be controlled by the :prop_tgt:`INSTALL_RPATH` target 
property on
 the target linking to this target.
 
 Policy :policy:`CMP0042` was introduced to change the default value of
-``MACOSX_RPATH`` to ``TRUE.  This is because use of ``@rpath`` is a
+``MACOSX_RPATH`` to ``TRUE``.  This is because use of ``@rpath`` is a
 more flexible and powerful alternative to ``@executable_path`` and
 ``@loader_path``.
diff --git a/Help/prop_tgt/RESOURCE.rst b/Help/prop_tgt/RESOURCE.rst
index 5dad3ea..d837f7b 100644
--- a/Help/prop_tgt/RESOURCE.rst
+++ b/Help/prop_tgt/RESOURCE.rst
@@ -1,11 +1,61 @@
 RESOURCE
 
 
-Specify resource files in a :prop_tgt:`FRAMEWORK` shared library target.
-
-Shared library targets marked with the :prop_tgt:`FRAMEWORK` property generate
-frameworks on OS X, iOS and normal shared libraries on other platforms.
-This property may be set to a list of files to be placed in the
-``Resources`` directory inside the framework folder.  On non-Apple
-platforms these files may be installed using the ``RESOURCE`` option to
-the ``install(TARGETS)`` command.
+Specify resource files in a :prop_tgt:`FRAMEWORK` or :prop_tgt:`BUNDLE`.
+
+Target marked with the :prop_tgt:`FRAMEWORK` or :prop_tgt:`BUNDLE` property
+generate framework or application bundle (both OS X and iOS is supported)
+or normal shared libraries on other platforms.
+This property may be set to a list of files to be placed in the corresponding
+directory (eg. ``Resources`` directory for OS X) inside the bundle.
+On non-Apple platforms these files may be installed using the ``RESOURCE``
+option to the ``install(TARGETS)`` command.
+
+Following example of Application Bundle:
+
+.. code-block:: cmake
+
+  add_executable(ExecutableTarget
+addDemo.c
+resourcefile.txt
+appresourcedir/appres.txt
+  )
+
+  target_link_libraries(ExecutableTarget 

[Cmake-commits] CMake branch, next, updated. v3.4.1-1568-g103203b

[Brad King]

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

The branch, next has been updated
   via  103203b3b0b83c73476f82a2e1bd29bb272a53c6 (commit)
   via  d8b251e2ea84e612dc30a1c9690a8b299aeb30fd (commit)
  from  b0cc082ad6c6619653afbceca0ac2888d944e9e2 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=103203b3b0b83c73476f82a2e1bd29bb272a53c6
commit 103203b3b0b83c73476f82a2e1bd29bb272a53c6
Merge: b0cc082 d8b251e
Author: Brad King 
AuthorDate: Thu Dec 3 09:17:56 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 3 09:17:56 2015 -0500

Merge topic 'fix-java-idlj-jarsigner-typos' into next

d8b251e2 FindJava: Fix typos in IdlJ and JarSigner component implementation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8b251e2ea84e612dc30a1c9690a8b299aeb30fd
commit d8b251e2ea84e612dc30a1c9690a8b299aeb30fd
Author: Marc Chevrier 
AuthorDate: Thu Dec 3 12:34:51 2015 +0100
Commit: Brad King 
CommitDate: Thu Dec 3 09:17:00 2015 -0500

FindJava: Fix typos in IdlJ and JarSigner component implementation

Fix typos introduced by commit v3.4.0-rc1~257^2~2 (FindJava: Add support
for idlj and jarsigner tools, 2015-07-31) to correctly report when these
components are found.

diff --git a/Modules/FindJava.cmake b/Modules/FindJava.cmake
index 9f87997..cc67df6 100644
--- a/Modules/FindJava.cmake
+++ b/Modules/FindJava.cmake
@@ -228,12 +228,12 @@ if(Java_FIND_COMPONENTS)
   endif()
 elseif(component STREQUAL "IdlJ")
   list(APPEND _JAVA_REQUIRED_VARS Java_IDLJ_EXECUTABLE)
-  if(Java_IdlJ_EXECUTABLE)
-set(Java_Extra_FOUND TRUE)
+  if(Java_IDLJ_EXECUTABLE)
+set(Java_IdlJ_FOUND TRUE)
   endif()
 elseif(component STREQUAL "JarSigner")
   list(APPEND _JAVA_REQUIRED_VARS Java_JARSIGNER_EXECUTABLE)
-  if(Java_IDLJ_EXECUTABLE)
+  if(Java_JARSIGNER_EXECUTABLE)
 set(Java_JarSigner_FOUND TRUE)
   endif()
 else()

---

Summary of changes:
 Modules/FindJava.cmake |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)


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

Re: [cmake-developers] [CMake][PATCH] Various Java support enhancements

[Brad King]

On 12/03/2015 06:43 AM, CHEVRIER, Marc wrote:
>  1. Fix some typo errors (introduced by myself :(

Good catch.  Sorry I didn't notice that during review.  Those typos
clearly came from the component renaming we discussed.

Applied:

 FindJava: Fix typos in IdlJ and JarSigner component implementation
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8b251e2

I queued it for merge to 'release' for inclusion in 3.4.2.

>  2. Enable to specify manifest file as relative path
> (same behaviour as java sources)

Applied:

 UseJava: Allow relative path to manifest file just as with other sources
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=56c11eee

>  3. Add support for AIX/powerpc Java toolkits

Applied:

 FindJNI: Add support for AIX java sdk
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6fc91ffb

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-commits] CMake branch, next, updated. v3.4.1-1570-gd8ac93f

[Brad King]

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

The branch, next has been updated
   via  d8ac93fff8a91c77294d2c5b062765ebdafdbe1e (commit)
   via  6fc91ffb5f836e5878295030ea83a8f733fd0e96 (commit)
  from  103203b3b0b83c73476f82a2e1bd29bb272a53c6 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8ac93fff8a91c77294d2c5b062765ebdafdbe1e
commit d8ac93fff8a91c77294d2c5b062765ebdafdbe1e
Merge: 103203b 6fc91ff
Author: Brad King 
AuthorDate: Thu Dec 3 09:23:08 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 3 09:23:08 2015 -0500

Merge topic 'FindJNI-aix' into next

6fc91ffb FindJNI: Add support for AIX java sdk


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6fc91ffb5f836e5878295030ea83a8f733fd0e96
commit 6fc91ffb5f836e5878295030ea83a8f733fd0e96
Author: Marc Chevrier 
AuthorDate: Thu Dec 3 12:37:26 2015 +0100
Commit: Brad King 
CommitDate: Thu Dec 3 09:20:07 2015 -0500

FindJNI: Add support for AIX java sdk

diff --git a/Modules/FindJNI.cmake b/Modules/FindJNI.cmake
index cbe21d7..037764a 100644
--- a/Modules/FindJNI.cmake
+++ b/Modules/FindJNI.cmake
@@ -63,7 +63,7 @@ macro(java_append_library_directories _var)
 elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "^(powerpc|ppc)64")
 set(_java_libarch "ppc64" "ppc")
 elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "^(powerpc|ppc)")
-set(_java_libarch "ppc")
+set(_java_libarch "ppc" "ppc64")
 elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "^sparc")
 # Both flavours can run on the same processor
 set(_java_libarch "${CMAKE_SYSTEM_PROCESSOR}" "sparc" "sparcv9")
@@ -271,7 +271,7 @@ find_path(JAVA_INCLUDE_PATH jni.h
   ${JAVA_AWT_INCLUDE_DIRECTORIES}
 )
 
-find_path(JAVA_INCLUDE_PATH2 jni_md.h
+find_path(JAVA_INCLUDE_PATH2 NAMES jni_md.h jniport.h
   ${JAVA_INCLUDE_PATH}
   ${JAVA_INCLUDE_PATH}/darwin
   ${JAVA_INCLUDE_PATH}/win32
@@ -281,6 +281,7 @@ find_path(JAVA_INCLUDE_PATH2 jni_md.h
   ${JAVA_INCLUDE_PATH}/solaris
   ${JAVA_INCLUDE_PATH}/hp-ux
   ${JAVA_INCLUDE_PATH}/alpha
+  ${JAVA_INCLUDE_PATH}/aix
 )
 
 find_path(JAVA_AWT_INCLUDE_PATH jawt.h

---

Summary of changes:
 Modules/FindJNI.cmake |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)


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

Re: [CMake] Adding required source files to a custom target

[Nils Gladitz]

On 12/03/2015 03:47 PM, Attila Krasznahorkay wrote:

Dear All,

Is it possible to add additional source files to an already existing custom 
target?

My project needs to generate a number of "different things", which it does by 
setting up many custom commands. In order to trigger the generation of everything, I 
currently need to set up an inconvenient number of custom targets as well. Would it be 
possible to attach multiple custom commands to an already existing custom target?


e.g. this nonsense example seems to work:

   cmake_minimum_required(VERSION 3.4)

   add_custom_target(foo ALL
COMMAND ${CMAKE_COMMAND} -E echo $
DEPENDS "$"
VERBATIM
   )

   function(add_custom_input input)
set(_output "${CMAKE_CURRENT_BINARY_DIR}/${input}.out")
set(_input "${CMAKE_CURRENT_SOURCE_DIR}/${input}")

add_custom_command(OUTPUT ${_output}
COMMAND ${CMAKE_COMMAND} -E copy ${_input} ${_output}
DEPENDS ${_input}
VERBATIM
)

set_property(TARGET foo APPEND PROPERTY MY_INPUTS ${_output})
   endfunction()

   file(WRITE input1)
   add_custom_input(input1)

   file(WRITE input2)
   add_custom_input(input2)

Nils
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files

[Brad King]

On 12/03/2015 11:05 AM, Bartosz Kosiorek wrote:
> After every step I will need to clean it up .

If you add these as cases in the RunCMake.CommandLine test then each one can
get its own directory and the RunCMake infrastructure will take care of
cleaning it up for each run.

-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] [PATCH] Extend copy and copy_if_different commands with support multiple files

[Bartosz Kosiorek]

When I'm trying to run test with wildcard:
run_cmake_command(E_copy-wildcard-source-files-target-is-directory 
${CMAKE_COMMAND} -E copy 
  ${RunCMake_copy_TEST_SOURCE_DIR}/directory1/* 
  ${RunCMake_copy_TEST_BINARY_DIR})

I've got an error:

Error copying file 
"/home/kosiorek/dev/perforce/cmake-dev/Tests/RunCMake/CommandLine/test_copy_command_dir/directory1/*"
 to 
"/home/kosiorek/dev/perforce/cmake-dev/builddir/Tests/RunCMake/CommandLine/test_copy_command_dir".

but when I'm running such command locally it work perfectly:

/home/kosiorek/dev/perforce/cmake-dev/builddir/bin/cmake -E copy 
/home/kosiorek/dev/perforce/cmake-dev/Tests/RunCMake/CommandLine/test_copy_command_dir/directory1/*
 
/home/kosiorek/dev/perforce/cmake-dev/builddir/Tests/RunCMake/CommandLine/test_copy_command_dir

What I'm doing wrong ?



From: Brad King 
Sent: Thursday, December 3, 2015 5:38 PM
To: Bartosz Kosiorek
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] Extend copy and copy_if_different 
commands with support multiple files

On 12/03/2015 11:05 AM, Bartosz Kosiorek wrote:
> After every step I will need to clean it up .

If you add these as cases in the RunCMake.CommandLine test then each one can
get its own directory and the RunCMake infrastructure will take care of
cleaning it up for each run.

-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] 3.4.1 installer overwrites Windows PATH system var

[Brad King]

On 12/03/2015 11:04 AM, Vasily Vladimirovich Vylkov wrote:
> Installing CMake on Windows (7, 64-bit) with the "add cmake to system
> PATH for all users" option overwrote the contents of my PATH variable,
> instead of appending to it.  This is horrible!  I don't know of any
> way to recover my previous PATH value.
> 
> It also looks like this has been an issue in several previous versions:
>   * https://cmake.org/Bug/view.php?id=10257
>   * https://cmake.org/Bug/view.php?id=12875
> 
> Shouldn't there be a regression / sanity test case for this prior to
> publishing a new version of the installer?

For every new release binary we run the installer by hand to verify
that the interaction works.  This doesn't happen to us.

The installer is produced with NSIS.  I wonder if this is a case of:

 
http://stackoverflow.com/questions/21897103/nsis-envvarupdate-overwrites-system-path-when-path-is-too-long-is-there-a-wor

How long was your PATH before?

-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Adding required source files to a custom target

[Attila Krasznahorkay]

Hi Nils,

Clever. I didn't even consider specifying the SOURCES argument of the custom 
target with a generator expression. But it seems to work perfectly.

Thanks!
 Attila

> On 03 Dec 2015, at 16:00, Nils Gladitz  wrote:
> 
> On 12/03/2015 03:47 PM, Attila Krasznahorkay wrote:
>> Dear All,
>> 
>> Is it possible to add additional source files to an already existing custom 
>> target?
>> 
>> My project needs to generate a number of "different things", which it does 
>> by setting up many custom commands. In order to trigger the generation of 
>> everything, I currently need to set up an inconvenient number of custom 
>> targets as well. Would it be possible to attach multiple custom commands to 
>> an already existing custom target?
>> 
> 
> e.g. this nonsense example seems to work:
> 
> cmake_minimum_required(VERSION 3.4)
> 
> add_custom_target(foo ALL
> COMMAND ${CMAKE_COMMAND} -E echo $
> DEPENDS "$"
> VERBATIM
> )
> 
> function(add_custom_input input)
> set(_output "${CMAKE_CURRENT_BINARY_DIR}/${input}.out")
> set(_input "${CMAKE_CURRENT_SOURCE_DIR}/${input}")
> 
> add_custom_command(OUTPUT ${_output}
> COMMAND ${CMAKE_COMMAND} -E copy ${_input} ${_output}
> DEPENDS ${_input}
> VERBATIM
> )
> 
> set_property(TARGET foo APPEND PROPERTY MY_INPUTS ${_output})
> endfunction()
> 
> file(WRITE input1)
> add_custom_input(input1)
> 
> file(WRITE input2)
> add_custom_input(input2)
> Nils

-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Bill Hoffman]

On 12/2/2015 10:39 PM, iosif neitzke wrote:

Ah, okay, thanks.  From cmake-gui the solution equivalent would be
selecting the Ninja generator but specifying native compilers (cl.exe
for this example) instead of using the default native compilers?
.
Yes, that would work as well.  As long as cmake-gui was run in an 
environment that had the compiler setup to work from the command line.


-Bill

--

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1576-g97739fa

[Chuck Atkins]

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

The branch, next has been updated
   via  97739fa35a165782eba503845a14f3eb769b0338 (commit)
   via  8003ff4f85df29213becc0ac3d45ffa8b592bf75 (commit)
  from  eb9afec9bd9949e4a7fd26b95bf1b9a0eafcfe1e (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=97739fa35a165782eba503845a14f3eb769b0338
commit 97739fa35a165782eba503845a14f3eb769b0338
Merge: eb9afec 8003ff4
Author: Chuck Atkins 
AuthorDate: Thu Dec 3 10:25:46 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 3 10:25:46 2015 -0500

Merge topic 'detect-compiler-wrappers' into next

8003ff4f Compiler: Add infrastructure for detecting compiler wrappers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8003ff4f85df29213becc0ac3d45ffa8b592bf75
commit 8003ff4f85df29213becc0ac3d45ffa8b592bf75
Author: Chuck Atkins 
AuthorDate: Wed Dec 2 08:47:43 2015 -0600
Commit: Chuck Atkins 
CommitDate: Thu Dec 3 10:25:29 2015 -0500

Compiler: Add infrastructure for detecting compiler wrappers

diff --git a/Modules/CMakeCCompiler.cmake.in b/Modules/CMakeCCompiler.cmake.in
index c72e338..f109a14 100644
--- a/Modules/CMakeCCompiler.cmake.in
+++ b/Modules/CMakeCCompiler.cmake.in
@@ -2,6 +2,7 @@ set(CMAKE_C_COMPILER "@CMAKE_C_COMPILER@")
 set(CMAKE_C_COMPILER_ARG1 "@CMAKE_C_COMPILER_ARG1@")
 set(CMAKE_C_COMPILER_ID "@CMAKE_C_COMPILER_ID@")
 set(CMAKE_C_COMPILER_VERSION "@CMAKE_C_COMPILER_VERSION@")
+set(CMAKE_C_COMPILER_WRAPPER "@CMAKE_C_COMPILER_WRAPPER@")
 set(CMAKE_C_STANDARD_COMPUTED_DEFAULT "@CMAKE_C_STANDARD_COMPUTED_DEFAULT@")
 set(CMAKE_C_COMPILE_FEATURES "@CMAKE_C_COMPILE_FEATURES@")
 set(CMAKE_C90_COMPILE_FEATURES "@CMAKE_C90_COMPILE_FEATURES@")
diff --git a/Modules/CMakeCInformation.cmake b/Modules/CMakeCInformation.cmake
index d2417aa..5c3705c 100644
--- a/Modules/CMakeCInformation.cmake
+++ b/Modules/CMakeCInformation.cmake
@@ -60,6 +60,18 @@ if (NOT _INCLUDED_FILE)
   include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}
 OPTIONAL RESULT_VARIABLE _INCLUDED_FILE)
 endif ()
+
+# load any compiler-wrapper specific information
+if (CMAKE_C_COMPILER_WRAPPER)
+  set(_INCLUDED_WRAPPER_FILE 0)
+  if (CMAKE_C_COMPILER_ID)
+
include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_C_COMPILER_WRAPPER}-${CMAKE_C_COMPILER_ID}-C
 OPTIONAL RESULT_VARIABLE _INCLUDED_WRAPPER_FILE)
+  endif()
+  if (NOT _INCLUDED_WRAPPER_FILE)
+include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_C_COMPILER_WRAPPER}-C 
OPTIONAL RESULT_VARIABLE _INCLUDED_WRAPPER_FILE)
+  endif ()
+endif ()
+
 # We specify the compiler information in the system file for some
 # platforms, but this language may not have been enabled when the file
 # was first included.  Include it again to get the language info.
diff --git a/Modules/CMakeCXXCompiler.cmake.in 
b/Modules/CMakeCXXCompiler.cmake.in
index 52e44f6..9e90aea 100644
--- a/Modules/CMakeCXXCompiler.cmake.in
+++ b/Modules/CMakeCXXCompiler.cmake.in
@@ -2,6 +2,7 @@ set(CMAKE_CXX_COMPILER "@CMAKE_CXX_COMPILER@")
 set(CMAKE_CXX_COMPILER_ARG1 "@CMAKE_CXX_COMPILER_ARG1@")
 set(CMAKE_CXX_COMPILER_ID "@CMAKE_CXX_COMPILER_ID@")
 set(CMAKE_CXX_COMPILER_VERSION "@CMAKE_CXX_COMPILER_VERSION@")
+set(CMAKE_CXX_COMPILER_WRAPPER "@CMAKE_CXX_COMPILER_WRAPPER@")
 set(CMAKE_CXX_STANDARD_COMPUTED_DEFAULT 
"@CMAKE_CXX_STANDARD_COMPUTED_DEFAULT@")
 set(CMAKE_CXX_COMPILE_FEATURES "@CMAKE_CXX_COMPILE_FEATURES@")
 set(CMAKE_CXX98_COMPILE_FEATURES "@CMAKE_CXX98_COMPILE_FEATURES@")
diff --git a/Modules/CMakeCXXInformation.cmake 
b/Modules/CMakeCXXInformation.cmake
index 091627b..cbcd0df 100644
--- a/Modules/CMakeCXXInformation.cmake
+++ b/Modules/CMakeCXXInformation.cmake
@@ -59,6 +59,18 @@ if (NOT _INCLUDED_FILE)
   include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME} OPTIONAL
   RESULT_VARIABLE _INCLUDED_FILE)
 endif ()
+
+# load any compiler-wrapper specific information
+if (CMAKE_CXX_COMPILER_WRAPPER)
+  set(_INCLUDED_WRAPPER_FILE 0)
+  if (CMAKE_CXX_COMPILER_ID)
+
include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_CXX_COMPILER_WRAPPER}-${CMAKE_CXX_COMPILER_ID}-CXX
 OPTIONAL RESULT_VARIABLE _INCLUDED_WRAPPER_FILE)
+  endif()
+  if (NOT _INCLUDED_WRAPPER_FILE)
+include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_CXX_COMPILER_WRAPPER}-CXX 
OPTIONAL RESULT_VARIABLE _INCLUDED_WRAPPER_FILE)
+  endif ()
+endif ()
+
 # We specify the compiler information in the system file for some
 # platforms, but this language may not have been enabled when the file
 # was first included.  Include it again to get the language info.
diff --git 

Re: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files

[Bartosz Kosiorek]

Hi.

I would like to create following tests for copy and copy_if_different commands:

cmake -E copy test_copy_command_dir/file1.txt 
test_copy_command_dir/target_directory1
Result: success
  E_copy-one-source-directory-target-is-directory-result.txt
  E_copy-one-source-directory-target-is-directory-stderr.txt

cmake -E copy test_copy_command_dir/directory1/file4.txt
Result: error
E_copy-one-source-file-result.txt
E_copy-one-source-file-stderr.txt

cmake -E copy test_copy_command_dir/file1.txt test_copy_command_dir/file2.txt  
test_copy_command_dir/file3.txt test_copy_command_dir/target_directory2
Result: Success
   E_copy-three-source-files-target-is-directory-result.txt
   E_copy-three-source-files-target-is-directory-stderr.txt

cmake -E copy test_copy_command_dir/file1.txt test_copy_command_dir/file2.txt  
test_copy_command_dir/file3.txt 
test_copy_command_dir/target_directory1/file4.txt
Result: Error
   E_copy-three-source-files-target-is-file-result.txt 
   E_copy-three-source-files-target-is-file-stderr.txt

cmake -E copy test_copy_command_dir/file1.txt not_existing_file.bad 
test_copy_command_dir/file2.txt   test_copy_command_dir/target_directory3
Result: Error. The correct files are copied successfuly
   E_copy-two-good-and-one-bad-source-files-target-is-directory-result.txt
   E_copy-two-good-and-one-bad-source-files-target-is-directory-stderr.txt

cmake -E copy test_copy_command_dir/*.txt 
test_copy_command_dir/target_directory4
Result: Success
   E_copy-wildcard-source-files-target-is-directory-result.txt
   E_copy-wildcard-source-files-target-is-directory-stderr.txt

cmake -E copy test_copy_command_dir/* test_copy_command_dir/directory1/file4.txt
Result: Error
   E_copy-wildcard-source-files-target-is-file-result.txt
   E_copy-wildcard-source-files-target-is-file-stderr.txt

The resource directory will be:
test_copy_command_dir
├── directory1
│   ├── file4.txt
│   └── file5.txt
├── directory2
├── file1.txt
├── file2.txt
├── file3.txt
├── target_directory1
├── target_directory2
├── target_directory3
└── target_directory4

What do you think about that?
After every step I will need to clean it up .

From: cmake-developers  on behalf of Brad 
King 
Sent: Thursday, December 3, 2015 2:45 PM
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] Extend copy and copy_if_different 
commands with support multiple files

On 12/02/2015 07:05 PM, Bartosz Kosiorek wrote:
> This patch allows to use multiple files in commands "copy" and 
> "copy_if_different".

Good, thanks.  Please also extend the Tests/RunCMake/CommandLine test to
cover this these operations.

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

[Cmake-commits] CMake branch, next, updated. v3.4.1-1574-geb9afec

[Chuck Atkins]

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

The branch, next has been updated
   via  eb9afec9bd9949e4a7fd26b95bf1b9a0eafcfe1e (commit)
   via  07b0b29d6cb38cec581c126b4e69fc10e8e48d1a (commit)
  from  4d1d9c62c5bb26fdf202e6fa5f302bee254ab77c (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eb9afec9bd9949e4a7fd26b95bf1b9a0eafcfe1e
commit eb9afec9bd9949e4a7fd26b95bf1b9a0eafcfe1e
Merge: 4d1d9c6 07b0b29
Author: Chuck Atkins 
AuthorDate: Thu Dec 3 10:25:10 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 3 10:25:10 2015 -0500

Merge topic 'detect-compiler-wrappers' into next

07b0b29d Wrappers: remove generic case


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07b0b29d6cb38cec581c126b4e69fc10e8e48d1a
commit 07b0b29d6cb38cec581c126b4e69fc10e8e48d1a
Author: Chuck Atkins 
AuthorDate: Thu Dec 3 10:24:33 2015 -0500
Commit: Chuck Atkins 
CommitDate: Thu Dec 3 10:24:33 2015 -0500

Wrappers: remove generic case

diff --git a/Modules/CMakeCInformation.cmake b/Modules/CMakeCInformation.cmake
index c204c77..5c3705c 100644
--- a/Modules/CMakeCInformation.cmake
+++ b/Modules/CMakeCInformation.cmake
@@ -70,9 +70,6 @@ if (CMAKE_C_COMPILER_WRAPPER)
   if (NOT _INCLUDED_WRAPPER_FILE)
 include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_C_COMPILER_WRAPPER}-C 
OPTIONAL RESULT_VARIABLE _INCLUDED_WRAPPER_FILE)
   endif ()
-  if (NOT _INCLUDED_WRAPPER_FILE)
-include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_C_COMPILER_WRAPPER} OPTIONAL)
-  endif ()
 endif ()
 
 # We specify the compiler information in the system file for some
diff --git a/Modules/CMakeCXXInformation.cmake 
b/Modules/CMakeCXXInformation.cmake
index cd706f4..cbcd0df 100644
--- a/Modules/CMakeCXXInformation.cmake
+++ b/Modules/CMakeCXXInformation.cmake
@@ -69,9 +69,6 @@ if (CMAKE_CXX_COMPILER_WRAPPER)
   if (NOT _INCLUDED_WRAPPER_FILE)
 include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_CXX_COMPILER_WRAPPER}-CXX 
OPTIONAL RESULT_VARIABLE _INCLUDED_WRAPPER_FILE)
   endif ()
-  if (NOT _INCLUDED_WRAPPER_FILE)
-include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_CXX_COMPILER_WRAPPER} 
OPTIONAL)
-  endif ()
 endif ()
 
 # We specify the compiler information in the system file for some
diff --git a/Modules/CMakeFortranInformation.cmake 
b/Modules/CMakeFortranInformation.cmake
index 110eec2..84ece04 100644
--- a/Modules/CMakeFortranInformation.cmake
+++ b/Modules/CMakeFortranInformation.cmake
@@ -46,9 +46,6 @@ if (CMAKE_Fortran_COMPILER_WRAPPER)
   if (NOT _INCLUDED_WRAPPER_FILE)
 
include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_WRAPPER}-Fortran 
OPTIONAL RESULT_VARIABLE _INCLUDED_WRAPPER_FILE)
   endif ()
-  if (NOT _INCLUDED_WRAPPER_FILE)
-include(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_WRAPPER} 
OPTIONAL)
-  endif ()
 endif ()
 
 # We specify the compiler information in the system file for some

---

Summary of changes:
 Modules/CMakeCInformation.cmake   |3 ---
 Modules/CMakeCXXInformation.cmake |3 ---
 Modules/CMakeFortranInformation.cmake |3 ---
 3 files changed, 9 deletions(-)


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

[CMake] List of debug configurations for multi-generators?

[Robert Dailey]

For any arbitrary configuration in a multi-generator, I need to
determine if it's configuration is optimized or not (release or
debug). At the moment I thought I could do this by comparing against
the list of DEBUG_CONFIGURATIONS, however this property is empty if I
have not set it. I was expecting CMake to fill this in at least with
"Debug" for the pre-provided configurations.

Is there no way to get this information? The only other way to do this
is to compare if the current configuration is "Debug", and if not,
treat it as release. But this will not work if I add my own custom
configurations.

I need to do this because for third party libraries, I only build
"Debug" and "Release" versions. "RelMinSize" and "RelWithDebInfo" both
use "release" libraries. I use this logic to help build relative paths
to point to the proper libs.
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] 3.4.1 installer overwrites Windows PATH system var

[Vasily Vladimirovich Vylkov]

Installing CMake on Windows (7, 64-bit) with the "add cmake to system
PATH for all users" option overwrote the contents of my PATH variable,
instead of appending to it.  This is horrible!  I don't know of any
way to recover my previous PATH value.

It also looks like this has been an issue in several previous versions:
  * https://cmake.org/Bug/view.php?id=10257
  * https://cmake.org/Bug/view.php?id=12875

Shouldn't there be a regression / sanity test case for this prior to
publishing a new version of the installer?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Alexander Neundorf]

On Thursday, December 03, 2015 09:27:29 Ruslan Baratov via CMake 
wrote:

> On 03-Dec-15 04:34, Alexander Neundorf wrote:
> > On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote:

> > If RPATH was _designed_ to be patchable, tools could just do it,
> > instead of having to implement workarounds for longer strings. E.g.
> > the linker would support a command line argument how much 
space it
> > should reserve for the RPATH entry, or something like that.
> 
> I think it's not possible. As far as I know there is no limitation for
> path size on Linux for example. Hence it's not possible to predict what
> size for path to library user want to use by setting RPATH.

More nitpicking about the meaning of "designed" ;-) :

CMake knows the length of the build RPATH and the length of the install 
RPATH. Let's say the build RPATH has a length of 100, and the install 
RPATH has a length of 150, it could, during linking, give the build RPATH 
to the linker, and also something like --rpath-size=150, and the linker 
would make the field for the RPATH 150 bytes big, so it could be 
patched easly later on.
This is what I would consider the minimum support if it was "designed" 
to be patched.
Instead cmake has to add 50 ":" at the end of the build RPATH. :-/

...
> > The idea above was only for solving the question "am I installed ?"
> > yes/no, not "where am I installed ?".
> 
> Then I don't understand how it's planned to be used. I thought that in
> build directory you changing "_I_M_NOT_INSTALLED_" to
> "/path/to/build/directory" so resources can be found there, and on
> install you change it to "/path/to/install/directory". So my guess is
> not correct?


Nothing is planned, just some ideas.
The idea was, during install, to set the first byte of that special string to 
'\0', and in the code you test whether the string is empty ( -> it has been 
patched, so it is installed) or not (still the original 
"_I_M_NOT_INSTALLED_").

With that information, the developer can then do whatever he wants. e.g. 
when not installed, search just in $CMAKE_BINARY_DIR (which could 
be configured into some other string), and if installed, search in some 
other way.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Add command line options for deprecation message control

[Michael Scott]

Thanks.  Applied with minor tweaks and merged to 'next' for testing:


That's great, thanks. Now that the patches are in, would you say it's 
better to work on adding a deprecated toggle option to the cmake-gui, or 
to work on adding support for upgrading warnings to errors?


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

[cmake-developers] [CMake 0015871]: Cmake may select incorrect default generator on windows host

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15871 
== 
Reported By:Richard Lang
Assigned To:
== 
Project:CMake
Issue ID:   15871
Category:   CMake
Reproducibility:have not tried
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-12-03 17:13 EST
Last Modified:  2015-12-03 17:13 EST
== 
Summary:Cmake may select incorrect default generator on
windows host
Description: 
Looking at cmake::ActualConfigure() method in cmake.cxx (line 1265 or
thereabouts), comment indicates that in absence of a specified generator cmake
running on a native Windows host (not Cygwin) should generate for the newest
Visual Studio installation found on the system, and fall back to generating a
NMake make file if none found (which seems sensible), however as far as I can
see the code is actually going to select the OLDEST VS install.

Haven't run any test cases, this is solely from code inspection.

Steps to Reproduce: 
Run Cmake without generator specified on Windows host with more than 1 version
of visual Studio installed.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-03 17:13 Richard Lang   New Issue
==

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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-commits] CMake branch, next, updated. v3.4.1-1578-g23b5ca6

[Gregor Jasny via Cmake-commits]

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

The branch, next has been updated
   via  23b5ca6d7461f3c166a0ab826c456bc30a370452 (commit)
   via  fc656fa4fe2926c7a50de91ff1b5564802ac4a7e (commit)
  from  97739fa35a165782eba503845a14f3eb769b0338 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23b5ca6d7461f3c166a0ab826c456bc30a370452
commit 23b5ca6d7461f3c166a0ab826c456bc30a370452
Merge: 97739fa fc656fa
Author: Gregor Jasny 
AuthorDate: Thu Dec 3 15:49:54 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 3 15:49:54 2015 -0500

Merge topic 'regex-explorer' into next

fc656fa4 cmake-gui: Add regex explorer window


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fc656fa4fe2926c7a50de91ff1b5564802ac4a7e
commit fc656fa4fe2926c7a50de91ff1b5564802ac4a7e
Author: Gregor Jasny 
AuthorDate: Wed Nov 18 22:40:59 2015 +0100
Commit: Gregor Jasny 
CommitDate: Thu Dec 3 21:45:54 2015 +0100

cmake-gui: Add regex explorer window

diff --git a/Help/release/dev/regex-explorer.rst 
b/Help/release/dev/regex-explorer.rst
new file mode 100644
index 000..2147816
--- /dev/null
+++ b/Help/release/dev/regex-explorer.rst
@@ -0,0 +1,6 @@
+regex-explorer
+--
+
+* The Qt base CMake GUI got a Regular Expression Explorer which could be used 
to
+  create and evaluate regular expressions in real-time. The explorer window
+  is available via the ``Tools`` menu.
diff --git a/Source/QtDialog/CMakeLists.txt b/Source/QtDialog/CMakeLists.txt
index 66fd18b..cad11f5 100644
--- a/Source/QtDialog/CMakeLists.txt
+++ b/Source/QtDialog/CMakeLists.txt
@@ -113,12 +113,15 @@ set(SRCS
   QCMakeCacheView.h
   QCMakeWidgets.cxx
   QCMakeWidgets.h
+  RegexExplorer.cxx
+  RegexExplorer.h
   )
 QT4_WRAP_UI(UI_SRCS
   CMakeSetupDialog.ui
   Compilers.ui
   CrossCompiler.ui
   AddCacheEntry.ui
+  RegexExplorer.ui
   )
 QT4_WRAP_CPP(MOC_SRCS
   AddCacheEntry.h
@@ -128,6 +131,7 @@ QT4_WRAP_CPP(MOC_SRCS
   QCMake.h
   QCMakeCacheView.h
   QCMakeWidgets.h
+  RegexExplorer.h
   )
 QT4_ADD_RESOURCES(RC_SRCS CMakeSetup.qrc)
 
diff --git a/Source/QtDialog/CMakeSetupDialog.cxx 
b/Source/QtDialog/CMakeSetupDialog.cxx
index 748dd7d..2b12834 100644
--- a/Source/QtDialog/CMakeSetupDialog.cxx
+++ b/Source/QtDialog/CMakeSetupDialog.cxx
@@ -33,6 +33,7 @@
 #include "QCMakeCacheView.h"
 #include "AddCacheEntry.h"
 #include "FirstConfigure.h"
+#include "RegexExplorer.h"
 #include "cmSystemTools.h"
 #include "cmVersion.h"
 
@@ -125,6 +126,9 @@ CMakeSetupDialog::CMakeSetupDialog()
this, SLOT(doInstallForCommandLine()));
 #endif
   ToolsMenu->addSeparator();
+  ToolsMenu->addAction(tr("Regular Expression Explorer..."),
+   this, SLOT(doRegexExplorerDialog()));
+  ToolsMenu->addSeparator();
   ToolsMenu->addAction(tr(" in Output..."),
this, SLOT(doOutputFindDialog()),
QKeySequence::Find);
@@ -1272,6 +1276,12 @@ void CMakeSetupDialog::doOutputFindDialog()
 }
 }
 
+void CMakeSetupDialog::doRegexExplorerDialog()
+{
+  RegexExplorer dialog(this);
+  dialog.exec();
+}
+
 void CMakeSetupDialog::doOutputFindPrev()
 {
   doOutputFindNext(false);
diff --git a/Source/QtDialog/CMakeSetupDialog.h 
b/Source/QtDialog/CMakeSetupDialog.h
index 1b26c64..bfd2bc9 100644
--- a/Source/QtDialog/CMakeSetupDialog.h
+++ b/Source/QtDialog/CMakeSetupDialog.h
@@ -82,6 +82,7 @@ protected slots:
   void doOutputFindNext(bool directionForward = true);
   void doOutputFindPrev();
   void doOutputErrorNext();
+  void doRegexExplorerDialog();
 
 protected:
 
diff --git a/Source/QtDialog/RegexExplorer.cxx 
b/Source/QtDialog/RegexExplorer.cxx
new file mode 100644
index 000..dfcf048
--- /dev/null
+++ b/Source/QtDialog/RegexExplorer.cxx
@@ -0,0 +1,166 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2015 Kitware, Inc., Gregor Jasny
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+*/
+
+#include "RegexExplorer.h"
+
+RegexExplorer::RegexExplorer(QWidget* p) : QDialog(p), m_matched(false)
+{
+  this->setupUi(this);
+
+  for(int i = 1; i < cmsys::RegularExpression::NSUBEXP; ++i)
+{
+

[Cmake-commits] CMake branch, next, updated. v3.4.1-1585-g26d765c

[James Johnston]

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

The branch, next has been updated
   via  26d765cf6b6c6a08b03b8643cd7b408dc29a373b (commit)
   via  7a3277276e69c92d0f69674cdc27bae11bcbc14f (commit)
   via  25211d756fad353e96d29e289d40d780a5341c92 (commit)
   via  060442c2e866c44ecf0c479e49e1d5ae35e8c6fb (commit)
   via  f3b3219c9687e54a83dc7e5dabb0afc4637bb799 (commit)
   via  ddbda72288f022fa558d8253c8894687634448c1 (commit)
   via  4ffeab0e3c451854a4a9d424b47b2179c6cf6c6b (commit)
  from  23b5ca6d7461f3c166a0ab826c456bc30a370452 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26d765cf6b6c6a08b03b8643cd7b408dc29a373b
commit 26d765cf6b6c6a08b03b8643cd7b408dc29a373b
Merge: 23b5ca6 7a32772
Author: James Johnston 
AuthorDate: Thu Dec 3 16:39:47 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 3 16:39:47 2015 -0500

Merge topic 'improve-embarcadero' into next

7a327727 Embarcadero: Fix erroneous interpretation of __CODEGEARC_VERSION__.
25211d75 Compiler ID: Compiler versions must be a valid, numeric version 
string.
060442c2 Embarcadero:  Check code using CMAKE_CXX_COMPILER_ID and 
CMAKE_C_COMPILER_ID.
f3b3219c Embarcadero/Watcom: Properly skip VSResource test for other 
generators.
ddbda722 Embarcadero: Fix bug where duplicate Ninja job pools would be 
created.
4ffeab0e CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a3277276e69c92d0f69674cdc27bae11bcbc14f
commit 7a3277276e69c92d0f69674cdc27bae11bcbc14f
Author: James Johnston 
AuthorDate: Thu Dec 3 21:24:56 2015 +
Commit: James Johnston 
CommitDate: Thu Dec 3 21:37:08 2015 +

Embarcadero: Fix erroneous interpretation of __CODEGEARC_VERSION__.

As per the following link:

  
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Example_of_CODEGEARC_VERSION_Macro

The major/minor versions must be decoded as a hex string, while the patch
version must be decoded as a normal decimal string.

As an example, C++ Builder XE 8.1's bcc32.exe sets this macro to 0x070189C9.
The file version of bcc32.exe is 7.1.5570.35273.  Therefore, the correct
interpretation to COMPILER_VERSION would be 7.1.35273.

diff --git a/Modules/Compiler/Embarcadero-DetermineCompiler.cmake 
b/Modules/Compiler/Embarcadero-DetermineCompiler.cmake
index 2feedac..8375624 100644
--- a/Modules/Compiler/Embarcadero-DetermineCompiler.cmake
+++ b/Modules/Compiler/Embarcadero-DetermineCompiler.cmake
@@ -4,4 +4,4 @@ set(_compiler_id_pp_test "defined(__BORLANDC__) && 
defined(__CODEGEARC_VERSION__
 set(_compiler_id_version_compute "
 # define @PREFIX@COMPILER_VERSION_MAJOR @MACRO_HEX@(__CODEGEARC_VERSION__>>24 
& 0x00FF)
 # define @PREFIX@COMPILER_VERSION_MINOR @MACRO_HEX@(__CODEGEARC_VERSION__>>16 
& 0x00FF)
-# define @PREFIX@COMPILER_VERSION_PATCH @MACRO_HEX@(__CODEGEARC_VERSION__ 
& 0x)")
+# define @PREFIX@COMPILER_VERSION_PATCH @MACRO_DEC@(__CODEGEARC_VERSION__ 
& 0x)")

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=25211d756fad353e96d29e289d40d780a5341c92
commit 25211d756fad353e96d29e289d40d780a5341c92
Author: James Johnston 
AuthorDate: Thu Dec 3 21:17:26 2015 +
Commit: James Johnston 
CommitDate: Thu Dec 3 21:37:07 2015 +

Compiler ID: Compiler versions must be a valid, numeric version string.

This test helps catch errors in compiler identification.

diff --git a/Tests/CMakeOnly/CompilerIdC/CMakeLists.txt 
b/Tests/CMakeOnly/CompilerIdC/CMakeLists.txt
index 848ffdd..6fea73e 100644
--- a/Tests/CMakeOnly/CompilerIdC/CMakeLists.txt
+++ b/Tests/CMakeOnly/CompilerIdC/CMakeLists.txt
@@ -12,3 +12,10 @@ foreach(v
 message(SEND_ERROR "${v} not set!")
   endif()
 endforeach()
+
+# Version numbers may only contain numbers and periods.
+if(NOT CMAKE_C_COMPILER_VERSION MATCHES
+"^([0-9]+)(\\.([0-9]+))?(\\.([0-9]+))?(\\.([0-9]+))?$"
+)
+  message(SEND_ERROR "Compiler version is not numeric!")
+endif()
diff --git a/Tests/CMakeOnly/CompilerIdCXX/CMakeLists.txt 
b/Tests/CMakeOnly/CompilerIdCXX/CMakeLists.txt
index 94ac31e..05e6bb2 100644
--- a/Tests/CMakeOnly/CompilerIdCXX/CMakeLists.txt
+++ b/Tests/CMakeOnly/CompilerIdCXX/CMakeLists.txt
@@ -12,3 +12,10 @@ foreach(v
 message(SEND_ERROR "${v} not set!")
   endif()
 endforeach()
+
+# Version numbers may only contain numbers and periods.
+if(NOT CMAKE_CXX_COMPILER_VERSION MATCHES
+

Re: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files

[Bartosz Kosiorek]

Hello.

Here is the patch with tests.

From: Brad King 
Sent: Thursday, December 3, 2015 7:07 PM
To: Bartosz Kosiorek
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] [PATCH] Extend copy and copy_if_different 
commands with support multiple files

On 12/03/2015 12:31 PM, Bartosz Kosiorek wrote:
> When I'm trying to run test with wildcard:
> run_cmake_command(E_copy-wildcard-source-files-target-is-directory 
> ${CMAKE_COMMAND} -E copy
>   ${RunCMake_copy_TEST_SOURCE_DIR}/directory1/*
>   ${RunCMake_copy_TEST_BINARY_DIR})
>
> I've got an error:

The command is not running through a shell in that case so there is
no step that expands the wildcard.  This feature is not about wildcard
expansion, but about multiple inputs to the copy.  They can be
spelled out explicitly in the command invocation, or passed through
a variable containing a list populated by file(GLOB).

-Brad

From 8225688074386ac8633bad5e6f9fdb4a7caf9775 Mon Sep 17 00:00:00 2001
From: "Bartosz Kosiorek bartosz.kosio...@tomtom.com"
 
Date: Thu, 3 Dec 2015 00:43:37 +0100
Subject: [PATCH 1/2] Extend copy and copy_if_different command with support
 multiple files

This patch allows to use multiple files in command copy and copy_if_different.
Input files could be merged with wildcards.
If multipile input files were provided, then destination must be directory.
If only one input file was provided, then destination could be either
file or directory. This path is starting point for fixing bug 15703
---
 Help/manual/cmake.1.rst | 12 
 Source/cmcmd.cxx| 73 +++--
 2 files changed, 58 insertions(+), 27 deletions(-)

diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index dac16bf..086f259 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -169,14 +169,14 @@ Available commands are:
 ``compare_files  ``
   Check if file1 is same as file2.
 
-``copy  ``
-  Copy file to destination (either file or directory).
+``copy ... ``
+  Copy files to 'destination' (either file or directory).
 
 ``copy_directory  ``
   Copy directory 'source' content to directory 'destination'.
 
-``copy_if_different  ``
-  Copy file if input has changed.
+``copy_if_different ... ``
+  Copy files if input has changed. Destination could be file or directory.
 
 ``echo [...]``
   Displays arguments as text.
@@ -193,10 +193,10 @@ Available commands are:
 ``make_directory ``
   Create a directory.
 
-``md5sum [...]``
+``md5sum ...``
   Compute md5sum of files.
 
-``remove [-f] [...]``
+``remove [-f] ...``
   Remove the file(s), use ``-f`` to force it.
 
 ``remove_directory ``
diff --git a/Source/cmcmd.cxx b/Source/cmcmd.cxx
index 21b126b..0dc5a9a 100644
--- a/Source/cmcmd.cxx
+++ b/Source/cmcmd.cxx
@@ -52,25 +52,25 @@ void CMakeCommandUsage(const char* program)
   // If you add new commands, change here,
   // and in cmakemain.cxx in the options table
   errorStream
-<< "Usage: " << program << " -E [command] [arguments ...]\n"
+<< "Usage: " << program << " -E  [arguments...]\n"
 << "Available commands: \n"
 << "  chdir dir cmd [args]...   - run command in a given directory\n"
 << "  compare_files file1 file2 - check if file1 is same as file2\n"
-<< "  copy file destination - copy file to destination (either file "
-   "or directory)\n"
+<< "  copy ... destination  - copy files to destination "
+   "(either file or directory)\n"
 << "  copy_directory source destination   - copy directory 'source' "
"content to directory 'destination'\n"
-<< "  copy_if_different in-file out-file  - copy file if input has "
+<< "  copy_if_different ... destination  - copy files if it has "
"changed\n"
-<< "  echo [string]...  - displays arguments as text\n"
-<< "  echo_append [string]...   - displays arguments as text but no new "
+<< "  echo [...]- displays arguments as text\n"
+<< "  echo_append [...] - displays arguments as text but no new "
"line\n"
 << "  env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...\n"
 << "- run command in a modified environment\n"
 << "  environment   - display the current environment\n"
 << "  make_directory dir- create a directory\n"
-<< "  md5sum file1 [...]- compute md5sum of files\n"
-<< "  remove [-f] file1 file2 ... - remove the file(s), use -f to force "
+<< "  md5sum ...  - compute md5sum of files\n"
+<< "  remove [-f] ... - remove the file(s), use -f to force "
"it\n"
 << "  remove_directory dir  - remove a directory and its contents\n"
 << "  rename oldname newname- rename a file or directory "
@@ -78,7 +78,7 @@ void CMakeCommandUsage(const char* program)
 << "  tar [cxt][vf][zjJ] file.tar [file/dir1 file/dir2 

Re: [CMake] Best way to handle application data path for local run vs. installation

[Ruslan Baratov via CMake]

On 04-Dec-15 03:47, Alexander Neundorf wrote:


On Thursday, December 03, 2015 09:27:29 Ruslan Baratov via CMake wrote:

> On 03-Dec-15 04:34, Alexander Neundorf wrote:

> > On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote:

> > If RPATH was _designed_ to be patchable, tools could just do it,

> > instead of having to implement workarounds for longer strings. E.g.

> > the linker would support a command line argument how much space it

> > should reserve for the RPATH entry, or something like that.

>

> I think it's not possible. As far as I know there is no limitation for

> path size on Linux for example. Hence it's not possible to predict what

> size for path to library user want to use by setting RPATH.

More nitpicking about the meaning of "designed" ;-) :

CMake knows the length of the build RPATH and the length of the 
install RPATH. Let's say the build RPATH has a length of 100, and the 
install RPATH has a length of 150, it could, during linking, give the 
build RPATH to the linker, and also something like --rpath-size=150, 
and the linker would make the field for the RPATH 150 bytes big, so it 
could be patched easly later on.


This is what I would consider the minimum support if it was "designed" 
to be patched.


Instead cmake has to add 50 ":" at the end of the build RPATH. :-/

...

> > The idea above was only for solving the question "am I installed ?"

> > yes/no, not "where am I installed ?".

>

> Then I don't understand how it's planned to be used. I thought that in

> build directory you changing "_I_M_NOT_INSTALLED_" to

> "/path/to/build/directory" so resources can be found there, and on

> install you change it to "/path/to/install/directory". So my guess is

> not correct?

Nothing is planned, just some ideas.

The idea was, during install, to set the first byte of that special 
string to '\0', and in the code you test whether the string is empty ( 
-> it has been patched, so it is installed) or not (still the original 
"_I_M_NOT_INSTALLED_").


With that information, the developer can then do whatever he wants. 
e.g. when not installed, search just in $CMAKE_BINARY_DIR (which could 
be configured into some other string), and if installed, search in 
some other way.


Will not work, just like I said compiler is smart enough to figure out 
if the first char in string literal is '\0' or not. Just make some 
testing: https://gist.github.com/ruslo/04d8993800ee78513d1c


The only one possibility to implement what you want I see in creating 
new dynamic library (probably by CMake) with one literal:


// 3rd party library API
const char* path_to_install();

void parse_resources() {
  const char* x = path_to_install();
  assert(x != 0);
  if (x[0] == '\0') {
// OK, can't be optimized since it's an external library
  }
  else {
// load resources
  }
}

So CMake should create such library in build directory and then 
re-create and install it with new string in install directory. Of course 
if you move such library it will not work :) So still doesn't make sense 
to me...


Ruslo

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] FindTIFF: Add imported targets

[Roger Leigh]

On 02/12/2015 17:31, rle...@codelibre.net wrote:

- Add TIFF::TIFF imported target
- Document imported target
- Add testcase to test the standard variables and the imported
   target

Also:

- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
   TIFF_INCLUDE_DIRS


I hope this is now staged correctly for review.  I've pushed a 
tiff-imported-target topic branch and merged into next:


amys% ssh g...@cmake.org stage cmake merge -b next tiff-imported-target
Fetching upstream next
Merge topic 'tiff-imported-target' into next

09f36344 Help: Document addition of FindTIFF imported targets
a237b26d FindTIFF: Add imported targets and update documentation

Auto-merging Tests/CMakeLists.txt
Pushing upstream next


Kind regards,
Roger
--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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-commits] CMake branch, next, updated. v3.4.1-1588-g203efca

[Roger Leigh]

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

The branch, next has been updated
   via  203efca5072f27271f5403f0188afc0bb0df767a (commit)
   via  09f36344eaa6adee6a238ae1320d57352eaee8f0 (commit)
   via  a237b26d6c9821464856db283e0f83152409465b (commit)
  from  26d765cf6b6c6a08b03b8643cd7b408dc29a373b (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=203efca5072f27271f5403f0188afc0bb0df767a
commit 203efca5072f27271f5403f0188afc0bb0df767a
Merge: 26d765c 09f3634
Author: Roger Leigh 
AuthorDate: Thu Dec 3 19:08:42 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 3 19:08:42 2015 -0500

Merge topic 'tiff-imported-target' into next

09f36344 Help: Document addition of FindTIFF imported targets
a237b26d FindTIFF: Add imported targets and update documentation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09f36344eaa6adee6a238ae1320d57352eaee8f0
commit 09f36344eaa6adee6a238ae1320d57352eaee8f0
Author: Roger Leigh 
AuthorDate: Thu Dec 3 23:46:44 2015 +
Commit: Roger Leigh 
CommitDate: Thu Dec 3 23:46:44 2015 +

Help: Document addition of FindTIFF imported targets

diff --git a/Help/release/dev/FindTIFF-imported-targets.rst 
b/Help/release/dev/FindTIFF-imported-targets.rst
new file mode 100644
index 000..f8bbc14
--- /dev/null
+++ b/Help/release/dev/FindTIFF-imported-targets.rst
@@ -0,0 +1,4 @@
+FindTIFF-imported-targets
+-
+
+* The :module:`FindTIFF` module now provides imported targets.

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a237b26d6c9821464856db283e0f83152409465b
commit a237b26d6c9821464856db283e0f83152409465b
Author: Roger Leigh 
AuthorDate: Wed Dec 2 17:20:24 2015 +
Commit: Roger Leigh 
CommitDate: Thu Dec 3 23:44:40 2015 +

FindTIFF: Add imported targets and update documentation

- Add TIFF::TIFF imported target
- Document imported target
- Add testcase to test the standard variables and the imported
  target

Also:

- Add TIFF_INCLUDE_DIRS to match common practice
- Update documentation generally, including documenting
  TIFF_INCLUDE_DIRS

diff --git a/Modules/FindTIFF.cmake b/Modules/FindTIFF.cmake
index ed092ea..e49a00d 100644
--- a/Modules/FindTIFF.cmake
+++ b/Modules/FindTIFF.cmake
@@ -2,24 +2,43 @@
 # FindTIFF
 # 
 #
-# Find TIFF library
+# Find the TIFF library (libtiff).
 #
-# Find the native TIFF includes and library This module defines
+# Imported targets
+# 
 #
-# ::
+# This module defines the following :prop_tgt:`IMPORTED` targets:
 #
-#   TIFF_INCLUDE_DIR, where to find tiff.h, etc.
-#   TIFF_LIBRARIES, libraries to link against to use TIFF.
-#   TIFF_FOUND, If false, do not try to use TIFF.
+# ``TIFF::TIFF``
+#   The TIFF library, if found.
 #
-# also defined, but not for general use are
+# Result variables
+# 
 #
-# ::
+# This module will set the following variables in your project:
 #
-#   TIFF_LIBRARY, where to find the TIFF library.
+# ``TIFF_FOUND``
+#   true if the TIFF headers and libraries were found
+# ``TIFF_INCLUDE_DIR``
+#   the directory containing the TIFF headers
+# ``TIFF_INCLUDE_DIRS``
+#   the directory containing the TIFF headers
+# ``TIFF_LIBRARIES``
+#   TIFF libraries to be linked
+#
+# Cache variables
+# ^^^
+#
+# The following cache variables may also be set:
+#
+# ``TIFF_INCLUDE_DIR``
+#   the directory containing the TIFF headers
+# ``TIFF_LIBRARY``
+# the path to the TIFF library
 
 #=
 # Copyright 2002-2009 Kitware, Inc.
+# Copyright 2015 University of Dundee
 #
 # Distributed under the OSI-approved BSD License (the "License");
 # see accompanying file Copyright.txt for details.
@@ -65,7 +84,35 @@ FIND_PACKAGE_HANDLE_STANDARD_ARGS(TIFF
   VERSION_VAR TIFF_VERSION_STRING)
 
 if(TIFF_FOUND)
-  set( TIFF_LIBRARIES ${TIFF_LIBRARY} )
+  set(TIFF_LIBRARIES ${TIFF_LIBRARY})
+  set(TIFF_INCLUDE_DIRS "${TIFF_INCLUDE_DIR}")
+
+  if(NOT TARGET TIFF::TIFF)
+add_library(TIFF::TIFF UNKNOWN IMPORTED)
+if(TIFF_INCLUDE_DIRS)
+  set_target_properties(TIFF::TIFF PROPERTIES
+INTERFACE_INCLUDE_DIRECTORIES "${TIFF_INCLUDE_DIRS}")
+endif()
+if(EXISTS "${TIFF_LIBRARY}")
+  set_target_properties(TIFF::TIFF PROPERTIES
+IMPORTED_LINK_INTERFACE_LANGUAGES "C"
+IMPORTED_LOCATION "${TIFF_LIBRARY}")
+endif()
+if(EXISTS 

[Cmake-commits] CMake branch, next, updated. v3.4.1-1590-g28b3454

[Roger Leigh]

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

The branch, next has been updated
   via  28b34545ee7e2e8de7ef8f4dbac33ae28b9d6401 (commit)
   via  d85228770a8062b40392e26a066954f6efd4f517 (commit)
  from  203efca5072f27271f5403f0188afc0bb0df767a (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=28b34545ee7e2e8de7ef8f4dbac33ae28b9d6401
commit 28b34545ee7e2e8de7ef8f4dbac33ae28b9d6401
Merge: 203efca d852287
Author: Roger Leigh 
AuthorDate: Thu Dec 3 19:33:12 2015 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Dec 3 19:33:12 2015 -0500

Merge topic 'tiff-imported-target' into next

d8522877 FindTIFF: Correct definition list indent


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d85228770a8062b40392e26a066954f6efd4f517
commit d85228770a8062b40392e26a066954f6efd4f517
Author: Roger Leigh 
AuthorDate: Fri Dec 4 00:32:32 2015 +
Commit: Roger Leigh 
CommitDate: Fri Dec 4 00:32:32 2015 +

FindTIFF: Correct definition list indent

diff --git a/Modules/FindTIFF.cmake b/Modules/FindTIFF.cmake
index e49a00d..e600498 100644
--- a/Modules/FindTIFF.cmake
+++ b/Modules/FindTIFF.cmake
@@ -34,7 +34,7 @@
 # ``TIFF_INCLUDE_DIR``
 #   the directory containing the TIFF headers
 # ``TIFF_LIBRARY``
-# the path to the TIFF library
+#   the path to the TIFF library
 
 #=
 # Copyright 2002-2009 Kitware, Inc.

---

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


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

Re: [CMake] 3.4.1 installer overwrites Windows PATH system var

[Tamás Kenéz]

about recovering the path see
http://superuser.com/questions/523688/deleted-path-environment-variable-how-to-restore

On Thursday, December 3, 2015, Brad King  wrote:

> On 12/03/2015 11:04 AM, Vasily Vladimirovich Vylkov wrote:
> > Installing CMake on Windows (7, 64-bit) with the "add cmake to system
> > PATH for all users" option overwrote the contents of my PATH variable,
> > instead of appending to it.  This is horrible!  I don't know of any
> > way to recover my previous PATH value.
> >
> > It also looks like this has been an issue in several previous versions:
> >   * https://cmake.org/Bug/view.php?id=10257
> >   * https://cmake.org/Bug/view.php?id=12875
> >
> > Shouldn't there be a regression / sanity test case for this prior to
> > publishing a new version of the installer?
>
> For every new release binary we run the installer by hand to verify
> that the interaction works.  This doesn't happen to us.
>
> The installer is produced with NSIS.  I wonder if this is a case of:
>
>
> http://stackoverflow.com/questions/21897103/nsis-envvarupdate-overwrites-system-path-when-path-is-too-long-is-there-a-wor
>
> How long was your PATH before?
>
> -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
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] Extend copy and copy_if_different commands with support multiple files

[Brad King]

On 12/03/2015 12:31 PM, Bartosz Kosiorek wrote:
> When I'm trying to run test with wildcard:
> run_cmake_command(E_copy-wildcard-source-files-target-is-directory 
> ${CMAKE_COMMAND} -E copy 
>   ${RunCMake_copy_TEST_SOURCE_DIR}/directory1/* 
>   ${RunCMake_copy_TEST_BINARY_DIR})
> 
> I've got an error:

The command is not running through a shell in that case so there is
no step that expands the wildcard.  This feature is not about wildcard
expansion, but about multiple inputs to the copy.  They can be
spelled out explicitly in the command invocation, or passed through
a variable containing a list populated by file(GLOB).

-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