View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0014736 | CMake | CMake | public | 2014-02-05 05:44 | 2015-11-02 09:13 | ||||
Reporter | lando | ||||||||
Assigned To | Brad King | ||||||||
Priority | low | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | Apple | OS | OSX | OS Version | 10.9.1 | ||||
Product Version | CMake 2.8.12.1 | ||||||||
Target Version | CMake 3.3 | Fixed in Version | CMake 3.3 | ||||||
Summary | 0014736: Xcode warning due to set ARCHS (CMAKE_OSX_ARCHITECTURES) variable in project | ||||||||
Description | I'm using CMake-generated Xcode-projects in Xcode 5.0.2 and get a warning by Xcode that it wants to "Update to recommended settings", specifically to set to "Automatically Select Architectures". This is due to a set ARCHS-variable in the pbxproj-file of the Xcode project. Alas, even setting the variable to the Xcode default value $(ARCHS_STANDARD) via CMAKE_OSX_ARCHITECTURES does not help. Xcode complains as long as the line is present in the project file. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | fix_xcode_warning.patch [^] (1,746 bytes) 2015-03-27 08:46 [Show Content] | ||||||||
Relationships | |||||||||||
|
Relationships |
Notes | |
(0035045) Brad King (manager) 2014-02-06 10:37 |
By setting CMAKE_OSX_ARCHITECTURES explicitly you are telling CMake what to put in ARCHS. If you don't set it then CMake generates $(ARCHS_STANDARD_32_64_BIT), which was the default as of Xcode 3.2 and still works in 5. However, it also enables ONLY_ACTIVE_ARCH to build only for the host. When you set CMAKE_OSX_ARCHITECTURES to $(ARCHS_STANDARD) then Xcode is complaining that the settings are per-target rather than project-wide. BTW, CMake does not officially support this because it expects a ;-list of architecture names in CMAKE_OSX_ARCHITECTURES. In either case, Xcode is complaining that the project settings make it difficult for a human to make sweeping changes to the architecture selection through the IDE. For a CMake-generated project this doesn't matter because it should not be modified by hand through the IDE anyway. |
(0035048) lando (reporter) 2014-02-07 07:56 |
Quote: "By setting CMAKE_OSX_ARCHITECTURES explicitly you are telling CMake what to put in ARCHS. If you don't set it then CMake generates $(ARCHS_STANDARD_32_64_BIT), which was the default as of Xcode 3.2 and still works in 5." Yes, I already looked that up in the source code. Unfortunately, that seems to make it impossible to create a warning-free Xcode project for us. As the warning pops up as any compiler or linker warning, this glitch appears in our automatic build test logs. Admittedly, that's not exactly severe, but... *shrug* |
(0035049) Brad King (manager) 2014-02-07 08:34 |
Re 0014736:0035048: Using the Xcode IDE by hand without CMake, how does one create a project that has two targets such that one builds with one architecture and another builds with a different architecture but Xcode does not produce this warning? |
(0036496) Jan Rüegg (reporter) 2014-07-30 06:31 |
Yes, I agree, this is still the case. To solve the issue, the "ARCHS" line has to be removed completely from the project file. (This is by the way what the IDE does when you press "update to recommended settings"). However, currently there is no way to do this from a CMakeLists.txt file, since it is hardcoded in http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CompilerId/Xcode-3.pbxproj.in [^] |
(0037035) birarda (reporter) 2014-10-15 18:19 |
Found this while searching for a solution to the "update to recommended settings" warning. Would it be possible to have ARCHS removed from the standard project file unless explicitly set via CMAKE_OSX_ARCHITECTURES? |
(0037756) Laurent Demailly (reporter) 2015-01-20 13:59 |
my project doesn't have architecture and does get this warning (gory details in http://www.cmake.org/Bug/view.php?id=15360 [^] ) |
(0038345) Jan Rüegg (reporter) 2015-03-27 08:47 |
I just uploaded a patch with a possible fix. This will not set the ARCHS flag to some variable, but just leave it empty, letting XCode fill the variable itself with what is most correct. On my machine, this works fine and fixes the issue. |
(0038346) Brad King (manager) 2015-03-27 09:01 |
Can anyone answer my question in 0014736:0035049? Xcode is basically warning that we're using a feature they provide. |
(0038350) Jan Rüegg (reporter) 2015-03-27 12:19 |
Re http://www.cmake.org/Bug/view.php?id=14736#c38346 [^] As far as I understand XCode automatically selects for what architectures to compile depending on the hardware attached to the phone, or the requirements of an upload to the app store. Setting it manually interferes with that by forcing XCode to compile for a certain architecture. But that's just my guess. Its's the same with a compiler warning: You are allowed to do it (for example, create an unused variable), but the compiler will warn you that its not best practise to do so... |
(0038351) Brad King (manager) 2015-03-27 13:18 |
I've drafted a commit to fix this: Xcode: Set ARCHS only when CMAKE_OSX_ARCHITECTURES is specified http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b76b52c0 [^] |
(0038352) Brad King (manager) 2015-03-27 13:23 |
Re 0014736:0038350: Compilers warn about cases that are generally known to not be useful. My question is about the case when the developer knows what he/she is doing and really wants to build some binaries for one architecture and some for another. There does not seem to be a warning-free way to do this. Anyway, the commit linked in 0014736:0038351 should fix this warning. The commit message justifies the change for the general use case. The lack of such justification in the discussion here is why I hesitated to make this change for so long. |
(0039750) Robert Maynard (manager) 2015-11-02 09:13 |
Closing resolved issues that have not been updated in more than 4 months. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2014-02-05 05:44 | lando | New Issue | |
2014-02-06 10:37 | Brad King | Note Added: 0035045 | |
2014-02-07 07:56 | lando | Note Added: 0035048 | |
2014-02-07 08:34 | Brad King | Note Added: 0035049 | |
2014-07-30 06:31 | Jan Rüegg | Note Added: 0036496 | |
2014-10-15 18:19 | birarda | Note Added: 0037035 | |
2015-01-20 09:03 | Brad King | Relationship added | has duplicate 0015360 |
2015-01-20 13:59 | Laurent Demailly | Note Added: 0037756 | |
2015-01-27 14:01 | Brad King | Relationship added | has duplicate 0015376 |
2015-03-27 08:46 | Jan Rüegg | File Added: fix_xcode_warning.patch | |
2015-03-27 08:47 | Jan Rüegg | Note Added: 0038345 | |
2015-03-27 09:01 | Brad King | Note Added: 0038346 | |
2015-03-27 12:19 | Jan Rüegg | Note Added: 0038350 | |
2015-03-27 13:18 | Brad King | Note Added: 0038351 | |
2015-03-27 13:18 | Brad King | Assigned To | => Brad King |
2015-03-27 13:18 | Brad King | Status | new => resolved |
2015-03-27 13:18 | Brad King | Resolution | open => fixed |
2015-03-27 13:18 | Brad King | Fixed in Version | => CMake 3.3 |
2015-03-27 13:18 | Brad King | Target Version | => CMake 3.3 |
2015-03-27 13:23 | Brad King | Note Added: 0038352 | |
2015-11-02 09:13 | Robert Maynard | Note Added: 0039750 | |
2015-11-02 09:13 | Robert Maynard | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |