-
Notifications
You must be signed in to change notification settings - Fork 1.1k
XcodeBuild: pass deployment target from profile #18496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XcodeBuild: pass deployment target from profile #18496
Conversation
memsharded
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be doing too much in the same PR, specially when there are some potentially controversial things such as harcoding RUN_CLANG_STATIC_ANALYZER=NO in the command line.
Maybe it is better to split this PR, addressing first the bugfix, then the potential improvements in a separate one. Also, some test that covers the changes would be greatly appreciated, please ask us for support or guidance if you need, we might even contribute the tests ourselves.
| self._sdkroot, self._verbosity, target) | ||
|
|
||
| deployment_target_key = xcodebuild_deployment_target_key(self._os) | ||
| if deployment_target_key and self._os_version: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably the main and necessary fix?
I understand that if this is not provided, it will fail to build for iOS, watchOS, etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it's not provided, the setting from the Xcode project will be used, which may be not what the library user desires. Since profile defines OS version, it's natural to use it.
|
It also seems the PR broke some existing OSX-functional tests, please have a look https://github.com/conan-io/conan/actions/runs/15756189684/job/44412185234?pr=18496 (you an ignore the Windows-unit tests, that seems a temporary glitch). |
thanks, I fully agree with splitting. Are you fine with keeping the SYMROOT/OBJROOT change in this PR or it should also go to the other one? |
You convinced me that if not defining this it might pollute the source directory when But please wait a bit for the split, I am going to ask some colleague more knowledgeable than me in Apple for their feedback. |
|
FYI I'm heavily using changes from this PR quite successfully so far, would be great to get a review that I could proceed |
memsharded
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still need to check with @jcar87 about this, but it would be nice to get the minor build_options=[] and the RUN_CLANG_STATIC_ANALYZER fixed in the meantime too.
|
Also it seems there are a couple of builds broken, I haven't check them yet, but it would be necessary to have them green too. |
memsharded
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have checked with the team, and the issue seems that this PR is being a bit confusing, doing different things:
- adding new optional arguments, not fully clear all use cases
- changing some command layout things with SYMROOT, OBJROOT. These seems should be defined at the project level, or in any case at the toolchain level. Because otherwise, normal flow like
conan install + IDE/xcodebuild direct user invocationwill do something different - The main fix which is passing the deployment target to the command line
I'd say to remove all the other things, and leave just the definition of the deployment target, which could be considered a bug fix if I understood correctly, if this is not passed, the conan build will not build the intended thing? That way we can move the PR forward, the other improvements can be discussed later in a different issue/PR, as they seem less priority
9fa5da6 to
0ac6270
Compare
|
Removed all the new features from the PR but added 2 small fixes - quoting project path and target name as they can have spaces.
I can't really agree with this.
Will open a separate PR with all the new features. |
memsharded
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, thanks for doing the changes!
We can continue in other threads for the other features
| """ | ||
| target = "-target {}".format(target) if target else "-alltargets" | ||
| cmd = "xcodebuild -project {} -configuration {} -arch {} " \ | ||
| target = "-target '{}'".format(target) if target else "-alltargets" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We usually quote with double quotes, it is a bit more cross-platform, though I understand this isn't cross-platform at all, so most likely not an issue. Wdyt @czoido?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be fine to use single quotes as this should never run on windows cmd
It would be great to have the feedback of @jcar87 here, I am not a OSX user (it can be discussed in the new PR too) |
opened #18668 with the new features |
Thanks. I am aiming to include this PR in the next release, this split will certainly help in this. |
|
Hi @kambala-decapitator, |

Changelog: Fix: Pass deployment target from profile to
XcodeBuild.Changelog: Fix: Project path and target name are quoted now for
XcodeBuild.Docs: conan-io/docs#4129
developbranch, documenting this one.