yonaskolb / yonaskolb/XcodeGen

[Question] Generating Multiple Projects - Best Practices?

Open
#776 0 comments 19 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Swift
Stars
8.8k
Forks
908
Avg merge
17d 14h
Merged PRs (30d)
2

Description

The work with projectReferences is great, especially with the addition to embedding sub projects in #570! With the project I work on, we currently split our app project from our frameworks project so as a result I have two separate project.yml files that each are used to generate the project for development.

Each time I checkout/pull, the regeneration flow is like this:

$ mint run yonaskolb/XcodeGen xcodegen --spec Frameworks/project.yml --project Frameworks/
$ mint run yonaskolb/XcodeGen xcodegen --spec App/project.yml --project App/
$ bundle exec pod install --clean-install

While this works, one thing that gets to me a little is the fact that I can't leverage the --use-cache argument along with postGenCommand to avoid regenerating the pods project (and workspace) in the event that there is no change.

I've seen a lot of recent tickets/discussions about people using project references so I'm wondering if there is a way that we could improve this kind of workflow to take advantage of caching capabilities?

I've seen the old discussion about generating workspaces in #168 however it doesn't look like there has been any movement on that, and maybe its a bit more complex than I thought in my comment at the end of that thread.

Another thing I was thinking was to potentially extend the projectReferences option even further with something like this:

projectReferences:
  Frameworks:
    path: Frameworks/Frameworks.xcodeproj
    spec: Frameworks/project.yml

In the event that a spec is declared, XcodeGen could use this as an indicator to generate reference projects also all in the same command so this would allow me to call just the following:

$ mint run yonaskolb/XcodeGen xcodegen --spec App/project.yml --project App/ --use-cache

And as a result, we could leverage the caching through all referenced specs and trigger the parent postGenCommand if anything changes with either the target project or any of its references.

Maybe this is a bit much, or maybe there are other plans on the horizon however I'm keen to get involved in working on a solution for this kind of thing so I'd appreciate any feedback or ideas/pointers as to how I (and others in the same situation) can achieve such behavior. Thanks!

Edit: Maybe another option could be to expose either a cache-check/validate command to detect if we need to run the generator (or somehow achieve similar from reading stdout in a more machine-readable way?) would be a simpler solution that allows people to chain commands and check the cache in their own scripts?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the existing Frameworks/project.yml and App/project.yml workflow, then review the projectReferences, --use-cache, and postGenCommand entry points described in the issue. Define whether referenced specs should be generated in one command and how cache changes should trigger post-generation work; completion should support the stated single-command workflow or clearly document an alternative.

Written by the indexing model from the issue text.

Assessment

Tech stack
swift
Domain
build-system, cli
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.