DaddyFrosty/yoga
1
0
Fork 0
Code Issues 96 Pull Requests 31 Actions Packages Projects Releases 33 Wiki Activity

Add support for Swift Package Manager #1032

Closed
salling wants to merge 17 commits from swiftpm into main
pull from: swiftpm
merge into: DaddyFrosty:main
Conversation 11 Commits 17 Files Changed 3 +73434 -42256
salling commented 2020-10-09 03:11:12 -07:00 (Migrated from github.com)
Copy Link

This PR addresses #965

Objective was to add support for swiftpm, while at the same time keeping the change set minimal. The "trick" here is to add a public header file that is used from Package.swift.

Note: this PR does not intend to expose YogaKit through SPM, only yoga itself.

This PR addresses #965 Objective was to add support for swiftpm, while at the same time keeping the change set minimal. The "trick" here is to add a public header file that is used from Package.swift. Note: this PR does not intend to expose YogaKit through SPM, only yoga itself.
clausjoergensen (Migrated from github.com) reviewed 2020-10-09 06:46:12 -07:00
yoga/swiftpm-support/umbrella.h
@@ -0,0 +7,4 @@
#pragma once
#ifdef __OBJC__
clausjoergensen (Migrated from github.com) commented 2020-10-09 06:46:12 -07:00
Copy Link

Is it possible to use the SWIFT_PACKAGE preprocessor flag here to make it even safer?

Is it possible to use the [SWIFT_PACKAGE](https://github.com/apple/swift-package-manager/blob/main/Documentation/Usage.md#packaging-legacy-code) preprocessor flag here to make it even safer?
clausjoergensen commented 2020-10-09 06:49:42 -07:00 (Migrated from github.com)
Copy Link

Ping #921

Ping #921
salling (Migrated from github.com) reviewed 2020-10-09 13:12:45 -07:00
yoga/swiftpm-support/umbrella.h
@@ -0,0 +7,4 @@
#pragma once
#ifdef __OBJC__
salling (Migrated from github.com) commented 2020-10-09 13:12:45 -07:00
Copy Link

Does not seem to be defined at the time the public header is compiled. Only when the code that's part of the package is built.

Does not seem to be defined at the time the public header is compiled. Only when the code that's part of the package is built.
NickGerleman commented 2023-06-13 08:02:39 -07:00 (Migrated from github.com)
Copy Link

We are deprecating YogaKit as part of the Yoga 2.0 release. We are still going to release a new revision based on the current state of the repo, but won't be accepting new contributions, since we are going to be removing it from the repo after.

We are deprecating YogaKit as part of the Yoga 2.0 release. We are still going to release a new revision based on the current state of the repo, but won't be accepting new contributions, since we are going to be removing it from the repo after.
clausjoergensen commented 2023-06-15 05:21:08 -07:00 (Migrated from github.com)
Copy Link

@NickGerleman this wasn't for YogaKit though. You keep updating the CocoaPods package, why can't you make a SPM package too?

@NickGerleman this wasn't for YogaKit though. You keep updating the CocoaPods package, why can't you make a SPM package too?
NickGerleman commented 2023-06-15 11:48:49 -07:00 (Migrated from github.com)
Copy Link

Oh yes it does look like I mistagged this.

My initial focus has been on rejuvenating the packages that Yoga is already published to, so Maven Central, CocoaPods, NPM. I do think SPM is a good target, and likely not too much burden to add. Though if we do add it, I think we will need to add some continuous validation for it, else it will atrophy. That is something that has been missing from the various PRs I have seen.

Apart from the validation, I have wanted there to be someone on the team with understanding of new infra before we decide to support it. So, after the contribution, we can continue to support it. I don't think anyone has looked into that as much yet.

cc @cipolleschi in case you have thoughts on this.

Oh yes it does look like I mistagged this. My initial focus has been on rejuvenating the packages that Yoga is already published to, so Maven Central, CocoaPods, NPM. I do think SPM is a good target, and likely not too much burden to add. Though if we do add it, I think we will need to add some continuous validation for it, else it will atrophy. That is something that has been missing from the various PRs I have seen. Apart from the validation, I have wanted there to be someone on the team with understanding of new infra before we decide to support it. So, after the contribution, we can continue to support it. I don't think anyone has looked into that as much yet. cc @cipolleschi in case you have thoughts on this.
🚀 1
cipolleschi commented 2023-06-15 18:08:21 -07:00 (Migrated from github.com)
Copy Link

Hi there, thanks @NickGerleman for tagging me.
I'm highly supportive of this change. Yoga is one of the few React Native packages that we can use independently and it makes a lot of sense to me to offer also a Swift PM alternative.

Also, the setup is fairly simple and I really like the folder with the public umbrella header.

I have not spent a lot of time thinking about how to validate it, though. One simple way could be to have an example app that import the dependency as a package and exercise it.
Another way could be to automatically generate the Package.swift from the podspec.

I don't have a strong opinion, although the second could be better in the long run.
I'll leave the decision to you.

Hi there, thanks @NickGerleman for tagging me. I'm highly supportive of this change. Yoga is one of the few React Native packages that we can use independently and it makes a lot of sense to me to offer also a Swift PM alternative. Also, the setup is fairly simple and I really like the folder with the public umbrella header. I have not spent a lot of time thinking about how to validate it, though. One simple way could be to have an example app that import the dependency as a package and exercise it. Another way could be to automatically generate the Package.swift from the podspec. I don't have a strong opinion, although the second could be better in the long run. I'll leave the decision to you.
cipolleschi (Migrated from github.com) reviewed 2023-06-15 18:09:37 -07:00
cipolleschi (Migrated from github.com) left a comment
Copy Link

I'm very happy about this happening. It is a first step toward embracing more modern languages. I left a couple of comments to update a couple of values, but I'll leave you the last word on those.

I'm very happy about this happening. It is a first step toward embracing more modern languages. I left a couple of comments to update a couple of values, but I'll leave you the last word on those.
Package.swift
@@ -0,0 +1,35 @@
// swift-tools-version:5.3
cipolleschi (Migrated from github.com) commented 2023-06-15 18:02:58 -07:00
Copy Link

we can probably use a more recent version of swift-tools here. At least 5.8, until Xcode 15 become stable.

we can probably use a more recent version of swift-tools here. At least `5.8`, until Xcode 15 become stable.
Package.swift
@@ -0,0 +31,4 @@
]
)
],
cxxLanguageStandard: .cxx14
cipolleschi (Migrated from github.com) commented 2023-06-15 18:00:46 -07:00
Copy Link

this should probably be .cxx17, as this is the version we are typically using internally.

this should probably be `.cxx17`, as this is the version we are typically using internally.
NickGerleman (Migrated from github.com) reviewed 2023-06-16 13:39:44 -07:00
Package.swift
@@ -0,0 +31,4 @@
]
)
],
cxxLanguageStandard: .cxx14
NickGerleman (Migrated from github.com) commented 2023-06-16 13:39:44 -07:00
Copy Link

Yoga is targeting C++14 for a little bit longer. There was some unhappiness when I tried to bump from C++ 11 directly to 17.

LLVM has had C++ 17 support for almost six years though, so I do plan for us to do a bump later this year. Same rules for same infra, and unlocking more support.

See https://github.com/facebook/yoga/pull/1203 for discussion

Yoga is targeting C++14 for a little bit longer. There was some unhappiness when I tried to bump from C++ 11 directly to 17. LLVM has had C++ 17 support for almost six years though, so I do plan for us to do a bump later this year. Same rules for same infra, and unlocking more support. See https://github.com/facebook/yoga/pull/1203 for discussion
NickGerleman (Migrated from github.com) reviewed 2023-06-16 13:40:17 -07:00
Package.swift
@@ -0,0 +1,35 @@
// swift-tools-version:5.3
NickGerleman (Migrated from github.com) commented 2023-06-16 13:40:16 -07:00
Copy Link

We should maybe consider bumping this in CocoaPods as well then, which is currently set on 5.1

We should maybe consider bumping this in CocoaPods as well then, which is currently set on 5.1
iainsmith commented 2023-08-23 14:34:00 -07:00 (Migrated from github.com)
Copy Link

This can be closed now we have ef5784aca6was

This can be closed now we have https://github.com/facebook/yoga/commit/ef5784aca647a68343f5409e379519827edb86a9was

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
Algorithm
Build and Infrastructure
C#
C++ Enhancement
CLA Signed
Discussion
Documentation
Feature Request
Java
JavaScript
Merged
Question
Reverted
Shared with Meta
Applied via automation to indicate that an Issue or Pull Request has been shared with the team.
YogaKit
YogaLayout ViewGroup
bug
dependencies
Pull requests that update a dependency file
duplicate
enhancement
fb-exported
fh:direct-merge-enabled
invalid
ruby
Pull requests that update Ruby code
wontfix
No Label
Build and Infrastructure
CLA Signed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
DaddyFrosty
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: DaddyFrosty/yoga#1032
No description provided.
Delete Branch "swiftpm"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?