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

[CHEVRIER, Marc]

Hi,

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

Marc



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

Powered by www.kitware.com

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

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

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

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

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

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

[Brad King]

On 12/11/2015 05:14 AM, CHEVRIER, Marc wrote:
> Attached is a patch to handle correctly policy 0065

Thanks.  I found that the same problem exists on HP-UX so I squashed
in some changes for that too and applied:

 AIX,HP-UX: Fix RPATH handling when CMP0065 is set to NEW
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f254276f

I've queued this for merge to the 'release' branch for 3.4.2.

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] Clarify on the ways to contribute

[Brad King]

On 12/11/2015 04:33 AM, Sebastian Schuberth wrote:
> while [1] clearly says that "The preferred entry point for new
> contributors is the mailing list", obviously also PRs at GitHub are
> merged [2]. Also, internally Kitware seems to use Gerrit [3], which
> for me would be the preferred place to submit and review patches.

The mailing list is still the preferred method, but GitHub does not
allow us to turn off PRs so we accept them for one-off simple changes.
For larger changes we usually close the PR with a request to come here.

The review.source.kitware.com site is used for some projects but is
not suitable for CMake development due to lack of topic-level reviews.

For now anyone taking the time to find and read CONTRIBUTING.rst should
contribute through this mailing list as it requests.

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] [Apple/iOS/OS X] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Brad King]

On 12/10/2015 09:52 AM, Bartosz Kosiorek wrote:
> How it is officialy supported to tell CMake to create subdirectories
> inside "Resources" directory?

I'm not particularly familiar with this infrastructure myself, but I
do not know of any way to define such a layout now.  A new interface
may have to be designed and implemented to achieve this.

-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] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Bartosz Kosiorek]

Thanks Clint

Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE 
property.
For every resource which is marked as RESOURCE, will be placed in root 
"Resources" directory.

The CMake code below create following directory structure for OS X:

── mul.framework
├── Headers -> Versions/Current/Headers
├── Resources -> Versions/Current/Resources
├── Versions
│   ├── A
│   │   ├── Headers
│   │   │   └── mul.h
│   │   ├── Modules
│   │   │   └── module.modulemap
│   │   ├── Resources
│   │   │   ├── Info.plist
│   │   │   ├── mulres.txt
│   │   │   ├── pl.txt
│   │   │   └── resourcefile.txt
│   │   ├── lang
│   │   │   └── en.txt
│   │   └── mul
│   └── Current -> A
└── mul -> Versions/Current/mul


As you can see eveything which is marked as "RESOURCE" will be placed in 
Versions/A/ directory
My expectation will be that lang/pl.txt and lang/en.txt should be in 
Resources/lang/ directory.
Here is complete directory structure:

── mul.framework
├── Headers -> Versions/Current/Headers
├── Resources -> Versions/Current/Resources
├── Versions
│   ├── A
│   │   ├── Headers
│   │   │   └── mul.h
│   │   ├── Modules
│   │   │   └── module.modulemap
│   │   ├── Resources
│   │   │   ├── Info.plist
│   │   │   ├── mulres.txt
│   │   │   ├── lang
│   │   │   │   └── pl.txt
│   │   │   │   └── en.txt
│   │   │   └── resourcefile.txt
│   │   ├── lang
│   │   │   └── en.txt
│   │   └── mul
│   └── Current -> A
└── mul -> Versions/Current/mul


What do you think about that?

Here is the source code:

set_property(SOURCE module.modulemap
  PROPERTY MACOSX_PACKAGE_LOCATION "Modules")

set_property(
  SOURCE lang/en.txt lang/pl.txt
  PROPERTY MACOSX_PACKAGE_LOCATION "lang")

set(RESLIST 
mulres.txt
lang/pl.txt
resourcefile.txt
)

add_library(mul SHARED 
mul.c
mul.h
module.modulemap
lang/pl.txt
lang/en.txt
resourcefile.txt
mulres.txt)

# Create an iOS Framework bundle 
set_target_properties(mul PROPERTIES
  FRAMEWORK TRUE
  MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
  MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
  MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
  XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
  PUBLIC_HEADER mul.h
  RESOURCE "${RESLIST}"
)

Thanks in advance 
Bartosz



From: clin...@elemtech.com 
Sent: Friday, December 11, 2015 4:24 PM
To: Brad King
Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny
Subject: Re: [Apple/iOS/OS X] Create subdirectories in Resource directory for 
Frameworks and Application bundle.

- On Dec 11, 2015, at 7:36 AM, Brad King brad.k...@kitware.com wrote:

> On 12/10/2015 09:52 AM, Bartosz Kosiorek wrote:
>> How it is officialy supported to tell CMake to create subdirectories
>> inside "Resources" directory?
>
> I'm not particularly familiar with this infrastructure myself, but I
> do not know of any way to define such a layout now.  A new interface
> may have to be designed and implemented to achieve this.
>
> -Brad


This may not be what you are looking for.
You can place files in a bundle/framework at certain locations.
Perhaps in subdirectories under Resources/.
https://cmake.org/cmake/help/v3.4/prop_sf/MACOSX_PACKAGE_LOCATION.html

Clint
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Imported targets for FindGTest

[Brad King]

On 12/10/2015 07:22 PM, rle...@codelibre.net wrote:
>> - Add unit test to test imported targets and existing variables
> 
> I should mention that to run the unit test, you must define the GTEST_ROOT
> environment variable to point to the gtest build, due to gtest being
> annoyingly crippled to be uninstallable for dubious reasons.  You can pass
> -DGTEST_ROOT, but since the cmake build can't pass it through without
> further changes, the environment variable is the only way to run the test
> with the existing patches.

Thanks.  I've set this up on a nightly dashboard testing client and will
look at it again once that is running.

-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] Clarify on the ways to contribute

[Sebastian Schuberth]

On Fri, Dec 11, 2015 at 2:35 PM, Brad King  wrote:

> The mailing list is still the preferred method, but GitHub does not
> allow us to turn off PRs so we accept them for one-off simple changes.
> For larger changes we usually close the PR with a request to come here.

Thanks for the clarification. Still, I'd appreciate if this info went
into CONTRIBUTING.rst.

-- 
Sebastian Schuberth
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 0015879]: Wrong configuration name emitted by generator expression

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15879 
== 
Reported By:Javier Martinez
Assigned To:
== 
Project:CMake
Issue ID:   15879
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2015-12-11 16:56 EST
Last Modified:  2015-12-11 16:56 EST
== 
Summary:Wrong configuration name emitted by generator
expression
Description: 
CMake has issues with the $ and $ generator expressions
when one configuration name is a substring of another. The attached reproducer
has Debug, Release and ReleaseInternal as the configuration names. In this case
ReleaseInternal is used instead of Release.

Steps to Reproduce: 
- Generate solution (I placed the CMakeLists/txt file in the /bin folder and
used cmake.exe . to generate the solution)
- Open the generated solution Test.sln
- Open the properties for TestProject -> CMake Rules ->stamp.txt.rule
- Click on Configuration Properties -> Custom Build Tools -> General
- On Configuration select Release
- Inspect the Command Line property, it reads "Printing comment for
ReleaseInternal" instead of "Printing comment for Release"

Additional Information: 
Tested with CMake version cmake-3.4.1-win32-x86
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2015-12-11 16:56 Javier MartinezNew Issue
2015-12-11 16:56 Javier MartinezFile Added: CMakeLists.txt
==

-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] set(CACHE) and the local scope

[Ben Boeckel]

On Fri, Dec 11, 2015 at 22:13:46 +0100, Alexander Neundorf wrote:
> On Friday, December 11, 2015 14:44:39 Ben Boeckel wrote:
> ...
> > Option 3:
> > 
> > set(CACHE) (and any other cache-touching behavior) does *nothing*
> > with the cache if a local variable by that name is defined
> 
> just to clarify: and also does nothing to the local variable ?

Correct.

--Ben
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Clinton Stimpson]

On Friday, December 11, 2015 08:46:56 PM Bartosz Kosiorek wrote:
> Hi
> 
> To enable iOS build, I'm using following settings in CMakeLists.txt:
> 
> 
> set(APPLE_PLATFORM "iphonesimulator")
> set(CMAKE_OSX_SYSROOT
> "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf
> orm/Developer/SDKs/iPhoneSimulator.sdk")
 set(CMAKE_C_FLAGS "-isysroot
> ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot
> ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") 
> Do you think it should be documented?
> 
> Where is the good place to do so?
> Maybe somewhere here:
> https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html
> 
> 
> 
> What do you think?
> 

I'm thinking it'll be better to integrate that at the Modules/Platform/ level.
For example, there is code in Darwin-Clang.cmake for the -mmacosx-version-min 
flag.

Perhaps iOS can be toggled with CMAKE_GENERATOR_PLATFORM.
Brad, what do you think?

Or maybe toggled with CMAKE_OSX_SYSROOT, and if the SDK is pointing to another 
platform than OS X, we can switch between
-mios-version-min= and -mmacosx-version-min=

Clint


> ​
> 
> 
> 
> From: clin...@elemtech.com 
> Sent: Friday, December 11, 2015 8:21 PM
> To: Bartosz Kosiorek
> Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny
> Subject: Re: [cmake-developers] Create subdirectories in Resource directory
> for Frameworks and Application bundle.
 
> 
> 
> - On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek 
> wrote:
 Hi
> 
> Because there is difference between OS X and iOS Bundles directory structure
> (see: Apple specification
> https://developer.apple.com/library/mac/documentation/CoreFoundation/Concep
> tual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5)
> RESOURCE property create corresponding directory structure. I have already
> fix that with:
> https://public.kitware.com/Bug/view.php?id=15848
> Ok.  I hadn't been following all your work.
> Also, I didn't see a toggle in the CMake code you sent to choose an iOS
> bundle instead of OS X bundles.  How is that toggled?
 
> So RESOURCE gives you a level of abstraction:
> For OSX:
> it will create "Resource" directory
> 
> For iOS it will create "flat" directory structure.
> 
> In your example "Resource" directory will be created in both cases (for OSX
> and iOS).
 Which is wrong:
> For OSX: it should  create "Resource" directory
> For iOS it will create "flat" directory structure.
> 
> I could provide patch to fix that issue, if you agree with that.
> What do you think about that?
> Do you think the same should be applied to "Headers"?
> 
> I think the abstraction seems reasonable, as well as what you are proposing.
>  However, I'm not an Apple guru.
 I wonder if there are other Apple experts
> that can weigh in this if better feedback is needed. 
> Clint
> 
> 
> Best Regards
> Bartosz
> 
> 
> 
> 2015-12-11 19:06 GMT+01:00 Clinton Stimpson
> >:
 
> 
> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:
> 
> > Thanks Clint
> >
> >
> >
> > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with
> > RESOURCE
 property. For every resource which is marked as RESOURCE, will
> > be placed in root "Resources" directory.
> >
> >
> >
> > The CMake code below create following directory structure for OS X:
> >
> >
> >
> > ── mul.framework
> > 
> > ├── Headers -> Versions/Current/Headers
> > ├── Resources -> Versions/Current/Resources
> > ├── Versions
> > │   ├── A
> > │   │   ├── Headers
> > │   │   │   └── mul.h
> > │   │   ├── Modules
> > │   │   │   └── module.modulemap
> > │   │   ├── Resources
> > │   │   │   ├── Info.plist
> > │   │   │   ├── mulres.txt
> > │   │   │   ├── pl.txt
> > │   │   │   └── resourcefile.txt
> > │   │   ├── lang
> > │   │   │   └── en.txt
> > │   │   └── mul
> > │   └── Current -> A
> > └── mul -> Versions/Current/mul
> >
> >
> >
> >
> > As you can see eveything which is marked as "RESOURCE" will be placed in
> > Versions/A/ directory My expectation will be that lang/pl.txt and
> > lang/en.txt should be in Resources/lang/ directory. Here is complete
> > directory structure:
> >
> >
> >
> > ── mul.framework
> > 
> > ├── Headers -> Versions/Current/Headers
> > ├── Resources -> Versions/Current/Resources
> > ├── Versions
> > │   ├── A
> > │   │   ├── Headers
> > │   │   │   └── mul.h
> > │   │   ├── Modules
> > │   │   │   └── module.modulemap
> > │   │   ├── Resources
> > │   │   │   ├── Info.plist
> > │   │   │   ├── mulres.txt
> > │   │   │   ├── lang
> > │   │   │   │   └── pl.txt
> > │   │   │   │   └── en.txt
> > │   │   │   └── resourcefile.txt
> > │   │   ├── lang
> > │   │   │   └── en.txt
> > │   │   └── mul
> > │   └── Current -> A
> > └── mul -> Versions/Current/mul
> >
> >

Re: [cmake-developers] set(CACHE) and the local scope

[Alexander Neundorf]

On Friday, December 11, 2015 14:44:39 Ben Boeckel wrote:
...
> Option 3:
> 
> set(CACHE) (and any other cache-touching behavior) does 
*nothing*
> with the cache if a local variable by that name is defined

just to clarify: and also does nothing to the local variable ?

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

[cmake-developers] parallel install of different cmake versions

[Orion Poplawski]

For Fedora EPEL we often end up packaging newer versions of cmake as cmakeXY
(e.g. cmake34) that can be installed in parallel with the system cmake.  This
is a fairly invasive process.  I'm attaching the current patch I'm working on
for this.  Is there any interest in cmake itself for supporting this kind of
thing?

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
diff -up cmake-3.4.1/bootstrap.cmake34 cmake-3.4.1/bootstrap
--- cmake-3.4.1/bootstrap.cmake34	2015-12-02 08:43:25.0 -0700
+++ cmake-3.4.1/bootstrap	2015-12-07 11:38:15.186608455 -0700
@@ -1346,8 +1346,8 @@ cmake_c_flags="${cmake_c_flags}-I`cmake_
   -I`cmake_escape \"${cmake_bootstrap_dir}\"`"
 cmake_cxx_flags="${cmake_cxx_flags} -I`cmake_escape \"${cmake_bootstrap_dir}\"` -I`cmake_escape \"${cmake_source_dir}/Source\"` \
   -I`cmake_escape \"${cmake_bootstrap_dir}\"`"
-echo "cmake: ${objs}" > "${cmake_bootstrap_dir}/Makefile"
-echo "	${cmake_cxx_compiler} ${cmake_ld_flags} ${cmake_cxx_flags} ${objs} -o cmake" >> "${cmake_bootstrap_dir}/Makefile"
+echo "cmake34: ${objs}" > "${cmake_bootstrap_dir}/Makefile"
+echo "	${cmake_cxx_compiler} ${cmake_ld_flags} ${cmake_cxx_flags} ${objs} -o cmake34" >> "${cmake_bootstrap_dir}/Makefile"
 for a in ${CMAKE_CXX_SOURCES}; do
   src=`cmake_escape "${cmake_source_dir}/Source/${a}.cxx"`
   echo "${a}.o : ${src} ${dep}" >> "${cmake_bootstrap_dir}/Makefile"
@@ -1465,7 +1465,7 @@ cmake_options="-DCMAKE_BOOTSTRAP=1"
 if [ -n "${cmake_verbose}" ]; then
   cmake_options="${cmake_options} -DCMAKE_VERBOSE_MAKEFILE=1"
 fi
-"${cmake_bootstrap_dir}/cmake" "${cmake_source_dir}" "-C${cmake_bootstrap_dir}/InitialCacheFlags.cmake" "-G${cmake_bootstrap_generator}" ${cmake_options} ${cmake_bootstrap_system_libs} "$@"
+"${cmake_bootstrap_dir}/cmake34" "${cmake_source_dir}" "-C${cmake_bootstrap_dir}/InitialCacheFlags.cmake" "-G${cmake_bootstrap_generator}" ${cmake_options} ${cmake_bootstrap_system_libs} "$@"
 RES=$?
 if [ "${RES}" -ne "0" ]; then
   cmake_error 11 "Problem while running initial CMake"
diff -up cmake-3.4.1/CMakeLists.txt.cmake34 cmake-3.4.1/CMakeLists.txt
--- cmake-3.4.1/CMakeLists.txt.cmake34	2015-12-02 08:43:21.0 -0700
+++ cmake-3.4.1/CMakeLists.txt	2015-12-07 11:38:15.186608455 -0700
@@ -179,9 +179,9 @@ macro(CMAKE_SETUP_TESTING)
 set_property(TARGET ${exe} PROPERTY IMPORTED_LOCATION ${CMake_TEST_EXTERNAL_CMAKE}/${exe})
   endforeach()
 else()
-  set(CMAKE_CTEST_COMMAND "${CMake_BIN_DIR}/ctest")
-  set(CMAKE_CMAKE_COMMAND "${CMake_BIN_DIR}/cmake")
-  set(CMAKE_CPACK_COMMAND "${CMake_BIN_DIR}/cpack")
+  set(CMAKE_CTEST_COMMAND "${CMake_BIN_DIR}/ctest34")
+  set(CMAKE_CMAKE_COMMAND "${CMake_BIN_DIR}/cmake34")
+  set(CMAKE_CPACK_COMMAND "${CMake_BIN_DIR}/cpack34")
 endif()
   endif()
 
diff -up cmake-3.4.1/Source/cmake.cxx.cmake34 cmake-3.4.1/Source/cmake.cxx
--- cmake-3.4.1/Source/cmake.cxx.cmake34	2015-12-02 08:43:22.0 -0700
+++ cmake-3.4.1/Source/cmake.cxx	2015-12-07 11:38:15.187608450 -0700
@@ -1958,7 +1958,7 @@ int cmake::CheckBuildSystem()
   if(verbose)
 {
 std::ostringstream msg;
-msg << "Re-run cmake, missing byproduct: " << *pi << "\n";
+msg << "Re-run cmake34, missing byproduct: " << *pi << "\n";
 cmSystemTools::Stdout(msg.str().c_str());
 }
   return 1;
@@ -1981,7 +1981,7 @@ int cmake::CheckBuildSystem()
 if(verbose)
   {
   std::ostringstream msg;
-  msg << "Re-run cmake no CMAKE_MAKEFILE_DEPENDS "
+  msg << "Re-run cmake34 no CMAKE_MAKEFILE_DEPENDS "
 "or CMAKE_MAKEFILE_OUTPUTS :\n";
   cmSystemTools::Stdout(msg.str().c_str());
   }
@@ -2007,7 +2007,7 @@ int cmake::CheckBuildSystem()
   if(verbose)
 {
 std::ostringstream msg;
-msg << "Re-run cmake: build system dependency is missing\n";
+msg << "Re-run cmake34: build system dependency is missing\n";
 cmSystemTools::Stdout(msg.str().c_str());
 }
   return 1;
@@ -2033,7 +2033,7 @@ int cmake::CheckBuildSystem()
   if(verbose)
 {
 std::ostringstream msg;
-msg << "Re-run cmake: build system output is missing\n";
+msg << "Re-run cmake34: build system output is missing\n";
 cmSystemTools::Stdout(msg.str().c_str());
 }
   return 1;
@@ -2051,7 +2051,7 @@ int cmake::CheckBuildSystem()
 if(verbose)
   {
   std::ostringstream msg;
-  msg << "Re-run cmake file: " << out_oldest
+  msg << "Re-run cmake34 file: " << out_oldest
   << " older than: " << dep_newest << "\n";
   cmSystemTools::Stdout(msg.str().c_str());
   }
diff -up cmake-3.4.1/Source/CMakeLists.txt.cmake34 cmake-3.4.1/Source/CMakeLists.txt
--- cmake-3.4.1/Source/CMakeLists.txt.cmake34	2015-12-02 

Re: [cmake-developers] [PATCH] Re: Create subdirectories in Resource directory for Frameworks and Application bundle.

[Bartosz Kosiorek]

Thanks Ruslan.


I will update documentation with information about such option (for Xcode 
generator)


Is it possible to mix arm and x86 architectures also for Make generator?

I'm very interesting in that bit :-)


Best Regards

Bartosz



From: Ruslan Baratov 
Sent: Saturday, December 12, 2015 2:15 AM
To: Bartosz Kosiorek
Cc: Clinton Stimpson; cmake-developers; Gregor Jasny
Subject: Re: [cmake-developers] [PATCH] Re: Create subdirectories in Resource 
directory for Frameworks and Application bundle.

On 12-Dec-15 07:26, Bartosz Kosiorek wrote:

Hi
I have updated current documentation with examples, to reflect current status 
of CMake in OSX/iOS support.

Such information is very useful for novice CMake developers,
and it saves an hours of digging through mailing list and websites.

This is true, totally agree.


+If user would like to build for iPhone device, it could specify::
+
+  set(CMAKE_OSX_ARCHITECTURES "armv7;armv7s;arm64")

Note that:
* you can mix simulator and device architectures here
* if more than one architecture set then `ONLY_ACTIVE_ARCH` will be set to 
`NO`. it is useful for install/archive stage but will slow down your 
development process. at least it worth to mention 
CMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH variable usage
* I think newly created IOS_INSTALL_COMBINED should be mentioned too
* also architectures can be set using next Xcode attributes:

  set_target_properties(
  foo
  PROPERTIES
  XCODE_ATTRIBUTE_ARCHS[sdk=iphoneos*] armv7
  XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphoneos*] armv7
  XCODE_ATTRIBUTE_ARCHS[sdk=iphonesimulator*] x86_64
  XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphonesimulator*] x86_64
  )

note that to specify several architectures you need to use space as a separator 
(unlike CMake list):

  set_target_properties(
  foo
  PROPERTIES
  XCODE_ATTRIBUTE_ARCHS[sdk=iphoneos*] "armv7 arm64"
  XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphoneos*] "armv7 arm64"
  )

Ruslan

Best Regards
Bartosz



From: Clinton Stimpson 
Sent: Friday, December 11, 2015 10:16 PM
To: Bartosz Kosiorek
Cc: cmake-developers; Gregor Jasny
Subject: Re: Create subdirectories in Resource directory for Frameworks and 
Application bundle.

On Friday, December 11, 2015 08:46:56 PM Bartosz Kosiorek wrote:


Hi

To enable iOS build, I'm using following settings in CMakeLists.txt:


set(APPLE_PLATFORM "iphonesimulator")
set(CMAKE_OSX_SYSROOT
"/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf
orm/Developer/SDKs/iPhoneSimulator.sdk")


 set(CMAKE_C_FLAGS "-isysroot


${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot
${CMAKE_OSX_SYSROOT} -mios-version-min=7.0")
Do you think it should be documented?

Where is the good place to do so?
Maybe somewhere here:
https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html



What do you think?



I'm thinking it'll be better to integrate that at the Modules/Platform/ level.
For example, there is code in Darwin-Clang.cmake for the -mmacosx-version-min
flag.

Perhaps iOS can be toggled with CMAKE_GENERATOR_PLATFORM.
Brad, what do you think?

Or maybe toggled with CMAKE_OSX_SYSROOT, and if the SDK is pointing to another
platform than OS X, we can switch between
-mios-version-min= and -mmacosx-version-min=

Clint




​



From: clin...@elemtech.com 

Sent: Friday, December 11, 2015 8:21 PM
To: Bartosz Kosiorek
Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny
Subject: Re: [cmake-developers] Create subdirectories in Resource directory
for Frameworks and Application bundle.


- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek 

wrote:


 Hi


Because there is difference between OS X and iOS Bundles directory structure
(see: Apple specification
https://developer.apple.com/library/mac/documentation/CoreFoundation/Concep
tual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5)
RESOURCE property create corresponding directory structure. I have already
fix that with:
https://public.kitware.com/Bug/view.php?id=15848
Ok.  I hadn't been following all your work.
Also, I didn't see a toggle in the CMake code you sent to choose an iOS
bundle instead of OS X bundles.  How is that toggled?


So RESOURCE gives you a level of abstraction:
For OSX:
it will create "Resource" directory

For iOS it will create "flat" directory structure.

In your example "Resource" directory will be created in both cases (for OSX
and iOS).


 Which is wrong:


For OSX: it should  create "Resource" directory
For iOS it will create "flat" directory structure.

I could provide patch to fix that issue, if you agree with that.
What do you think about that?
Do you think the same should be applied to 

Re: [cmake-developers] [PATCH] Re: Create subdirectories in Resource directory for Frameworks and Application bundle.

[Ruslan Baratov via cmake-developers]

On 12-Dec-15 07:26, Bartosz Kosiorek wrote:

Hi
I have updated current documentation with examples, to reflect current status 
of CMake in OSX/iOS support.

Such information is very useful for novice CMake developers,
and it saves an hours of digging through mailing list and websites.

This is true, totally agree.

+If user would like to build for iPhone device, it could specify::
+
+  set(CMAKE_OSX_ARCHITECTURES "armv7;armv7s;arm64")


Note that:
* you can mix simulator and device architectures here
* if more than one architecture set then `ONLY_ACTIVE_ARCH` will be set 
to `NO`. it is useful for install/archive stage but will slow down your 
development process. at least it worth to mention 
CMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH variable usage

* I think newly created IOS_INSTALL_COMBINED should be mentioned too
* also architectures can be set using next Xcode attributes:

  set_target_properties(
  foo
  PROPERTIES
  XCODE_ATTRIBUTE_ARCHS[sdk=iphoneos*] armv7
  XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphoneos*] armv7
  XCODE_ATTRIBUTE_ARCHS[sdk=iphonesimulator*] x86_64
  XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphonesimulator*] x86_64
  )

note that to specify several architectures you need to use space as a 
separator (unlike CMake list):


  set_target_properties(
  foo
  PROPERTIES
  XCODE_ATTRIBUTE_ARCHS[sdk=iphoneos*] "armv7 arm64"
  XCODE_ATTRIBUTE_VALID_ARCHS[sdk=iphoneos*] "armv7 arm64"
  )

Ruslan


Best Regards
Bartosz



From: Clinton Stimpson 
Sent: Friday, December 11, 2015 10:16 PM
To: Bartosz Kosiorek
Cc: cmake-developers; Gregor Jasny
Subject: Re: Create subdirectories in Resource directory for Frameworks and 
Application bundle.

On Friday, December 11, 2015 08:46:56 PM Bartosz Kosiorek wrote:

Hi

To enable iOS build, I'm using following settings in CMakeLists.txt:


set(APPLE_PLATFORM "iphonesimulator")
set(CMAKE_OSX_SYSROOT
"/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf
orm/Developer/SDKs/iPhoneSimulator.sdk")

  set(CMAKE_C_FLAGS "-isysroot

${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot
${CMAKE_OSX_SYSROOT} -mios-version-min=7.0")
Do you think it should be documented?

Where is the good place to do so?
Maybe somewhere here:
https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html



What do you think?


I'm thinking it'll be better to integrate that at the Modules/Platform/ level.
For example, there is code in Darwin-Clang.cmake for the -mmacosx-version-min
flag.

Perhaps iOS can be toggled with CMAKE_GENERATOR_PLATFORM.
Brad, what do you think?

Or maybe toggled with CMAKE_OSX_SYSROOT, and if the SDK is pointing to another
platform than OS X, we can switch between
-mios-version-min= and -mmacosx-version-min=

Clint



​



From: clin...@elemtech.com 
Sent: Friday, December 11, 2015 8:21 PM
To: Bartosz Kosiorek
Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny
Subject: Re: [cmake-developers] Create subdirectories in Resource directory
for Frameworks and Application bundle.

- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek 
wrote:

  Hi

Because there is difference between OS X and iOS Bundles directory structure
(see: Apple specification
https://developer.apple.com/library/mac/documentation/CoreFoundation/Concep
tual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5)
RESOURCE property create corresponding directory structure. I have already
fix that with:
https://public.kitware.com/Bug/view.php?id=15848
Ok.  I hadn't been following all your work.
Also, I didn't see a toggle in the CMake code you sent to choose an iOS
bundle instead of OS X bundles.  How is that toggled?
So RESOURCE gives you a level of abstraction:
For OSX:
it will create "Resource" directory

For iOS it will create "flat" directory structure.

In your example "Resource" directory will be created in both cases (for OSX
and iOS).

  Which is wrong:

For OSX: it should  create "Resource" directory
For iOS it will create "flat" directory structure.

I could provide patch to fix that issue, if you agree with that.
What do you think about that?
Do you think the same should be applied to "Headers"?

I think the abstraction seems reasonable, as well as what you are proposing.
  However, I'm not an Apple guru.

  I wonder if there are other Apple experts

that can weigh in this if better feedback is needed.
Clint


Best Regards
Bartosz



2015-12-11 19:06 GMT+01:00 Clinton Stimpson
>:
On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:


Thanks Clint



Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with
RESOURCE

  property. For every resource which is marked as RESOURCE, will

be placed in root "Resources" directory.



The CMake code below create following directory structure for OS X:



── 

[cmake-developers] [PATCH] Re: Create subdirectories in Resource directory for Frameworks and Application bundle.

[Bartosz Kosiorek]

Hi
I have updated current documentation with examples, to reflect current status 
of CMake in OSX/iOS support.

Such information is very useful for novice CMake developers, 
and it saves an hours of digging through mailing list and websites.

Best Regards
Bartosz



From: Clinton Stimpson 
Sent: Friday, December 11, 2015 10:16 PM
To: Bartosz Kosiorek
Cc: cmake-developers; Gregor Jasny
Subject: Re: Create subdirectories in Resource directory for Frameworks and 
Application bundle.

On Friday, December 11, 2015 08:46:56 PM Bartosz Kosiorek wrote:
> Hi
>
> To enable iOS build, I'm using following settings in CMakeLists.txt:
>
>
> set(APPLE_PLATFORM "iphonesimulator")
> set(CMAKE_OSX_SYSROOT
> "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platf
> orm/Developer/SDKs/iPhoneSimulator.sdk")
 set(CMAKE_C_FLAGS "-isysroot
> ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0") set(CMAKE_CXX_FLAGS "-isysroot
> ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0")
> Do you think it should be documented?
>
> Where is the good place to do so?
> Maybe somewhere here:
> https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html
>
>
>
> What do you think?
>

I'm thinking it'll be better to integrate that at the Modules/Platform/ level.
For example, there is code in Darwin-Clang.cmake for the -mmacosx-version-min
flag.

Perhaps iOS can be toggled with CMAKE_GENERATOR_PLATFORM.
Brad, what do you think?

Or maybe toggled with CMAKE_OSX_SYSROOT, and if the SDK is pointing to another
platform than OS X, we can switch between
-mios-version-min= and -mmacosx-version-min=

Clint


> ​
>
>
> 
> From: clin...@elemtech.com 
> Sent: Friday, December 11, 2015 8:21 PM
> To: Bartosz Kosiorek
> Cc: Bartosz Kosiorek; cmake-developers; Gregor Jasny
> Subject: Re: [cmake-developers] Create subdirectories in Resource directory
> for Frameworks and Application bundle.

>
>
> - On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek 
> wrote:
 Hi
>
> Because there is difference between OS X and iOS Bundles directory structure
> (see: Apple specification
> https://developer.apple.com/library/mac/documentation/CoreFoundation/Concep
> tual/CFBundles/BundleTypes/BundleTypes.html), in trunk (In CMake 3.5)
> RESOURCE property create corresponding directory structure. I have already
> fix that with:
> https://public.kitware.com/Bug/view.php?id=15848
> Ok.  I hadn't been following all your work.
> Also, I didn't see a toggle in the CMake code you sent to choose an iOS
> bundle instead of OS X bundles.  How is that toggled?

> So RESOURCE gives you a level of abstraction:
> For OSX:
> it will create "Resource" directory
>
> For iOS it will create "flat" directory structure.
>
> In your example "Resource" directory will be created in both cases (for OSX
> and iOS).
 Which is wrong:
> For OSX: it should  create "Resource" directory
> For iOS it will create "flat" directory structure.
>
> I could provide patch to fix that issue, if you agree with that.
> What do you think about that?
> Do you think the same should be applied to "Headers"?
>
> I think the abstraction seems reasonable, as well as what you are proposing.
>  However, I'm not an Apple guru.
 I wonder if there are other Apple experts
> that can weigh in this if better feedback is needed.
> Clint
>
>
> Best Regards
> Bartosz
>
>
>
> 2015-12-11 19:06 GMT+01:00 Clinton Stimpson
> >:

>
> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:
>
> > Thanks Clint
> >
> >
> >
> > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with
> > RESOURCE
 property. For every resource which is marked as RESOURCE, will
> > be placed in root "Resources" directory.
> >
> >
> >
> > The CMake code below create following directory structure for OS X:
> >
> >
> >
> > ── mul.framework
> >
> > ├── Headers -> Versions/Current/Headers
> > ├── Resources -> Versions/Current/Resources
> > ├── Versions
> > │   ├── A
> > │   │   ├── Headers
> > │   │   │   └── mul.h
> > │   │   ├── Modules
> > │   │   │   └── module.modulemap
> > │   │   ├── Resources
> > │   │   │   ├── Info.plist
> > │   │   │   ├── mulres.txt
> > │   │   │   ├── pl.txt
> > │   │   │   └── resourcefile.txt
> > │   │   ├── lang
> > │   │   │   └── en.txt
> > │   │   └── mul
> > │   └── Current -> A
> > └── mul -> Versions/Current/mul
> >
> >
> >
> >
> > As you can see eveything which is marked as "RESOURCE" will be placed in
> > Versions/A/ directory My expectation will be that lang/pl.txt and
> > lang/en.txt should be in Resources/lang/ directory. Here is complete
> > directory structure:
> >
> >
> >
> > ── mul.framework
> >
> > ├── Headers -> Versions/Current/Headers
> > ├── Resources -> Versions/Current/Resources
> > ├── Versions
> > │   ├── A
> > │ 

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Ruslan Baratov via cmake-developers]

On 12-Dec-15 10:08, Bartosz Kosiorek wrote:


Thanks Ruslan.


I would like to create instruction which is universal for all generators.

I think it's not possible. E.g. IOS_INSTALL_COMBINED will work only for 
Xcode.



Currently we would like to support both Make/Ninja and Xcode generators,


...

because Make is much faster than Xcode generator, and we are using it 
in our CI system.


Do you mean generate step or build? I've used to compile quite big 
projects like OpenCV with Xcode and according to the `top` it uses all 
my cores with clang++ at 100% CPU time.
Can you show any benchmarks? Also note that Xcode can add some 
additional stuff, like dSYM: 
https://github.com/headupinclouds/gatherer/pull/69



Make is also common for other architectures (Linux, QNX, Android etc.)


Unfortunately

   set(CMAKE_OSX_SYSROOT "iphoneos")

is not working for me.

It displays error:


  /Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake .. && 
/Users/warsaw/Perforce/cmake-dev/cmake-build/bin/cmake --build .

  -- Configuring done
  -- Generating done
  -- Build files have been written to: 
/Users/warsaw/Perforce/cmake_ios_framework_with_resource2/builddir
  [ 14%] Building C object 
shared_empty/heymath/CMakeFiles/heymath.dir/add.c.o

  clang: warning: no such sysroot directory: 'iphoneos'
...
Do you have some tip for that?

Yes, this hint was for Xcode generator.




After removing "-isysroot ${CMAKE_OSX_SYSROOT}" everything works 
perfectly. Thanks


Unfortunately CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET is not 
working with Make.
Is it possible to introduce CMAKE_IOS_DEPLOYMENT_TARGET, as we already 
have CMAKE_OSX_DEPLOYMENT_TARGET?
Since OSX_ARCHITECTURES controls iOS architectures too I think request 
should sounds like "Extend OSX_DEPLOYMENT_TARGET property for iOS platform".




I have attached my example script which I'm using.
​Could you please modify it to be better (and still support other 
generators)?

I don't know how to use iOS target with Makefile generator.

Some notes about project you've sent:
* You need to add instructions to codesign your bundle
* Instead of hardcoding `set(CMAKE_OSX_SYSROOT 
"/Applications/Xcode.app/.../iPhoneSimulator.sdk")` you can run 
`xcode-select -print-path` to detect location of default Xcode version
* Should be `set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} 
-mios-version-min=8.0")` instead of `set(CMAKE_CXX_FLAGS 
"-mios-version-min=8.0")` otherwise some flags may be lost


Ruslan


Best Regards
Bartosz






*From:* Ruslan Baratov 
*Sent:* Saturday, December 12, 2015 1:58 AM
*To:* Bartosz Kosiorek
*Cc:* clin...@elemtech.com; Gregor Jasny; CMake Developers
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.

On 12-Dec-15 03:46, Bartosz Kosiorek wrote:


Hi

To enable iOS build, I'm using following settings in CMakeLists.txt:


set(APPLE_PLATFORM "iphonesimulator")

I think this one not needed. Can't find any place where it parsed.

set(CMAKE_OSX_SYSROOT 
"/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk")

Can be set to:

set(CMAKE_OSX_SYSROOT "iphoneos")

in this case will support both simulator and device


set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0")
set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} 
-mios-version-min=7.0")
You can set minimum version by 
CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGETvariable.
In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option 
`-isysroot` is redundant.




Do you think it should be documented?

Where is the good place to do so?
Maybe somewhere here:
https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html


What do you think?

​



*From:* clin...@elemtech.com 
*Sent:* Friday, December 11, 2015 8:21 PM
*To:* Bartosz Kosiorek
*Cc:* Bartosz Kosiorek; cmake-developers; Gregor Jasny
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.




- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek 
 wrote:


Hi

Because there is difference between OS X and iOS Bundles
directory structure (see: Apple specification

https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html),

in trunk (In CMake 3.5) RESOURCE property create corresponding
directory structure.
I have already fix that with:
https://public.kitware.com/Bug/view.php?id=15848

Ok.  I hadn't been following all your work.
Also, I didn't see a toggle in the CMake code you sent to choose an 
iOS bundle instead of OS X bundles.  How is that toggled?


So RESOURCE gives you a level of abstraction:
For OSX:
it 

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Ruslan Baratov via cmake-developers]

On 12-Dec-15 03:46, Bartosz Kosiorek wrote:


Hi

To enable iOS build, I'm using following settings in CMakeLists.txt:


set(APPLE_PLATFORM "iphonesimulator")

I think this one not needed. Can't find any place where it parsed.

set(CMAKE_OSX_SYSROOT 
"/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk")

Can be set to:

   set(CMAKE_OSX_SYSROOT "iphoneos")

in this case will support both simulator and device


set(CMAKE_C_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} -mios-version-min=7.0")
set(CMAKE_CXX_FLAGS "-isysroot ${CMAKE_OSX_SYSROOT} 
-mios-version-min=7.0")
You can set minimum version by 
CMAKE_XCODE_ATTRIBUTE_IPHONEOS_DEPLOYMENT_TARGET variable.
In case of `CMAKE_OSX_SYSROOT` variable is set to `iphoneos` option 
`-isysroot` is redundant.




Do you think it should be documented?

Where is the good place to do so?
Maybe somewhere here:
https://cmake.org/cmake/help/v3.4/variable/CMAKE_OSX_SYSROOT.html


What do you think?

​



*From:* clin...@elemtech.com 
*Sent:* Friday, December 11, 2015 8:21 PM
*To:* Bartosz Kosiorek
*Cc:* Bartosz Kosiorek; cmake-developers; Gregor Jasny
*Subject:* Re: [cmake-developers] Create subdirectories in Resource 
directory for Frameworks and Application bundle.




- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek 
 wrote:


Hi

Because there is difference between OS X and iOS Bundles directory
structure (see: Apple specification

https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html),

in trunk (In CMake 3.5) RESOURCE property create corresponding
directory structure.
I have already fix that with:
https://public.kitware.com/Bug/view.php?id=15848

Ok.  I hadn't been following all your work.
Also, I didn't see a toggle in the CMake code you sent to choose an 
iOS bundle instead of OS X bundles.  How is that toggled?


So RESOURCE gives you a level of abstraction:
For OSX:
it will create "Resource" directory

For iOS it will create "flat" directory structure.

In your example "Resource" directory will be created in both cases
(for OSX and iOS).
Which is wrong:
For OSX: it should  create "Resource" directory
For iOS it will create "flat" directory structure.

I could provide patch to fix that issue, if you agree with that.
What do you think about that?
Do you think the same should be applied to "Headers"?


I think the abstraction seems reasonable, as well as what you are 
proposing.  However, I'm not an Apple guru.
I wonder if there are other Apple experts that can weigh in this if 
better feedback is needed.


Clint



Best Regards
Bartosz



2015-12-11 19:06 GMT+01:00 Clinton Stimpson >:



On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:
> Thanks Clint
>
> Unfortunately MACOSX_PACKAGE_LOCATION is not working
correctly with RESOURCE
> property. For every resource which is marked as RESOURCE,
will be placed in
> root "Resources" directory.
>
> The CMake code below create following directory structure
for OS X:
>
> ── mul.framework
> ├── Headers -> Versions/Current/Headers
> ├── Resources -> Versions/Current/Resources
> ├── Versions
> │   ├── A
> │   │   ├── Headers
> │   │   │   └── mul.h
> │   │   ├── Modules
> │   │   │   └── module.modulemap
> │   │   ├── Resources
> │   │   │   ├── Info.plist
> │   │   │   ├── mulres.txt
> │   │   │   ├── pl.txt
> │   │   │   └── resourcefile.txt
> │   │   ├── lang
> │   │   │   └── en.txt
> │   │   └── mul
> │   └── Current -> A
> └── mul -> Versions/Current/mul
>
>
> As you can see eveything which is marked as "RESOURCE" will
be placed in
> Versions/A/ directory My expectation will be that
lang/pl.txt and
> lang/en.txt should be in Resources/lang/ directory. Here is
complete
> directory structure:
>
> ── mul.framework
> ├── Headers -> Versions/Current/Headers
> ├── Resources -> Versions/Current/Resources
> ├── Versions
> │   ├── A
> │   │   ├── Headers
> │   │   │   └── mul.h
> │   │   ├── Modules
> │   │   │   └── module.modulemap
> │   │   ├── Resources
> │   │   │   ├── Info.plist
> │   │   │   ├── mulres.txt
> │   │   │   ├── lang
> │   │   │   │   └── pl.txt
> │   

Re: [cmake-developers] set(CACHE) and the local scope

[Ben Boeckel]

On Thu, Dec 10, 2015 at 08:50:10 -0500, Brad King wrote:
>  BUG: change in how set cache overrides local definitions. Should mainly be a 
> NOP change for most cases
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2

So Brad and I discussed today the reasons behind this change. Here is
the thread behind the cause for the change:

http://public.kitware.com/pipermail/cmake/2007-March/013198.html

The problem was this pattern:

function (set_cache var value)
set("${var}" "${value}" CACHE INTERNAL "docs")
endfunction ()

set(some_var value CACHE INTERNAL "docs")
set_cache(some_var other_value)
message("${some_var}")

Before this change, "value" would be output because the first set(CACHE)
would set `some_var` to `value` in the local scope, but afterwards,
because the variable is unset, the cache would be queried directly and
"other_value" would be output.

###

For work related to any changes to the interactions between the local
scope and the cache, here is the baseline that must be met:

The first configure must not differ from subsequent configures.

set(CACHE) using either FORCE or the INTERNAL type do not have this
problem currently since they always touch the local scope as well. I
don't think anyone is going to disagree that the existing behavior is a
problem in this regard, so the question is which behavior to prefer
(whether set(CACHE) has other optional arguments to select a specific
behavior or not is a separate question):

Option 1:

set(CACHE) always pulls from the cache into the local scope (first
configure behavior is canonical)

Option 2:

set(CACHE) never touches the local scope (subsequent configure
behavior is canonical)

The main benefit of the first option is that reading the code is more
"logical" in that set(CACHE) always does something to that variable
(makes the cache's value available as ${var}). The value is
unpredictable since the user can always set the cache to some bogus
value (the STRINGS property or type hints will not save you because -D
exists).

The main benefit of the second option is that projects embedding
external projects could override cache variables inside of that project
without set(CACHE INTERNAL) (which doesn't help in the case of FORCE or
INTERNAL variables that inner project uses anyways).

A third option that Brad and I brainstormed after tracking down various
bits of history and thinking about the behaviors is:

Option 3:

set(CACHE) (and any other cache-touching behavior) does *nothing*
with the cache if a local variable by that name is defined

This has the benefits of the second in that superset projects can set
projects *and* hide cache values with a single set() command and also
caches become less cluttered (e.g., if you set PYTHON_EXECUTABLE
explicitly, the cache entry for FindPythonInterp doesn't appear and
since the project is presumably forcing the value using a local
variable, that is what is wanted anyways, so don't let the user mess
that up).

This policy would become an invasive change (there are 40 (+6 if you
count cmCPluginAPI) call sites of cmMakefile::AddCacheDefinition that
need audited for behavior changes due to whatever policy behavior is
chosen.

Thoughts?

--Ben
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Clinton Stimpson]

On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:
> Thanks Clint
> 
> Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with RESOURCE
> property. For every resource which is marked as RESOURCE, will be placed in
> root "Resources" directory.
> 
> The CMake code below create following directory structure for OS X:
> 
> ── mul.framework
> ├── Headers -> Versions/Current/Headers
> ├── Resources -> Versions/Current/Resources
> ├── Versions
> │   ├── A
> │   │   ├── Headers
> │   │   │   └── mul.h
> │   │   ├── Modules
> │   │   │   └── module.modulemap
> │   │   ├── Resources
> │   │   │   ├── Info.plist
> │   │   │   ├── mulres.txt
> │   │   │   ├── pl.txt
> │   │   │   └── resourcefile.txt
> │   │   ├── lang
> │   │   │   └── en.txt
> │   │   └── mul
> │   └── Current -> A
> └── mul -> Versions/Current/mul
> 
> 
> As you can see eveything which is marked as "RESOURCE" will be placed in
> Versions/A/ directory My expectation will be that lang/pl.txt and
> lang/en.txt should be in Resources/lang/ directory. Here is complete
> directory structure:
> 
> ── mul.framework
> ├── Headers -> Versions/Current/Headers
> ├── Resources -> Versions/Current/Resources
> ├── Versions
> │   ├── A
> │   │   ├── Headers
> │   │   │   └── mul.h
> │   │   ├── Modules
> │   │   │   └── module.modulemap
> │   │   ├── Resources
> │   │   │   ├── Info.plist
> │   │   │   ├── mulres.txt
> │   │   │   ├── lang
> │   │   │   │   └── pl.txt
> │   │   │   │   └── en.txt
> │   │   │   └── resourcefile.txt
> │   │   ├── lang
> │   │   │   └── en.txt
> │   │   └── mul
> │   └── Current -> A
> └── mul -> Versions/Current/mul
> 
> 
> What do you think about that?
> 
> Here is the source code:
> 
> set_property(SOURCE module.modulemap
>   PROPERTY MACOSX_PACKAGE_LOCATION "Modules")
> 
> set_property(
>   SOURCE lang/en.txt lang/pl.txt
>   PROPERTY MACOSX_PACKAGE_LOCATION "lang")
> 
> set(RESLIST
> mulres.txt
> lang/pl.txt
> resourcefile.txt
> )
> 
> add_library(mul SHARED
> mul.c
> mul.h
> module.modulemap
> lang/pl.txt
> lang/en.txt
> resourcefile.txt
> mulres.txt)
> 
> # Create an iOS Framework bundle
> set_target_properties(mul PROPERTIES
>   FRAMEWORK TRUE
>   MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
>   MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
>   MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
>   XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
>   PUBLIC_HEADER mul.h
>   RESOURCE "${RESLIST}"
> )


Here is a CMakeLists.txt that will give you the desired layout.
I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE.


set_property(SOURCE module.modulemap
  PROPERTY MACOSX_PACKAGE_LOCATION "Modules")

set_property(
  SOURCE lang/pl.txt lang/en.txt
  PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang")

set(RESLIST 
mulres.txt
resourcefile.txt
)

add_library(mul SHARED 
mul.c
mul.h
module.modulemap
lang/pl.txt
lang/en.txt
resourcefile.txt
mulres.txt)

# Create an iOS Framework bundle 
set_target_properties(mul PROPERTIES
  FRAMEWORK TRUE
  MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
  MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
  MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
  XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
  PUBLIC_HEADER mul.h
  RESOURCE "${RESLIST}"
)


Now I'm wondering what does the RESOURCE target property do that 
MACOSX_PACKAGE_LOCATION doesn't already support?

Clint
-- 

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 0015878]: CMake 3.4.1 can not find standalone Windows SDK 8.1

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15878 
== 
Reported By:Dmitry Sokolov
Assigned To:
== 
Project:CMake
Issue ID:   15878
Category:   CMake
Reproducibility:have not tried
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2015-12-11 14:11 EST
Last Modified:  2015-12-11 14:11 EST
== 
Summary:CMake 3.4.1 can not find standalone Windows SDK 8.1
Description: 
Installed components:

* CMake 3.4.1
* Windows SDK 8.1 (standalone,
https://msdn.microsoft.com/en-us/windows/desktop/bg162891.aspx)
* Windows SDK 10 (standalone,
https://dev.windows.com/en-us/downloads/windows-10-sdk)
* Visual Studio Community 2015 with Update 1
(https://www.microsoft.com/en-us/download/details.aspx?id=49988)

Launching CMake:

cmake -G "Visual Studio 14 2015 ARM" ^
  -D CMAKE_SYSTEM_NAME=WindowsStore ^
  -D CMAKE_SYSTEM_VERSION=8.1 ^
  -D CMAKE_MACHINE_TYPE="ARM" ^
  -D CMAKE_C_COMPILER_WORKS=1 ^
  -D CMAKE_CXX_COMPILER_WORKS=1 ^
  -D CMAKE_SUPPRESS_REGENERATION=1 ^
  -D CMAKE_BUILD_TYPE=Release ^
  -D CMAKE_CONFIGURATION_TYPES=Release ^
  -D CMAKE_SKIP_BUILD_ALL_DEPENDENCY=1 ^
  x:/source


CMake Error at CMakeLists.txt:20 (project):
  A Windows Store component with CMake requires both the Windows Desktop SDK
  as well as the Windows Store '8.1' SDK.  Please make sure that you have
  both installed


Additional Information: 
== Environment variables ==

CommandPromptType=Cross
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
CommonProgramW6432=C:\Program Files\Common Files
ComSpec=C:\WINDOWS\system32\cmd.exe
DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\
Framework40Version=v4.0
FrameworkDir=C:\WINDOWS\Microsoft.NET\Framework64
FrameworkDIR32=C:\WINDOWS\Microsoft.NET\Framework\
FrameworkDIR64=C:\WINDOWS\Microsoft.NET\Framework64
FrameworkVersion=v4.0.30319
FrameworkVersion32=v4.0.30319
FrameworkVersion64=v4.0.30319
INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10586.0\ucrt;C:\Program Files (x86)\Windows
Kits\NETFXSDK\4.6.1\include\um;C:\Program Files (x86)\Windows
Kits\8.1\include\shared;C:\Program Files (x86)\Windows
Kits\8.1\include\um;C:\Program Files (x86)\Windows
Kits\8.1\include\winrt;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Windows
Kits\10\include\10.0.10586.0\ucrt;C:\Program Files (x86)\Windows
Kits\NETFXSDK\4.6.1\include\um;C:\Program Files (x86)\Windows
Kits\8.1\include\shared;C:\Program Files (x86)\Windows
Kits\8.1\include\um;C:\Program Files (x86)\Windows Kits\8.1\include\winrt;
LIB=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB\ARM;C:\Program
Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\LIB\ARM;C:\Program Files
(x86)\Windows Kits\10\lib\10.0.10586.0\ucrt\ARM;C:\Program Files (x86)\Windows
Kits\NETFXSDK\4.6.1\lib\um\ARM;C:\Program Files (x86)\Windows
Kits\8.1\lib\winv6.3\um\ARM;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\LIB;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows
Kits\10\lib\10.0.10586.0\ucrt\x86;C:\Program Files (x86)\Windows
Kits\NETFXSDK\4.6.1\lib\um\x86;C:\Program Files (x86)\Windows
Kits\8.1\lib\winv6.3\um\x86;
LIBPATH=C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files
(x86)\Microsoft Visual Studio 14.0\VC\LIB\ARM;C:\Program Files (x86)\Microsoft
Visual Studio 14.0\VC\ATLMFC\LIB\ARM;C:\Program Files (x86)\Windows
Kits\8.1\References\CommonConfiguration\Neutral;\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;C:\Program
Files (x86)\Microsoft Visual Studio 14.0\VC\LIB;C:\Program Files (x86)\Microsoft
Visual Studio 14.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Windows
Kits\8.1\References\CommonConfiguration\Neutral;\Microsoft.VCLibs\14.0\References\CommonConfiguration\neutral;
NETFXSDKDir=C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\
NUMBER_OF_PROCESSORS=4
OS=Windows_NT
Path=C:\Program Files (x86)\Microsoft Visual Studio
14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files
(x86)\MSBuild\14.0\bin\amd64;C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\BIN\amd64_arm;C:\Program Files 

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[clinton]

- On Dec 11, 2015, at 11:44 AM, Bartosz Kosiorek  
wrote: 

> Hi

> Because there is difference between OS X and iOS Bundles directory structure
> (see: Apple specification
> https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html
> ),
> in trunk (In CMake 3.5) RESOURCE property create corresponding directory
> structure.
> I have already fix that with:
> https://public.kitware.com/Bug/view.php?id=15848

Ok. I hadn't been following all your work. 
Also, I didn't see a toggle in the CMake code you sent to choose an iOS bundle 
instead of OS X bundles. How is that toggled? 

> So RESOURCE gives you a level of abstraction:
> For OSX:
> it will create "Resource" directory

> For iOS it will create "flat" directory structure.

> In your example "Resource" directory will be created in both cases (for OSX 
> and
> iOS).
> Which is wrong:
> For OSX: it should create "Resource" directory
> For iOS it will create "flat" directory structure.

> I could provide patch to fix that issue, if you agree with that.
> What do you think about that?
> Do you think the same should be applied to "Headers"?

I think the abstraction seems reasonable, as well as what you are proposing. 
However, I'm not an Apple guru. 
I wonder if there are other Apple experts that can weigh in this if better 
feedback is needed. 

Clint 

> Best Regards
> Bartosz

> 2015-12-11 19:06 GMT+01:00 Clinton Stimpson < clin...@elemtech.com > :

>> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:
>> > Thanks Clint

>> > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with 
>> > RESOURCE
>> > property. For every resource which is marked as RESOURCE, will be placed in
>> > root "Resources" directory.

>> > The CMake code below create following directory structure for OS X:

>> > ── mul.framework
>> > ├── Headers -> Versions/Current/Headers
>> > ├── Resources -> Versions/Current/Resources
>> > ├── Versions
>> > │ ├── A
>> > │ │ ├── Headers
>> > │ │ │ └── mul.h
>> > │ │ ├── Modules
>> > │ │ │ └── module.modulemap
>> > │ │ ├── Resources
>> > │ │ │ ├── Info.plist
>> > │ │ │ ├── mulres.txt
>> > │ │ │ ├── pl.txt
>> > │ │ │ └── resourcefile.txt
>> > │ │ ├── lang
>> > │ │ │ └── en.txt
>> > │ │ └── mul
>> > │ └── Current -> A
>> > └── mul -> Versions/Current/mul


>> > As you can see eveything which is marked as "RESOURCE" will be placed in
>> > Versions/A/ directory My expectation will be that lang/pl.txt and
>> > lang/en.txt should be in Resources/lang/ directory. Here is complete
>> > directory structure:

>> > ── mul.framework
>> > ├── Headers -> Versions/Current/Headers
>> > ├── Resources -> Versions/Current/Resources
>> > ├── Versions
>> > │ ├── A
>> > │ │ ├── Headers
>> > │ │ │ └── mul.h
>> > │ │ ├── Modules
>> > │ │ │ └── module.modulemap
>> > │ │ ├── Resources
>> > │ │ │ ├── Info.plist
>> > │ │ │ ├── mulres.txt
>> > │ │ │ ├── lang
>> > │ │ │ │ └── pl.txt
>> > │ │ │ │ └── en.txt
>> > │ │ │ └── resourcefile.txt
>> > │ │ ├── lang
>> > │ │ │ └── en.txt
>> > │ │ └── mul
>> > │ └── Current -> A
>> > └── mul -> Versions/Current/mul


>> > What do you think about that?

>> > Here is the source code:

>> > set_property(SOURCE module.modulemap
>> > PROPERTY MACOSX_PACKAGE_LOCATION "Modules")

>> > set_property(
>> > SOURCE lang/en.txt lang/pl.txt
>> > PROPERTY MACOSX_PACKAGE_LOCATION "lang")

>> > set(RESLIST
>> > mulres.txt
>> > lang/pl.txt
>> > resourcefile.txt
>> > )

>> > add_library(mul SHARED
>> > mul.c
>> > mul.h
>> > module.modulemap
>> > lang/pl.txt
>> > lang/en.txt
>> > resourcefile.txt
>> > mulres.txt)

>> > # Create an iOS Framework bundle
>> > set_target_properties(mul PROPERTIES
>> > FRAMEWORK TRUE
>> > MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
>> > MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
>> > MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
>> > XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
>> > PUBLIC_HEADER mul.h
>> > RESOURCE "${RESLIST}"
>> > )

>> Here is a CMakeLists.txt that will give you the desired layout.
>> I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE.

>> set_property(SOURCE module.modulemap
>> PROPERTY MACOSX_PACKAGE_LOCATION "Modules")

>> set_property(
>> SOURCE lang/pl.txt lang/en.txt
>> PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang")

>> set(RESLIST
>> mulres.txt
>> resourcefile.txt
>> )

>> add_library(mul SHARED
>> mul.c
>> mul.h
>> module.modulemap
>> lang/pl.txt
>> lang/en.txt
>> resourcefile.txt
>> mulres.txt)

>> # Create an iOS Framework bundle
>> set_target_properties(mul PROPERTIES
>> FRAMEWORK TRUE
>> MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
>> MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
>> MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
>> XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
>> PUBLIC_HEADER mul.h
>> RESOURCE "${RESLIST}"
>> )

>> Now I'm wondering what does the RESOURCE target property do that
>> MACOSX_PACKAGE_LOCATION doesn't already support?

>> Clint
>> --

>> Powered by 

Re: [cmake-developers] set(CACHE) and the local scope

[Robert Maynard]

I like the sounds of both Option 1, and Option 2. I feel Option 3 is really
bad.

We should remember that people understand/are taught the current CMake
behavior of local variables being preferred over cache variables.

If we move to Option 3, that rule becomes "local variables are preferred
over cache variables, and cache variables are not constructed if a local
variable exists ( even if unset? ) with the same name.". I can already
imagine people writing functions that try to set cache variables, but can't
since a local function variable is blocking them.




On Fri, Dec 11, 2015 at 2:44 PM, Ben Boeckel 
wrote:

> On Thu, Dec 10, 2015 at 08:50:10 -0500, Brad King wrote:
> >  BUG: change in how set cache overrides local definitions. Should mainly
> be a NOP change for most cases
> >  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2
>
> So Brad and I discussed today the reasons behind this change. Here is
> the thread behind the cause for the change:
>
> http://public.kitware.com/pipermail/cmake/2007-March/013198.html
>
> The problem was this pattern:
>
> function (set_cache var value)
> set("${var}" "${value}" CACHE INTERNAL "docs")
> endfunction ()
>
> set(some_var value CACHE INTERNAL "docs")
> set_cache(some_var other_value)
> message("${some_var}")
>
> Before this change, "value" would be output because the first set(CACHE)
> would set `some_var` to `value` in the local scope, but afterwards,
> because the variable is unset, the cache would be queried directly and
> "other_value" would be output.
>
> ###
>
> For work related to any changes to the interactions between the local
> scope and the cache, here is the baseline that must be met:
>
> The first configure must not differ from subsequent configures.
>
> set(CACHE) using either FORCE or the INTERNAL type do not have this
> problem currently since they always touch the local scope as well. I
> don't think anyone is going to disagree that the existing behavior is a
> problem in this regard, so the question is which behavior to prefer
> (whether set(CACHE) has other optional arguments to select a specific
> behavior or not is a separate question):
>
> Option 1:
>
> set(CACHE) always pulls from the cache into the local scope (first
> configure behavior is canonical)
>
> Option 2:
>
> set(CACHE) never touches the local scope (subsequent configure
> behavior is canonical)
>
> The main benefit of the first option is that reading the code is more
> "logical" in that set(CACHE) always does something to that variable
> (makes the cache's value available as ${var}). The value is
> unpredictable since the user can always set the cache to some bogus
> value (the STRINGS property or type hints will not save you because -D
> exists).
>
> The main benefit of the second option is that projects embedding
> external projects could override cache variables inside of that project
> without set(CACHE INTERNAL) (which doesn't help in the case of FORCE or
> INTERNAL variables that inner project uses anyways).
>
> A third option that Brad and I brainstormed after tracking down various
> bits of history and thinking about the behaviors is:
>
> Option 3:
>
> set(CACHE) (and any other cache-touching behavior) does *nothing*
> with the cache if a local variable by that name is defined
>
> This has the benefits of the second in that superset projects can set
> projects *and* hide cache values with a single set() command and also
> caches become less cluttered (e.g., if you set PYTHON_EXECUTABLE
> explicitly, the cache entry for FindPythonInterp doesn't appear and
> since the project is presumably forcing the value using a local
> variable, that is what is wanted anyways, so don't let the user mess
> that up).
>
> This policy would become an invasive change (there are 40 (+6 if you
> count cmCPluginAPI) call sites of cmMakefile::AddCacheDefinition that
> need audited for behavior changes due to whatever policy behavior is
> chosen.
>
> Thoughts?
>
> --Ben
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/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: 

Re: [cmake-developers] Create subdirectories in Resource directory for Frameworks and Application bundle.

[Bartosz Kosiorek]

Hi

Because there is difference between OS X and iOS Bundles directory
structure (see: Apple specification
https://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html),

in trunk (In CMake 3.5) RESOURCE property create corresponding directory
structure.
I have already fix that with:
https://public.kitware.com/Bug/view.php?id=15848

So RESOURCE gives you a level of abstraction:
For OSX:
it will create "Resource" directory

For iOS it will create "flat" directory structure.

In your example "Resource" directory will be created in both cases (for OSX
and iOS).
Which is wrong:
For OSX: it should  create "Resource" directory
For iOS it will create "flat" directory structure.

I could provide patch to fix that issue, if you agree with that.
What do you think about that?
Do you think the same should be applied to "Headers"?

Best Regards
Bartosz



2015-12-11 19:06 GMT+01:00 Clinton Stimpson :

>
>
> On Friday, December 11, 2015 05:01:41 PM Bartosz Kosiorek wrote:
> > Thanks Clint
> >
> > Unfortunately MACOSX_PACKAGE_LOCATION is not working correctly with
> RESOURCE
> > property. For every resource which is marked as RESOURCE, will be placed
> in
> > root "Resources" directory.
> >
> > The CMake code below create following directory structure for OS X:
> >
> > ── mul.framework
> > ├── Headers -> Versions/Current/Headers
> > ├── Resources -> Versions/Current/Resources
> > ├── Versions
> > │   ├── A
> > │   │   ├── Headers
> > │   │   │   └── mul.h
> > │   │   ├── Modules
> > │   │   │   └── module.modulemap
> > │   │   ├── Resources
> > │   │   │   ├── Info.plist
> > │   │   │   ├── mulres.txt
> > │   │   │   ├── pl.txt
> > │   │   │   └── resourcefile.txt
> > │   │   ├── lang
> > │   │   │   └── en.txt
> > │   │   └── mul
> > │   └── Current -> A
> > └── mul -> Versions/Current/mul
> >
> >
> > As you can see eveything which is marked as "RESOURCE" will be placed in
> > Versions/A/ directory My expectation will be that lang/pl.txt and
> > lang/en.txt should be in Resources/lang/ directory. Here is complete
> > directory structure:
> >
> > ── mul.framework
> > ├── Headers -> Versions/Current/Headers
> > ├── Resources -> Versions/Current/Resources
> > ├── Versions
> > │   ├── A
> > │   │   ├── Headers
> > │   │   │   └── mul.h
> > │   │   ├── Modules
> > │   │   │   └── module.modulemap
> > │   │   ├── Resources
> > │   │   │   ├── Info.plist
> > │   │   │   ├── mulres.txt
> > │   │   │   ├── lang
> > │   │   │   │   └── pl.txt
> > │   │   │   │   └── en.txt
> > │   │   │   └── resourcefile.txt
> > │   │   ├── lang
> > │   │   │   └── en.txt
> > │   │   └── mul
> > │   └── Current -> A
> > └── mul -> Versions/Current/mul
> >
> >
> > What do you think about that?
> >
> > Here is the source code:
> >
> > set_property(SOURCE module.modulemap
> >   PROPERTY MACOSX_PACKAGE_LOCATION "Modules")
> >
> > set_property(
> >   SOURCE lang/en.txt lang/pl.txt
> >   PROPERTY MACOSX_PACKAGE_LOCATION "lang")
> >
> > set(RESLIST
> > mulres.txt
> > lang/pl.txt
> > resourcefile.txt
> > )
> >
> > add_library(mul SHARED
> > mul.c
> > mul.h
> > module.modulemap
> > lang/pl.txt
> > lang/en.txt
> > resourcefile.txt
> > mulres.txt)
> >
> > # Create an iOS Framework bundle
> > set_target_properties(mul PROPERTIES
> >   FRAMEWORK TRUE
> >   MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
> >   MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
> >   MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
> >   XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
> >   PUBLIC_HEADER mul.h
> >   RESOURCE "${RESLIST}"
> > )
>
>
> Here is a CMakeLists.txt that will give you the desired layout.
> I also see that MACOSX_PACKAGE_LOCATION doesn't work with RESOURCE.
>
>
> set_property(SOURCE module.modulemap
>   PROPERTY MACOSX_PACKAGE_LOCATION "Modules")
>
> set_property(
>   SOURCE lang/pl.txt lang/en.txt
>   PROPERTY MACOSX_PACKAGE_LOCATION "Resources/lang")
>
> set(RESLIST
> mulres.txt
> resourcefile.txt
> )
>
> add_library(mul SHARED
> mul.c
> mul.h
> module.modulemap
> lang/pl.txt
> lang/en.txt
> resourcefile.txt
> mulres.txt)
>
> # Create an iOS Framework bundle
> set_target_properties(mul PROPERTIES
>   FRAMEWORK TRUE
>   MACOSX_FRAMEWORK_IDENTIFIER org.cmake.mul
>   MACOSX_FRAMEWORK_SHORT_VERSION_STRING 42
>   MACOSX_FRAMEWORK_BUNDLE_VERSION 3.2.10
>   XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
>   PUBLIC_HEADER mul.h
>   RESOURCE "${RESLIST}"
> )
>
>
> Now I'm wondering what does the RESOURCE target property do that
> MACOSX_PACKAGE_LOCATION doesn't already support?
>
> Clint
> --
>
> Powered by www.kitware.com
>
> Please keep messages