Add XcodePlugin support

[tboogh]

First thanks for the awesome addition of a build plugin!

This PR is pretty basic and just cope-pastes the existing code with a few modifications to add support for Xcode 14 XcodeProject build plugins.

I tried to keep as much as possible, one thing I'm unsure about is the PRODUCT_MODULE_NAME which I couldn't find a counterpart to.

[sveinhal]

I'm not in a position to review this PR, but I'd like a solution to the problem that this PR seeks to solve. Wether that is accepting this as-is or moving it forward in some direction, I don't know.

Can someone please either merge, or give feedback so this can move forward?

[scsinke]

@djbe can this PR get some ❤️ ?

[knellr]

I'd like to see this merged. I've confirmed the PRODUCT_MODULE_NAME environment variable would be available to SwiftGen without being explicitly configured (I modified the value in my project file's build settings to distinguish it from the target / product name).

It would also be good to update the command plugin to support Xcode projects but one step at a time!

[st4rrk]

I hope it will be integrated soon 👍
I've tried your branch but I couldn't find a way to make the generation work.
The yaml is in root folder, and works when using command line.
(I couldn't find the log of the plugin execution, do you have any idea where it can be found?)

[pietbrauer]

This works as expected for me:

1. Add the Package Plugin from the branch locally to Xcode

2. Add the Package Plugin as a Build Tool Plugin

3. Verified that it works when changing the Localizable.strings file

Would love to see this merged.

[st4rrk]

I think the difference is that I forked his projet and used the remote reference of the plugin module in xCode, I was not using it locally. 🤔
Is it thought to be integrated locally? And do you know how to check the plugin logs in case of a problem? (btw xCode 14.1 resolves the cpu usage problem (in case you were using it locally because of that))

[st4rrk]

For more details

The xCode hierarchy:

The yaml conf:

The working command line:

Then I use the plugin:

Here I tried both, not sure which one I am supposed to use tho

Finally, the xCode plugin command is running:

(the file Generated string file was previously emptied again, to ensure the plugin does the job)

But here I'm blocked, because the command looks like it runs and works, but my file still end up being empty.
Any insight?

ps: I also tried to put the yaml inside the LocasliationExploration folder instead of root, but still same results

ps2: adding the plugin as pietbrauer did in the Build Phrases -> Run Build Tool Plug-ins DOES WORK, so it looks like only the instanciation from the Project Navigator isn't working? (but these are different usage :/ )

[knellr]

@st4rrk have you tried adding the ${DERIVED_SOURCES_DIR}/ prefix to your output files or output_dir in the yml as described in the README? https://github.com/SwiftGen/SwiftGenPlugin#add-a-swiftgen-config

[st4rrk]

@knellr I try to generate code into the xcodeproj's location (in the "Generated/" folder idealy), so that I can track it with git. I don't want to only generate file directly into the working_directory, and the README seems to only cover the case where you use the plugin within a Package+working_directory context.

Maybe I missunderstand the goal of the "SwiftGen-Generate" command? (which goal would be to manually trigger the generation into a working_directory?)

[knellr]

@st4rrk this PR only updates the build tool plugin, and unfortunately build tool plugins aren't permitted to write the source directory. Command plugins are permitted to do this once you give explicit permission, but have to be manually invoked.

As you mention the SwiftGen-Generate command it sounds like maybe your issues are unrelated to this PR?

From past experience it's possible that you haven't given permission for the command plugin to access the package directory?

[romero-ios]

Any reason this PR can't get merged? Checking out the fork and using this branch, my setup works and everything is great.
Using the main repo, nothing else changed, and I always get the error Plugin doesn't support Xcode projects (it doesn't use the XcodeProjectPlugin library)

[MaxencemPro]

This PR can now be merged ?

[ckuburlis]

@djbe could we get a heads up if this is the correct approach, or if you know anyone else able to review/approve it?
It works well for me and would be good to see it merged in.

[ehyche]

It would be great if this could be merged. I could use this as well.

[n-giaccone]

I tested it on my local machine and it works very well, if this PR could be merged that would be great.

[captainhaddockfr35]

It would be great if this could be merged :)

[edoardop13]

Please merge this pull request 🙏

[p4checo]

Bumping this. @djbe can you please review? 🙏🏼

[rrroyal]

bumping again

[nandhavadivel]

Please merge

[tomasharkema]

bump

[bloxidge]

bump

[prateekMindTickle]

please merge this PR

[NameX44]

Hi, we need a merge of this PR too :)

[giginet]

In the current implementation, it cares only about a top-level configuration.
We have to care about a target-specified configuration.

Unfortunately, we can't fetch the top-level directory of each target from XcodeBuildToolPlugin, because a top-level directory of targets doesn't always exist in xcodeproj.

But most likely it will be $SRCROOT/TARGET_NAME.

So it's better to add target.displayName as a search path.

Suggested change

	let configurations: [Path] = [context.xcodeProject.directory]
	.map { $0.appending("swiftgen.yml") }
	.filter { fileManager.fileExists(atPath: $0.string) }
	let configurations: [Path] = [
	context.xcodeProject.directory,
	context.xcodeProject.directory.appending(subpath: target.displayName),
	]
	.map { $0.appending("swiftgen.yml") }
	.filter { fileManager.fileExists(atPath: $0.string) }

[Svantulden]

This works well for my multi-target situation, thanks!

[Svantulden]

I see @AliSoftware is also one of the main maintainers and hasn't been tagged yet. Could you take a look at this PR? 🙏

[markst]

Has this been tested on Xcode 15? Seem Xcode 15 has some stricter rules around write permissions to outputFilesDirectory

[BrentMifsud]

has there been any updates on this? This PR has been open for quite some time and it seems like the owners of this repo are nowhere to be seen.

[BrentMifsud]

Has this been tested on Xcode 15? Seem Xcode 15 has some stricter rules around write permissions to outputFilesDirectory

just tested this. Seems like the permissions are an issue in Xcode 15.

Getting the following message:

Error: You don’t have permission to save the file “Strings.swift” in the folder “Generated”.

EDIT:

I figured it out.

There is a new environment variable that points to a work directory that build plugins can access: ${DERIVED_SOURCES_DIR}/

The simplest solution is to make note in the readme that you need to use that env variable as your work directory root.

Alternatively, this PR can set that as the work directory for the plugins. And any directory provided in the swift gen configuration file can be appended to the end of that path.

[Flatout73]

bump

[duszmox]

Bump

[tboogh]

Has this been tested on Xcode 15? Seem Xcode 15 has some stricter rules around write permissions to outputFilesDirectory

just tested this. Seems like the permissions are an issue in Xcode 15.

Getting the following message:

Error: You don’t have permission to save the file “Strings.swift” in the folder “Generated”.

EDIT:

I figured it out.

There is a new environment variable that points to a work directory that build plugins can access: ${DERIVED_SOURCES_DIR}/

The simplest solution is to make note in the readme that you need to use that env variable as your work directory root.

Alternatively, this PR can set that as the work directory for the plugins. And any directory provided in the swift gen configuration file can be appended to the end of that path.

I'll have a look into it

[tboogh]

Started looking into this more now when I had time and we wanted to start using it in our work projects. Unfortunately the changes in Xcode 16 to deny writing in the source file directory makes the usage of Swiftgen as a precommand build tool a little pointless. The whole point is to have assets generated upfront so they can be used in the compile code and also fail compilation if something that was used is removed. So compiling to the DERIVED_FILES_DIR is possible but not really that helpful. I think a better approach is to investigate implementing it as a command plugin in Xcode instead.