8000 [Feature] Use `Development Pods` group for `generate_multiple_pod_projects` mode · Issue #8659 · CocoaPods/CocoaPods · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[Feature] Use Development Pods group for generate_multiple_pod_projects mode #8659

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.

Sign up for GitHub

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

Jump to bottom
Closed
Whirlwind opened this issue Mar 31, 2019 · 7 comments
Closed

[Feature] Use Development Pods group for generate_multiple_pod_projects mode #8659

Whirlwind opened this issue Mar 31, 2019 · 7 comments
Assignees
@sebastianv1
Labels
t3:discussion These are issues that can be non-issues, and encompass best practices, or plans for the future. t4:question This is a question to the maintainers. This could lead into closing the issue or into an enhancement
Milestone
1.7.0

Comments

@Whirlwind
Copy link
Contributor
Whirlwind commented Mar 31, 2019 •
edited
Loading

When :generate_multiple_pod_projects=>true, all pod will use a single project in Dependencies group, include the development pods. It is hard to find the development pod in 150+ pods!! On the other hand, it is hard to check whether is a local pod for a pod ( I must check the path of a source file).

Have CP a plan that move back the local pod to Development Pods group? Of cause, I still hope keep the single pod project for per-pod in the Development Pods.
@sebastianv1
Copy link
Collaborator
sebastianv1 commented Apr 1, 2019 •
edited
Loading

I think it makes sense for subprojects to just hold a Dependencies group, but for Pods.xcodeproj we could produce a similar structure as before since it holds every pod in the workspace. Thoughts @segiddins @dnkoutso ?

@sebastianv1 sebastianv1 mentioned this issue Apr 1, 2019
Merged
@dnkoutso dnkoutso added t3:discussion These are issues that can be non-issues, and encompass best practices, or plans for the future. t4:question This is a question to the maintainers. This could lead into closing the issue or into an enhancement labels Apr 1, 2019
@amorde
Copy link
Member
amorde commented Apr 2, 2019

I'd be in favor of something like the Development Pods group that exists now, I use it in my projects

@sebastianv1
Copy link
Collaborator

Cool, so I'm thinking the structure would look something like:

├── Pods.xcodeproj
│   ├── Development Pods (if they exist)
│   │   ├── Local Pod A
│   │   │   └── Dependencies
│   ├── Pods
│   │   ├── Remote Pod A
│   │   │   └── Dependencies
...

The Dependencies group still gets generated, but only for each individual subproject and not for Pods.xcodeproj.

@Whirlwind
Copy link
Contributor Author
Whirlwind commented Apr 3, 2019 •
edited
Loading

Why do we need the Dependencies group? I think the old structure is fine:

├── Pods.xcodeproj
│   ├── Development Pods (if they exist)
│   │   ├── Local Pod A.xcodeproj
│   ├── Pods
│   │   ├── Remote Pod A.xcodeproj

Or, move the development pod into workspace: ( Maybe we could remove the Pods group! )

├── Pods.xcodeproj
│   ├── Remote Pod A.xcodeproj
│   ├── Framework
│── Local Pod A.xcodeproj

@sebastianv1
Copy link
Collaborator

Dependencies group is required for target dependencies to be set up correctly. A target dependency can only be added to a target if it exists in the same project or is nested as a subproject, hence the Dependencies group.

@sebastianv1 sebastianv1 self-assigned this Apr 23, 2019
@sebastianv1
Copy link
Collaborator

PR: #8731

@dnkoutso dnkoutso added this to the 1.7.0 milestone Apr 24, 2019
@wulongwang
Copy link

cocoapods can do that below?

├── Pods.xcodeproj
│   ├── Remote Pod A.xcodeproj
│   ├── Framework
│── Local Pod A.xcodeproj

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sebastianv1 sebastianv1

Labels
t3:discussion These are issues that can be non-issues, and encompass best practices, or plans for the future. t4:question This is a question to the maintainers. This could lead into closing the issue or into an enhancement
Projects
None yet
Milestone
1.7.0
Development

No branches or pull requests
5 participants
@dnkoutso @Whirlwind @amorde @wulongwang @sebastianv1
0