SwiftPM Xcode Integration

One of our goals for the Swift Package Manager is excellent and delightful integration with Xcode.

To this end we are going to start work on initial integration by making SwiftPM able to generate Xcode project files. This is not the long-term design we want for the Xcode integration, but it is a concrete step we can take now which will allow Xcode users to adopt Swift packages and use them in their products. We expect this to significantly increase the adoption of SwiftPM and give us more feedback and experience, which will inform the eventual full integration design. This will also enable Swift packages to be built for Apple's iOS, Apple TV, and watchOS platforms, in addition to OS X.

The code for this will be written in the open as part of the SwiftPM open source project and we will begin the feature presently.

We would like to emphasize again that proper and tight integration with Xcode is our long-term goal, but in the near-term we consider this a good intermediary solution—making real Swift package use possible.

Our design for this feature is as follows:

* Generate a single xcodeproj from the command line for a Package.swift
* The xcodeproj will contain targets for all packages and their modules
* Require the user to add this xcodeproj to their main project and link the dependency by hand.

In addition to allowing users to adopt Swift packages in their Xcode projects through this mechanism, this will allow package authors to use Xcode to work on their packages.

We are also considering a feature that auto-regenerates the xcodeproj if the user changes their Package.swift or edits any of their package sources, though parts of that feature would be built in Xcode and not in the open source project. We are aware of the frustrating aspects of other systems that generate Xcode projects and will be looking at ways to mitigate the problems that come with this solution.

We're looking forward to your feedback on this intermediary solution as it evolves!

Max

It's nice to see progress on the package manager. I manually maintain an
xcodeproj for the SwiftGL project. Here's a couple things in there which
are off the beaten path.

I use GLFW3 for the demos. This is a simple C API for which I made a
modulemap package. Two actually, because the linked libraries differ on
Linux and Mac. So I end up using this:

if os(Linux)
    package.dependencies.append(
        Package.Dependency.Package(url: "
https://github.com/AE9RB/SwiftCGLFW3Linux.git", majorVersion: 1)
    )
#else
    package.dependencies.append(
        Package.Dependency.Package(url: "
https://github.com/AE9RB/SwiftCGLFW3.git", majorVersion: 1)
    )
#endif

This works just fine from the pm build. But I have to add the /usr/lib and
/usr/include paths to XCode manually.

So that's it I think. Conditionals in Package.swift, and paths for
modulemaps. Hopefully these can be supported in the xcodeproj generator.

It's not clear if we will have to combine all the swift package
dependencies manually in Xcode. That would be unfortunate. I see some web
server libraries coming up and these tend to grow to dozens of dependencies.

-david GitHub - AE9RB/SwiftGL: This project has moved.

···

On Fri, Feb 19, 2016 at 9:55 AM, Max Howell via swift-evolution < swift-evolution@swift.org> wrote:

One of our goals for the Swift Package Manager is excellent and delightful
integration with Xcode.

To this end we are going to start work on initial integration by making
SwiftPM able to generate Xcode project files. This is not the long-term
design we want for the Xcode integration, but it is a concrete step we can
take now which will allow Xcode users to adopt Swift packages and use them
in their products. We expect this to significantly increase the adoption of
SwiftPM and give us more feedback and experience, which will inform the
eventual full integration design. This will also enable Swift packages to
be built for Apple's iOS, Apple TV, and watchOS platforms, in addition to
OS X.

The code for this will be written in the open as part of the SwiftPM open
source project and we will begin the feature presently.

We would like to emphasize again that proper and tight integration with
Xcode is our long-term goal, but in the near-term we consider this a good
intermediary solution—making real Swift package use possible.

Our design for this feature is as follows:

* Generate a single xcodeproj from the command line for a Package.swift
* The xcodeproj will contain targets for all packages and their modules
* Require the user to add this xcodeproj to their main project and link
the dependency by hand.

In addition to allowing users to adopt Swift packages in their Xcode
projects through this mechanism, this will allow package authors to use
Xcode to work on their packages.

We are also considering a feature that auto-regenerates the xcodeproj if
the user changes their Package.swift or edits any of their package sources,
though parts of that feature would be built in Xcode and not in the open
source project. We are aware of the frustrating aspects of other systems
that generate Xcode projects and will be looking at ways to mitigate the
problems that come with this solution.

We're looking forward to your feedback on this intermediary solution as it
evolves!

Max
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

For Xcode builds, if I install a C dependency via Homebrew, then include it
with a module map, will it be copied into the application bundle when
archiving—say, for the App Store?

Jeff Kelley

SlaunchaMan@gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan&gt; |
jeffkelley.org

···

On Fri, Feb 19, 2016 at 12:55 PM, Max Howell via swift-evolution < swift-evolution@swift.org> wrote:

One of our goals for the Swift Package Manager is excellent and delightful
integration with Xcode.

To this end we are going to start work on initial integration by making
SwiftPM able to generate Xcode project files. This is not the long-term
design we want for the Xcode integration, but it is a concrete step we can
take now which will allow Xcode users to adopt Swift packages and use them
in their products. We expect this to significantly increase the adoption of
SwiftPM and give us more feedback and experience, which will inform the
eventual full integration design. This will also enable Swift packages to
be built for Apple's iOS, Apple TV, and watchOS platforms, in addition to
OS X.

The code for this will be written in the open as part of the SwiftPM open
source project and we will begin the feature presently.

We would like to emphasize again that proper and tight integration with
Xcode is our long-term goal, but in the near-term we consider this a good
intermediary solution—making real Swift package use possible.

Our design for this feature is as follows:

* Generate a single xcodeproj from the command line for a Package.swift
* The xcodeproj will contain targets for all packages and their modules
* Require the user to add this xcodeproj to their main project and link
the dependency by hand.

In addition to allowing users to adopt Swift packages in their Xcode
projects through this mechanism, this will allow package authors to use
Xcode to work on their packages.

We are also considering a feature that auto-regenerates the xcodeproj if
the user changes their Package.swift or edits any of their package sources,
though parts of that feature would be built in Xcode and not in the open
source project. We are aware of the frustrating aspects of other systems
that generate Xcode projects and will be looking at ways to mitigate the
problems that come with this solution.

We're looking forward to your feedback on this intermediary solution as it
evolves!

Max
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

For Xcode builds, if I install a C dependency via Homebrew, then include it with a module map, will it be copied into the application bundle when archiving—say, for the App Store?

We don’t initially intend to support module map packages with this integration.

Not that we never will, but this part of the integration is not yet designed. We’ll revisit this question once the first iteration is complete.

Hi,

What kind of target will be made in the Xcode project? Specifically, will
it be a static library or a framework? In my experience, frameworks play
better with sourcekit and generally require less configuration in Xcode.

The folks behind Zewo made a tool to help us manage our large dependency
graph that generates complete xcode projects with subprojects and targets
(it also does a few other things, but those aren't important). As a side
effect it also supports modulemaps with no extra configuration. It
generates frameworks (not static libraries) for the reasons described
earlier, but I'm sure it would be trivial to change it to work the other
way.

The tool can be found here: https://github.com/zewo/zewo-dev\. Unfortunately
it had to be made in ruby because of the xcodeproj gem but I believe it
could still be a useful reference.

Dan

···

On Fri, Feb 19, 2016 at 11:21 AM Max Howell via swift-build-dev < swift-build-dev@swift.org> wrote:

> For Xcode builds, if I install a C dependency via Homebrew, then include
it with a module map, will it be copied into the application bundle when
archiving—say, for the App Store?

We don’t initially intend to support module map packages with this
integration.

Not that we never will, but this part of the integration is not yet
designed. We’ll revisit this question once the first iteration is complete.

_______________________________________________
swift-build-dev mailing list
swift-build-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev

--
Dan Appel

What kind of target will be made in the Xcode project? Specifically, will it be a static library or a framework?

Frameworks.

The folks behind Zewo made a tool to help us manage our large dependency graph that generates complete xcode projects with subprojects and targets (it also does a few other things, but those aren't important). As a side effect it also supports modulemaps with no extra configuration. It generates frameworks (not static libraries) for the reasons described earlier, but I'm sure it would be trivial to change it to work the other way.

The tool can be found here: https://github.com/zewo/zewo-dev\. Unfortunately it had to be made in ruby because of the xcodeproj gem but I believe it could still be a useful reference.

Thanks for the link, a very interesting project.

Excellent news!

At the moment I have a workflow that uses xcconfig files and XCake:
    GitHub - igor-makarov/xcake: 🍰 Describe Xcode projects in a human readable format and (re)generate one on demand.
XCake sounds similar to zewo, by the sounds of it, I think its author is
active on this list.

The main reason for my workflow is because it makes it much easier to make
new modules, copy configuration, and resolve merge conflicts.

In that context, I have a few questions:
* Is it intended that the generated Xcode project will be checked-in?
* Will the project duplicate information that SwiftPM specifies? file
references? configuration?
* Will the rebuild clobber project configuration that SwiftPM can't
specify? This is probably fine. Maybe Xcode should make configuration
read-only in generated projects.

···

On Saturday, 20 February 2016, Max Howell via swift-evolution < swift-evolution@swift.org> wrote:

What kind of target will be made in the Xcode project? Specifically, will
it be a static library or a framework?

Frameworks.

The folks behind Zewo made a tool to help us manage our large dependency
graph that generates complete xcode projects with subprojects and targets
(it also does a few other things, but those aren't important). As a side
effect it also supports modulemaps with no extra configuration. It
generates frameworks (not static libraries) for the reasons described
earlier, but I'm sure it would be trivial to change it to work the other
way.

The tool can be found here: https://github.com/zewo/zewo-dev\.
Unfortunately it had to be made in ruby because of the xcodeproj gem but I
believe it could still be a useful reference.

Thanks for the link, a very interesting project.

In that context, I have a few questions:
* Is it intended that the generated Xcode project will be checked-in?

It’s up to you, but certainly it will not be required and we will recommend NOT editing the generated project.

* Will the project duplicate information that SwiftPM specifies? file references? configuration?

Yes, because it will be generated, consider it a build artefact.

* Will the rebuild clobber project configuration that SwiftPM can't specify? This is probably fine. Maybe Xcode should make configuration read-only in generated projects.

Yes… don’t edit the projects! ;)

Thanks, that's what I expected, and is what I was hoping for.

My main point then is that I expect users won't realise their changes will
be clobbered. It would be good if Xcode's configuration UI is read-only for
these projects. At least for v1, if the engineering cost is sufficiently
low.

···

On Saturday, 20 February 2016, Max Howell <max.howell@apple.com> wrote:

> In that context, I have a few questions:
> * Is it intended that the generated Xcode project will be checked-in?

It’s up to you, but certainly it will not be required and we will
recommend NOT editing the generated project.

> * Will the project duplicate information that SwiftPM specifies? file
references? configuration?

Yes, because it will be generated, consider it a build artefact.

> * Will the rebuild clobber project configuration that SwiftPM can't
specify? This is probably fine. Maybe Xcode should make configuration
read-only in generated projects.

Yes… don’t edit the projects! ;)

Yes we hope to make them read only somehow.

···

On Feb 19, 2016, at 5:20 PM, Andrew Bennett <cacoyi@gmail.com> wrote:

On Saturday, 20 February 2016, Max Howell <max.howell@apple.com> wrote:
> In that context, I have a few questions:
> * Is it intended that the generated Xcode project will be checked-in?

It’s up to you, but certainly it will not be required and we will recommend NOT editing the generated project.

> * Will the project duplicate information that SwiftPM specifies? file references? configuration?

Yes, because it will be generated, consider it a build artefact.

> * Will the rebuild clobber project configuration that SwiftPM can't specify? This is probably fine. Maybe Xcode should make configuration read-only in generated projects.

Yes… don’t edit the projects! ;)

Thanks, that's what I expected, and is what I was hoping for.

My main point then is that I expect users won't realise their changes will be clobbered. It would be good if Xcode's configuration UI is read-only for these projects. At least for v1, if the engineering cost is sufficiently low.