Ability to set a couple of project/target settings?

[smackie]

As I work through converting our (huge) project files to xcodegen, I've found a couple of things that I can't resolved. I've looked at the Swift so I'm guess these aren't supported (yet) but figured I'd ask

• Project flag to turn off automatically generating schemes for every target. Ideally just for a list of targets and/or a class of target. For example, I have a lot of libraries. Don't need schemes for them. But schemes for the gtest applications and final apps would be fine.

• Target flag to disable copying headers. I don't really need them to be copied and I'd probably prefer just to suppress the "copy headers" step. Being able to flip the "Only copy on install" option would be a good workaround.

Any thoughts? The first seems relatively straightforward as part of the project definition. The second looks tricker from the code but flipping the "Only copy on install" option might be easier depending on what xcodeproj supports (I guess).

Cheers!

Scott...

[smackie]

Dug down a bit into the second issue a bit. It does look like there's logic in the code to suppress copying when the target is a static library but this doesn't appear to be working. For reference, the target looks like this

  foo-log:
    type: library.static
    platform: macOS
    sources:
      - path: foo/foo-log
        excludes:
          - "unit-test"
          - "Makefile*"
          - "src/Makefile*"
          - "*.mk"

I have loads of targets like this (the xcode build is overlaid on top of native linux build). The actual directory layout is

foo-log -+- src
         +- unit-test
         +- include

There are headers in the src directory too. If I get a chance, I'll try to run the config through with xcodegen in the debugger to see what's happening in in the target generation code.

[yonaskolb]

Hi @smackie

In terms of the schemes, XcodeGen doesn't actually generate a scheme for every target by default. (Adding something like that is discussed here #215). From a bit of an investigation, what I believe you're experiencing is Xcode itself automatically adding schemes for targets that don't have them when you open the project. You can turn off this behaviour by unchecking Autocreate schemes within Manage schemes at the top left.

This property is set in a file that isn't touched by Xcodegen (and can't currently, as it's not supported by xcodeproj). You should be able to set that property and check in the file it writes to (WorkspaceSettings.xcsettings) and then regenerate. The downside of this is that your project will look like it has a project.pbx checked in, but it's only a small file within that. This is the same if you have private settings in the project (eg breakpoints).
All this should probably be added to the documentation. If you find a better solution now that you know the cause, please let me know

Regarding the copy files, the best person to answer this would be @brentleyjones as he built most of that infrastructure

[brentleyjones]

There is no way currently to disable the static library copy files phase. I’ll look into build settings that can help suppress that.

It can’t just be “copy only on install”, since they are needed during development as well (in place of what a dynamic framework does during its Copy Header phase), without the phase other modules can’t find module maps or headers (unless you explicitly include header search paths to the source directories).

_{Sent with GitHawk}

[smackie]

This property is set in a file that isn't touched by Xcodegen (and can't currently, as it's not supported by xcodeproj).

Ah. Okay. I see this came up last year as a question to the xcodeproj folks. As we wrap the generation of the project with Xcodegen in a python wrapper, what I might do is generate the plist file and insert it gently into the project after generation (we have a bazillion targets but only a few real schemes are required). I'm really trying to avoid having the project generation seen as anything but dynamic (from my user's PoV).

Thanks!

[smackie]

There is no way currently to disable the static library copy files phase. I’ll look into build settings that can help suppress that.

Okay - thanks! I'll accept that my build is slightly unusual but it'd be helpful to be able to tweak this stuff.

It can’t just be “copy only on install”, since they are needed during development as well (in place of what a dynamic framework does during its Copy Header phase), without the phase other modules can’t find module maps or headers (unless you explicitly include header search paths to the source directories).

I guess what I meant here was this -

Control over either the "copy only on install" flag or even being able to set the default include subpath (so I can safely tuck them in a stage directory) would be useful. In fact, if I could set an absolute path (as you can directly in Xcode), that'd be just fine as an alternative (and maybe more useful for other folks)

Cheers!

Scott...

[PeqNP]

We had the same issue in regards to all of our modules having a respective scheme. @yonaskolb's suggestion to uncheck "Autocreate schemes" was the solution. However, the schemes that exist in this list will not go away immediately.

It's probably important to know that we use cocoapods. Therefore, after pod install is ran, a Project.xcworkspace will be created. The process is:

0. Pre-build cleanup (explained later)
1. Run xcodegen
2. Run pod install (workspace is created)
3. Open your Project.xcworkspace
4. Select list of schemes and select "Manage schemes"
5. Uncheck "Autocreate schemes"
6. git add Project.xcworkspace/xcshareddata/WorkspaceSettings.xcsettings (you may need to add git add -f if you've added *.xcworkspace in your .gitignore.

Now that we have a WorkspaceSettings checked in, we updated our pre-build cleanup process to restore the workspace to contain only this file. So, before step 1, what we do is rm -rf Project.xcworkspace and then checkout the workspace so that it contains only the workspace settings file (just a convenient way to revert the workspace to its original state).

Run steps 1, 2, and 3. You'll now notice that module schemes are no longer in the list.