Re: [cmake-developers] Patch: install universal iOS libraries
On 07-Oct-15 16:57, Gregor Jasny wrote:
Hello,
thank you for working on this. This is really hairy stuff.
On 24/09/15 11:10, Ruslan Baratov via cmake-developers wrote:
Patches help to install universal iOS (device + simulator) libraries by
triggering some extra instructions (build + fuse) after "regular"
library installation finished. This behavior controlled by CMake
variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS.
some general remarks:
* iOS is not the only platform where the simulator / device situation is
problematic. Others are now watchOS and the upcoming tvOS (see
xcodebuild -showsdks). So it would make sense to replace the ios naming
in the method signatures with something more general.
It cames from PlatformIsAppleIos.
* Does the patches handle Bundles and Frameworks properly?
No. At least for now it's designed to be used only for libraries
(cmInstall_{STATIC,SHARED,MODULE}_LIBRARY). I don't think it make sense
to extend this feature for Bundles (simulator architectures are useless
in AppStore and will be rejected). If Bundle use Framework with
simulator architectures it will be rejected too. Though it make sense to
create "development" version of Framework with simulator archs but we
need to resign it after fuse procedure (libs are not signed).
I'm planning to try to make such patches for Frameworks next.
* This functionality should be limited to XCODE Generator
Fixed.
0001-
* Could you make the CMAKE_IOS_INSTALL_UNIVERSAL_LIBS a two staged
property like CMAKE_INSTALL_RPATH / INSTALL_RPATH. That way one would be
able to enable this behavior for only some targets
Implemented. But I'm not sure it make sense. Can you describe scenario
when it can be helpful?
0002-CMake-module-for-universal-iOS-library-install
* Could you avoid to hard-code architecture names like i386 or armv7 in
the module?
Ok. Added function to get "real" architectures by parsing `lipo -info`.
If it's not equal to the one specified by SDK then needless archs removed.
* In Xcode 7 (and maybe earlier) I see the following environment
variables when I install for Device:
export CORRESPONDING_SIMULATOR_PLATFORM_NAME=iphonesimulator
export CORRESPONDING_SIMULATOR_SDK_NAME=iphonesimulator9.0
export SUPPORTED_PLATFORMS="iphonesimulator iphoneos"
export SDK_NAME=iphoneos9.0
for Simulator:
export CORRESPONDING_DEVICE_PLATFORM_NAME=iphoneos
export CORRESPONDING_DEVICE_SDK_NAME=iphoneos9.0
export SDK_NAME=iphonesimulator9.0
Could you use those variables to avoid hardcoding iphoneos/simulator in
the module?
I see CORRESPONDING_*_SDK_NAME variables in Xcode 7.0 but not in 6.4.
+ install_universal_ios_remove_arch("${dev_libpath}" "i386")
+ install_universal_ios_remove_arch("${dev_libpath}" "x86_64")
Doing it the other way round (keeping only what's needed) looks saner to me.
+ install_universal_ios_remove_arch("${dev_libpath}" ...)
+
+ install_universal_ios_remove_arch("${sim_libpath}" ...)
+
+ set(cmd lipo -create ${src} ${dst} -output ${dst})
Would it be possible to just add selected architectures from src to dst
(via lipo -replace)? That way you would save some disk i/o and would
make the pruning step for src superfluous.
This is kind of "unusual" situation. In most cases this command will
just exit with "no such architecture" error (and ignored). I've added a
warning message if unexpected arch detected.
Rebased version of patches attached.
Github fork: https://github.com/ruslo/CMake/commits/pr.ios.universal.2
Thanks, Ruslo
>From 1576f4d44902041407ab405544e6925bc52f8285 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov
Date: Thu, 8 Oct 2015 03:09:34 +0300
Subject: [PATCH 1/3] Get target name for universal iOS library install
Add method GetTargetNameForUniversalIosInstall to cmInstallTargetGenerator.
This method will return target name if:
* Platform is iOS
* Generator is Xcode
* Target is library
* CMake variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS or target property
IOS_INSTALL_UNIVERSAL_LIBS is ON
Otherwise an empty string will be returned.
---
Source/cmInstallTargetGenerator.cxx | 42 +
Source/cmInstallTargetGenerator.h | 5 +
2 files changed, 47 insertions(+)
diff --git a/Source/cmInstallTargetGenerator.cxx b/Source/cmInstallTargetGenerator.cxx
index 30cf175..34728fa 100644
--- a/Source/cmInstallTargetGenerator.cxx
+++ b/Source/cmInstallTargetGenerator.cxx
@@ -869,3 +869,45 @@ cmInstallTargetGenerator::AddRanlibRule(std::ostream& os,
os << indent << "execute_process(COMMAND \""
<< ranlib << "\" \"" << toDestDirPath << "\")\n";
}
+
+std::string
+cmInstallTargetGenerator
+::GetTargetNameForUniversalIosInstall(cmInstallType type) const
+{
+ cmMakefile const* mf = this->Target->Target->GetMakefile();
+ if(!mf->PlatformIsAppleIos())
+{
+return "";
+}
+
+ switch(type)
+{
+case cmInstallType_STATIC_LIBRARY:
+case cmInstallType_SHARED_LIBRARY:
+case cmInstallType_MODULE_LIBRARY:
+ break;
+default:
[cmake-developers] [CMake 0015776]: 3.3.4 RC 1 Asserts when running on ITK 4.8.0
The following issue has been SUBMITTED. == https://public.kitware.com/Bug/view.php?id=15776 == Reported By:Rick Frank Assigned To: == Project:CMake Issue ID: 15776 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-10-07 20:05 EDT Last Modified: 2015-10-07 20:05 EDT == Summary:3.3.4 RC 1 Asserts when running on ITK 4.8.0 Description: Running CMake on ITK asserts in Runtime Library and prints the following: Performing Test InitOnceExecuteOnce - Success Checking for appropriate format for 64 bit long: Width with l64 failed with result: 3 File:minkernel\crts\ucrt\inc\corecrt_internal_stdio_outout.h Line 2480 Steps to Reproduce: Running CMake on ITK 4.8.0 == Issue History Date ModifiedUsername FieldChange == 2015-10-07 20:05 Rick Frank New Issue 2015-10-07 20:05 Rick Frank File Added: Capture.PNG == -- 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 0015775]: Ninja will unnecessarily relink on windows if a library exports no symbols
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15775
==
Reported By:James Johnston
Assigned To:
==
Project:CMake
Issue ID: 15775
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-10-07 18:34 EDT
Last Modified: 2015-10-07 18:34 EDT
==
Summary:Ninja will unnecessarily relink on windows if a
library exports no symbols
Description:
This is very similar to the issue reported by Nils Gladitz:
0015666: Ninja may unnecessarily relink on windows
http://public.kitware.com/Bug/view.php?id=15666
However, my test case does not work on CMake 3.4.0-rc1 either. In this
situation, the issue arises when the library exports no symbols.
My test case is almost identical to the one from Nils, except notice that
test.cpp is now a blank file: I don't export any symbols. If the project does
not export any symbols, the linker *will not emit a LIB file at all.*
It initially sounds non-sensical, but not exporting any symbols is not as
uncommon as one might think; some examples:
* It is common that a .NET C++/CLR project will not export unmanaged symbols,
as it is exporting directly through the DLL (i.e. no LIB file).
* A DLL being used for the purpose of storing Win32 resources would not export
any symbols.
* Some 3rd-party libraries (e.g. FLANN) happily seem to link an empty
library...
Steps to Reproduce:
My test case, as you can see it's basically the same as Nils in
http://public.kitware.com/Bug/view.php?id=15666 except no symbols:
CMakeLists.txt
--
# Using CMake 3.4.0-rc1 here:
cmake_minimum_required(VERSION 3.4)
project(Foo CXX)
if(NOT EXISTS test.cpp)
# Unlike Nils, I emit no symbols at all here:
file(WRITE test.cpp "")
endif()
add_custom_target(touch
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_SOURCE_DIR}/test.cpp
)
add_library(foo SHARED test.cpp)
Procedure:
--
1. Configure with Ninja from a Visual C++ 2008 command prompt. (Other VC++
versions will likely exhibit the same issue).
2. ninja # builds as expected
3. ninja # continues to build
4. ninja -d explain
ninja explain: output foo.lib doesn't exist
ninja explain: foo.dll is dirty
[1/1] Linking CXX shared library foo.dll
==
Issue History
Date ModifiedUsername FieldChange
==
2015-10-07 18:34 James Johnston 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-developers] [PATCH] set Content-Type in ctest http file uploads
The attached patch fixes https://cmake.org/Bug/view.php?id=15774
From 51c6e48cb1f861c146cdd10d064ac38538f72a55 Mon Sep 17 00:00:00 2001
From: Derek Bruening
Date: Wed, 7 Oct 2015 17:51:26 -0400
Subject: [PATCH] CTest: set Content-Type header for http file upload
Sets the Content-Type header for http file uploads to avoid running afoul
of ModSecurity rules on the server.
Fixes https://cmake.org/Bug/view.php?id=15774
---
Source/CTest/cmCTestCurl.cxx | 5 +
Source/CTest/cmCTestSubmitHandler.cxx | 7 +++
2 files changed, 12 insertions(+)
diff --git a/Source/CTest/cmCTestCurl.cxx b/Source/CTest/cmCTestCurl.cxx
index b4c0137..7401ff7 100644
--- a/Source/CTest/cmCTestCurl.cxx
+++ b/Source/CTest/cmCTestCurl.cxx
@@ -166,6 +166,9 @@ bool cmCTestCurl::UploadFile(std::string const& local_file,
curlWriteMemoryCallback);
::curl_easy_setopt(this->Curl, CURLOPT_DEBUGFUNCTION,
curlDebugCallback);
+ // Be sure to set Content-Type to satisfy fussy modsecurity rules
+ struct curl_slist *headers = ::curl_slist_append(NULL, "Content-Type: text/xml");
+ ::curl_easy_setopt(this->Curl, CURLOPT_HTTPHEADER, headers);
std::vector responseData;
std::vector debugData;
::curl_easy_setopt(this->Curl, CURLOPT_FILE, (void *)&responseData);
@@ -174,6 +177,8 @@ bool cmCTestCurl::UploadFile(std::string const& local_file,
// Now run off and do what you've been told!
::curl_easy_perform(this->Curl);
::fclose(ftpfile);
+ ::curl_easy_setopt(this->Curl, CURLOPT_HTTPHEADER, NULL);
+ ::curl_slist_free_all(headers);
if ( responseData.size() > 0 )
{
diff --git a/Source/CTest/cmCTestSubmitHandler.cxx b/Source/CTest/cmCTestSubmitHandler.cxx
index 1e12f15..cb00dce 100644
--- a/Source/CTest/cmCTestSubmitHandler.cxx
+++ b/Source/CTest/cmCTestSubmitHandler.cxx
@@ -338,6 +338,7 @@ bool cmCTestSubmitHandler::SubmitUsingHTTP(const std::string& localprefix,
CURLcode res;
FILE* ftpfile;
char error_buffer[1024];
+ struct curl_slist *headers = ::curl_slist_append(NULL, "Content-Type: text/xml");
/* In windows, this will init the winsock stuff */
::curl_global_init(CURL_GLOBAL_ALL);
@@ -420,6 +421,9 @@ bool cmCTestSubmitHandler::SubmitUsingHTTP(const std::string& localprefix,
::curl_easy_setopt(curl, CURLOPT_PUT, 1);
::curl_easy_setopt(curl, CURLOPT_VERBOSE, 1);
+ // Be sure to set Content-Type to satisfy fussy modsecurity rules
+ ::curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers);
+
std::string local_file = *file;
if ( !cmSystemTools::FileExists(local_file.c_str()) )
{
@@ -477,6 +481,7 @@ bool cmCTestSubmitHandler::SubmitUsingHTTP(const std::string& localprefix,
cmCTestLog(this->CTest, ERROR_MESSAGE, " Cannot find file: "
<< local_file << std::endl);
::curl_easy_cleanup(curl);
+::curl_slist_free_all(headers);
::curl_global_cleanup();
return false;
}
@@ -621,6 +626,7 @@ bool cmCTestSubmitHandler::SubmitUsingHTTP(const std::string& localprefix,
<< std::endl);
}
::curl_easy_cleanup(curl);
+::curl_slist_free_all(headers);
::curl_global_cleanup();
return false;
}
@@ -630,6 +636,7 @@ bool cmCTestSubmitHandler::SubmitUsingHTTP(const std::string& localprefix,
" Uploaded: " + local_file << std::endl, this->Quiet);
}
}
+ ::curl_slist_free_all(headers);
::curl_global_cleanup();
return true;
}
--
2.4.3
--
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 0015774]: CTest result submission over http fails to set Content-Type header which runs afoul of ModSecurity rules
The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15774 == Reported By:Derek Bruening Assigned To: == Project:CMake Issue ID: 15774 Category: CTest Reproducibility:always Severity: block Priority: low Status: new == Date Submitted: 2015-10-07 17:49 EDT Last Modified: 2015-10-07 17:49 EDT == Summary:CTest result submission over http fails to set Content-Type header which runs afoul of ModSecurity rules Description: On some web hosting providers, ModSecurity rules are in place that prevent using CTest with a CDash installation on that provider. The particular rule looks like this (pieces removed for anonymity): ModSecurity: Access denied with code 406 (phase 2). Match of "rx ^0$" against "REQUEST_HEADERS:Content-Length" required. [msg "Request Containing Content, but Missing Content-Type header"] [uri "/CDash/submit.php"] CTest runs show this error: Submit files (using http) Using HTTP submit method Drop site:http:///CDash/submit.php?project= Error when uploading file: /Testing/20151005-0900/Build.xml Error message was: The requested URL returned error: 406 Not Acceptable Problems when submitting via HTTP The same 406 error is seen using curl -T: # curl -T /Testing/20151007-0900/Build.xml http:///CDash/submit.php?project= Not Acceptable!Not Acceptable!An appropriate representation of the requested resource could not be found on this server. This error was generated by Mod_Security. These hosting providers do not allow any method of disabling particular rules or ModSecurity in general. While we can debate the merits of this rule, it is simple to work around by providing a Content-Type header. E.g., curl -d works: # curl -d @/Testing/20151007-0900/Build.xml http:///CDash/submit.php?project= OK ... == Issue History Date ModifiedUsername FieldChange == 2015-10-07 17:49 Derek Bruening 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-developers] Visual Studio 6/7 removal
Hi, The CMake 3.3 notes deprecation of VS 6/7 generators. https://cmake.org/cmake/help/v3.3/release/3.3.html Can they be removed in the CMake 3.5 cycle, or is that intended for a later release? Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CXX_STANDARD and linking
Brad King wrote: > I don't want CMake to generate broken builds by default. We *know* it > goes wrong on Solaris and cannot possibly work without user intervention. Just some more on this: The CMake 3.3 behavior of this is the same as it has always been since introducing compile-features for SolarisStudio. Any users aware that compile-features only affect compilation will have added the link flag themselves with one of the already available mechanims. Such users will be affected by this CMake 3.4 change. For the build of CMake itself on Solaris, we should probably add the required link flag until there is a porcelian feature for it (in CompileFlags.cmake?). I'm also not confident in commit v3.4.0-rc1~10^2~1 (Features: Fix C++98 flags on Oracle SolarisStudio 12.4 on Linux, 2015-09-30) because it will mean that 'c++98 mode' on Solaris 12.4 is forced to use libstdc++ instead of stlport4 or libCstd (rougewave). I'm not sure of the implications of that. So, it might be best to revert that commit and its parent. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CXX_STANDARD and linking
Brad King wrote: > On 10/04/2015 10:47 AM, Stephen Kelly wrote: >> So, is this thread really about a bug, or is it a feature request? > > I think it has become a feature request to select link flags for language > standard levels. Not the language standard level, but the standard library to compile with and link with. It just happens that the way to link to the correct library on SolarisStudio is -std=c++11 (or -std=c++03 which presumably also links to the same libstdc++.so shipped with SolarisStudio; but I just note this for completeness). Also, I agree that we should pass -std=c++11 when linking with GNU too, which is why it looks like 'language standard level', but it is not because the language has no relevance at link time. >> Perhaps those commits should be reverted. I see no reason for >> SolarisStudio on linux to behave any differently than on solaris, so the >> commit relating to that is probably not appropriate. > > I don't want CMake to generate broken builds by default. We *know* it > goes wrong on Solaris and cannot possibly work without user intervention. > If a problem comes up on Linux too we can deal with it as necessary. I'm pretty sure the situation on linux is the same as on Solaris. Stephen Kelly wrote: > It is possible that I was operating as if the link flags were user > responsibility and had configured my environment accordingly (though I > don't remember). >> I wrote here some ideas of a design for specifying the standard library >> to use: >> >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13284/focus=13296 > > Is that the right link? I don't see discussion of -stdlib= in that > message. Gmane is not currently resolving the link. You might be right that there is no mention of -stdlib= flags, but I think there is mention of CMake providing IMPORTED targets which supply INTERFACE_ properties. I was referring to the design of cmake providing such IMPORTED targets, and indeed that design should allow the user to specify the library to link with, and that should add -stdlib= flags where appropriate. >> Perhaps, rather than passing CMAKE_CXX11_EXTENSION_COMPILE_OPTION to the >> linker, we should work more on a design like the above way to specify a >> standard library. > > Yes, but the -std= and -stdlib= flags are different from the full > LINK_OPTIONS discussion because they are meant specifically for the > front end and not for the linker (never "-Wl,"). Yes, I think previous design discussion (possibly the one linked above) included a TOOLCHAIN_OPTIONS property for cases like this and -pthread etc. > Also they need > to be selected by CMake rather than propagated as a flag specified > by project code. Yes, or some combination of both being possible. >> The compile features can imply a default and a set of allowed >> alternatives (for example, compiling with cxx_static_assert implies the >> use of stdlibc++ or libc++ with Clang by default but there is a way to >> use the other >> instead). The COMPATIBLE_INTERFACE features may also be used to ensure >> that targets which link together all use the same standard library. > > Originally I was thinking we should just use the same -std= for linking > that we do for compilation, but don't we currently support compiling > different targets at different standard levels and then linking them? As I wrote, this is not about 'linking with a language standard level', which is not a concept which has meaning. This is about 'which standard library binary do we link to?'. In the case of GNU, we link to libstdc++.so. If we would link some targets to libstdc++ and others to libc++ we could not use them together because the standard library implementations are not binary compatibile with each other. See also what I wrote before about using COMPATIBLE_INTERFACE properties to diagnose this at cmake time. > BTW, I noticed in cmLocalGenerator::AddCompileOptions that we currently > mutate the configure step result by setting target properties like > _STANDARD during generation. Also, this is done with one "config" > value which may not be appropriate in multi-config generators. Interesting. I've filed a bug here: http://public.kitware.com/Bug/view.php?id=15773 Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015773]: Transitive config-specific compile features may be buggy
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15773 == Reported By:Stephen Kelly Assigned To: == Project:CMake Issue ID: 15773 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2015-10-07 21:08 CEST Last Modified: 2015-10-07 21:08 CEST == Summary:Transitive config-specific compile features may be buggy Description: >From the mailing list: > BTW, I noticed in cmLocalGenerator::AddCompileOptions that we currently > mutate the configure step result by setting target properties like > _STANDARD during generation. Also, this is done with one "config" > value which may not be appropriate in multi-config generators. == Issue History Date ModifiedUsername FieldChange == 2015-10-07 21:08 Stephen Kelly 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-developers] [Review Request] New module: IncludeUrl
Hello all, Please review the "IncludeUrl" topic[1] that adds a new "IncludeUrl" module. This module adds the include_url command that is useful to download and include other CMake modules from a given url. [1]https://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/IncludeUrl The main use case for such a module is for groups that have several projects or CMake scripts, handled by different developers, that import the same CMake module that is sometimes updated, and they want to keep these files synchronized in all the projects. This is very hard to achieve when the developers are many and don't care too much about the build system. Instead of adding this file to each project, this module allows to put it somewhere, and automatically download and include it when required. This is not optimal in some cases, for example when network is not available, when packaging a project using build machines that may not have access to the network, or basically any case in which file(DOWNLOAD) is not optimal, but it can be useful in several other cases, for example for projects that are not going to be packaged any time soon, or that already depend on the network for some reason (e.g. ExternalProject) and for CMake scripts. This module has 3 main operation modes: * Normal mode: Always try to download the latest version of the file, but if the download fails use the last version available. * DOWNLOAD_ONCE mode: Download the file the only first time or (if used in combination with EXPECTED_HASH or EXPECTED_MD5) when the hash mismatches. * DOWNLOAD_ALWAYS mode: Never use a previously downloaded version of the file. If used with OPTIONAL can be used for a module that is not available all the time and should not be included in case the download fails. The topic comes with a broad set of unit tests. I tested only on local files, because I assume that the download part is already tested enough with unit tests for the file(DOWNLOAD) command. Also for now I tested it only on linux, therefore I expect some failure on other platforms... Thanks. Regards, Daniele -- 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: install universal iOS libraries
Hello,
thank you for working on this. This is really hairy stuff.
On 24/09/15 11:10, Ruslan Baratov via cmake-developers wrote:
> Patches help to install universal iOS (device + simulator) libraries by
> triggering some extra instructions (build + fuse) after "regular"
> library installation finished. This behavior controlled by CMake
> variable CMAKE_IOS_INSTALL_UNIVERSAL_LIBS.
some general remarks:
* iOS is not the only platform where the simulator / device situation is
problematic. Others are now watchOS and the upcoming tvOS (see
xcodebuild -showsdks). So it would make sense to replace the ios naming
in the method signatures with something more general.
* Does the patches handle Bundles and Frameworks properly?
* This functionality should be limited to XCODE Generator
0001-
* Could you make the CMAKE_IOS_INSTALL_UNIVERSAL_LIBS a two staged
property like CMAKE_INSTALL_RPATH / INSTALL_RPATH. That way one would be
able to enable this behavior for only some targets
0002-CMake-module-for-universal-iOS-library-install
* Could you avoid to hard-code architecture names like i386 or armv7 in
the module?
* In Xcode 7 (and maybe earlier) I see the following environment
variables when I install for Device:
> export CORRESPONDING_SIMULATOR_PLATFORM_NAME=iphonesimulator
> export CORRESPONDING_SIMULATOR_SDK_NAME=iphonesimulator9.0
> export SUPPORTED_PLATFORMS="iphonesimulator iphoneos"
> export SDK_NAME=iphoneos9.0
for Simulator:
> export CORRESPONDING_DEVICE_PLATFORM_NAME=iphoneos
> export CORRESPONDING_DEVICE_SDK_NAME=iphoneos9.0
> export SDK_NAME=iphonesimulator9.0
Could you use those variables to avoid hardcoding iphoneos/simulator in
the module?
> + install_universal_ios_remove_arch("${dev_libpath}" "i386")
> + install_universal_ios_remove_arch("${dev_libpath}" "x86_64")
Doing it the other way round (keeping only what's needed) looks saner to me.
> + install_universal_ios_remove_arch("${dev_libpath}" ...)
> +
> + install_universal_ios_remove_arch("${sim_libpath}" ...)
> +
> + set(cmd lipo -create ${src} ${dst} -output ${dst})
Would it be possible to just add selected architectures from src to dst
(via lipo -replace)? That way you would save some disk i/o and would
make the pruning step for src superfluous.
Thanks,
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: 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 0015772]: snprintf on msvc14 compiler
The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=15772 == Reported By:Garcia Sylvain Assigned To: == Project:CMake Issue ID: 15772 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-10-07 09:10 EDT Last Modified: 2015-10-07 09:10 EDT == Summary:snprintf on msvc14 compiler Description: The CheckFunctionExits module does not detect the new msvc14's snprintf function. Steps to Reproduce: Run 'cmake -G"Visual Studio 14 2015" .' on the attached CMakeLists.txt == Issue History Date ModifiedUsername FieldChange == 2015-10-07 09:10 Garcia Sylvain New Issue 2015-10-07 09:10 Garcia Sylvain File 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] Rename suffix of Mac OS Framework
Hi Brad,
A use case for example is when an InDesign plugin should be developed. The
InDesign plugin on Mac OS is a framework with the file extension
".InDesignPlugin".
It works if the "Xcode" generator is used and the target property
"XCODE_ATTRIBUTE_WRAPPER_EXTENSION" is set to "InDesignPlugin".
But it doesn't work if the "Unix Makefiles" generator is used.
See also https://cmake.org/Bug/view.php?id=14742
Best Regards
Roman
> Am 05.10.2015 um 17:31 schrieb Brad King :
>
>> On 10/01/2015 04:07 AM, Roman Wüger wrote:
>> set_target_properties(${PROJECT_NAME} PROPERTIES FRAMEWORK TRUE)
>>
>> Is there a way to rename the suffix ".framework"?
>
> Not currently. It is hard-coded here:
>
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGeneratorTarget.cxx;hb=679a5d21#l2981
>
> What is the use case for changing the framework extension?
> Doing so breaks the basic layout defined in "man ld":
>
> -framework name[,suffix]
> This option tells the linker to search for `name.frame-
> work/name' the framework search path. If the optional
> suffix is specified the framework is first searched for
> the name with the suffix and then without (e.g. look
> for `name.framework/name_suffix' first, if not there
> try `name.framework/name').
>
> -Brad
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015771]: GHS-MULTI Generator Uses Macros in GPJs Uncompatible With Older Versions
The following issue has been SUBMITTED.
==
https://public.kitware.com/Bug/view.php?id=15771
==
Reported By:iainmeikle
Assigned To:
==
Project:CMake
Issue ID: 15771
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2015-10-07 04:32 EDT
Last Modified: 2015-10-07 04:32 EDT
==
Summary:GHS-MULTI Generator Uses Macros in GPJs Uncompatible
With Older Versions
Description:
The GHS-MULTI generator adds the following to generated GPJ files:
{optgroup=GhsCommonOptions}.
Other than this, the GPJ files appear to work OK with older versions. This can
be alleviated by adding the following instead.
{isdefined(optgroup)}{optgroup=GhsCommonOptions}
Steps to Reproduce:
Use quite an old version of their tool chain.
Additional Information:
Unable to provide specific version information for the tool chain used.
==
Issue History
Date ModifiedUsername FieldChange
==
2015-10-07 04:32 iainmeikle 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-developers] Moving from Module to Target-based linking
Hey all,
is there any development going on towards providing FindXXX.cmake
wrapper modules that "convert" MODULE-mode results into CONFIG style
imported targets to consume?
correct me if i'm wrong here, but as more and more projects are being
cmake'ified and the config-mode is far more robust to
manage package-interdependencies, wouldn't it fuel this progress if
there was some sort of automatic imported target creation possible?
i've attached a template that is cmake-configured and has thus far been
able to work with all the 3rd party packages we've got involved (it's
also got some specific stuff - ignore).
it basically invokes the module mode and sets found libraries and paths
to an imported target (named after what was looked for)
which then can be consumed, much like the generated config files do.
if this is of general interest, i'm happy for some feedback and
suggestions how that could be of use in CMake.
- Daniel
--
Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a
+49 711 685 60044
# Appends a library to the list of interface_link_libraries
function(append_link_library TARGET LIB)
get_target_property(CURRENT_ILL
${TARGET} INTERFACE_LINK_LIBRARIES)
if (NOT CURRENT_ILL)
SET(CURRENT_ILL )
endif()
# Treat framework references different
if(APPLE AND ${LIB} MATCHES ".framework$")
STRING(REGEX REPLACE ".*/([A-Za-z0-9.]+).framework$" "\\1" FW_NAME ${LIB})
#message(STATUS "Matched '${FW_NAME}' to ${LIB}")
SET(LIB "-framework ${FW_NAME}")
endif()
set_target_properties(${TARGET} PROPERTIES
INTERFACE_LINK_LIBRARIES "${CURRENT_ILL};${LIB}")
endfunction()
function(messageo MSG)
message(STATUS "Find@PACKAGE_NAME@ wrapper: ${MSG}")
endfunction()
function(messaged MSG)
#message(STATUS "DEBUG Find@PACKAGE_NAME@ wrapper: ${MSG}")
endfunction()
messaged("Entering script. CMAKE_PREFIX_PATH: ${CMAKE_PREFIX_PATH}")
# Default: Not found
SET(@PACKAGE_CASENAME@_FOUND NO)
# The default way is to look for components in the current PREFIX_PATH, e.g. own build components.
# If the OC_SYSTEM_@PACKAGE_NAME@ flag is set for a package, the MODULE and CONFIG modes are tried outside the PREFIX PATH first.
if (NOT OC_SYSTEM_@PACKAGE_NAME@)
set(OC_SYSTEM_@PACKAGE_NAME@ NO) # set it to NO so that we have a value if none is set at all (debug output)
find_package(@PACKAGE_CASENAME@ ${@PACKAGE_CASENAME@_FIND_VERSION} CONFIG
PATHS ${CMAKE_PREFIX_PATH}
QUIET
NO_DEFAULT_PATH)
if (@PACKAGE_CASENAME@_FOUND)
set(@PACKAGE_NAME@_FOUND YES)
messageo("Found version ${@PACKAGE_CASENAME@_FIND_VERSION} at ${@PACKAGE_CASENAME@_DIR} in CONFIG mode")
endif()
else()
# If local lookup is enabled, try to look for packages in old-fashioned module mode and then config modes
messageo("System search enabled")
# Remove all paths resolving to this one here so that recursive calls wont search here again
set(_ORIGINAL_CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH})
set(_READDME )
get_filename_component(_THIS_DIRECTORY ${CMAKE_CURRENT_LIST_FILE} DIRECTORY)
foreach(_ENTRY ${_ORIGINAL_CMAKE_MODULE_PATH})
get_filename_component(_ENTRY_ABSOLUTE ${_ENTRY} ABSOLUTE)
if (_ENTRY_ABSOLUTE STREQUAL _THIS_DIRECTORY)
list(REMOVE_ITEM CMAKE_MODULE_PATH ${_ENTRY})
endif()
endforeach()
unset(_THIS_DIRECTORY)
unset(_ENTRY_ABSOLUTE)
# Make "native" call to find_package in MODULE mode first
messageo("Trying to find version ${@PACKAGE_CASENAME@_FIND_VERSION} on system in MODULE mode")
messaged("CMAKE_MODULE_PATH: ${CMAKE_MODULE_PATH}\nCMAKE_SYSTEM_PREFIX_PATH=${CMAKE_SYSTEM_PREFIX_PATH}\nPATH=$ENV{PATH}\nLD_LIBRARY_PATH=$ENV{LD_LIBRARY_PATH}")
# Temporarily disable the required flag (if set from outside)
SET(_PKG_REQ_OLD ${@PACKAGE_CASENAME@_FIND_REQUIRED})
UNSET(@PACKAGE_CASENAME@_FIND_REQUIRED)
# Remove CMAKE_INSTALL_PREFIX from CMAKE_SYSTEM_PREFIX_PATH - we dont want the module search to "accidentally"
# discover the packages in our install directory, collect libraries and then re-turn them into targets (redundant round-trip)
if (CMAKE_INSTALL_PREFIX AND CMAKE_SYSTEM_PREFIX_PATH)
list(REMOVE_ITEM CMAKE_SYSTEM_PREFIX_PATH ${CMAKE_INSTALL_PREFIX})
set(_readd YES)
endif()
# Actual MODULE mode find call
#message(STATUS "find_package(@PACKAGE_CASENAME@ ${@PACKAGE_CASENAME@_FIND_VERSION} MODULE QUIET)")
find_package(@PACKAGE_CASENAME@ ${@PACKAGE_CASENAME@_FIND_VERSION} MODULE QUIET)
# Restore stuff
SET(@PACKAGE_CASENAME@_FIND_REQUIRED ${_PKG_REQ_OLD})
if (_readd)
list(APPEND CMAKE_SYSTEM_PREFIX_PATH ${CMAKE_INSTALL_PREFIX})
endif()
unset(_readd)
# Restore the current module path
# This needs to be done BEFORE any calls in CONFIG find mode - if the found config has our
# xxx-config-dependencie
Re: [cmake-developers] [Review request] TopicFind GTK2_sigc++_c++11
On 06/10/2015 19:25, Brad King wrote: > On 10/06/2015 12:20 PM, Daniele E. Domenichelli wrote: >> I updated the topic according to your comments. The new commit is this: >> >> FindGTK2: Enable c++11 for sigc++ 2.5.1 or later >> https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=33eb8fa > > LGTM. Merged into next. Thanks, Daniele -- 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
