-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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.
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
Put (Swift) Target Runtimes in Separate Repos #1774
Comments
One of the key features of antlr4 is its genuine multi target capability.
It comes with constraints notably that all targets share the same test suite, in order to check that any tool change works with all targets.
It also requires a versioning scheme and release lifecycle that spans across targets.
We've had dedicated repos in the past, and it was a recipe for diverging targets.
There must be a way to publish the relevant sub repo automatically from the ANTLR repo whenever it is released.
Envoyé de mon iPhone
… Le 20 mars 2017 à 07:26, hanjoes ***@***.***> a écrit :
Introduction
This is a proposal to separate out (some) target's runtime into separate repos for better project integration.
For e.g.: The current way of importing the Swift Antlr4 runtime is not ideal because:
It can only work with Xcode. (all of the configuration is Xcode dependent) so it does not work on non-darwin platforms.
It does not work with Swift Package Manager (1st party support for Swift's dependency management), neither Carthage (3rd party package manager) which also requires a git repo or at least a remote space that stores the artifact (not ideal for Swift because of ABI stability).
Motivation
Although in 4.6 release we added SPM integration, but without a separate repo for swift target, the workflow is like this:
clone/fork the antlr4 repository
'git init' in the swift runtime folder, and tag the runtime repository
create a remote repository that should hold the swift runtime
push to the remote repository just created
add the remote repository as dependency in our projects SPM manifest file.
run 'swift build' will then pull dependency from the repository
This workflow is awkward. Reference.
This change will end all the hassle in adding swift runtime to a project, and instead, make it as easy as adding the git repository to Package.swift:
let package = Package(
name: "ProjectUsingSwiftRuntime",
targets: [
Target(name: "ProjectUsingSwiftRuntime", dependencies: []),
],
dependencies: [
.Package(url: "https://github.com/antlr/antlr4-swift-runtime.git", majorVersion: x.x.x)
]
)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I agree. I have a gut feeling that it can be supported. But there must be some maintenance overhead. |
Yeah, All of your reasons are good, which is why we originally had separate repos, but we went through a huge effort to actually integrate everything into one repository. There are negatives as you both point out but I think I'd like to keep everything together. Can we make tools or something to make integration easier? Perhaps we make a script that generates a read-only repo or something? |
Good to know. Separating runtimes doesn't seem worth the effort given what you've mentioned. We can do some workaround to make integration easier. Anything can be done, it's all about tradeoffs after all. Closing! |
Since SPM4 supports custom Source locations, a simple workaround would be to put the Package.swift in root folder. |
Introduction
This is a proposal to separate out (some) target's runtime into separate repos for better project integration.
For e.g.: The current way of importing the Swift Antlr4 runtime is not ideal because:
Motivation
Although in 4.6 release we added SPM integration, but without a separate repo for swift target, the workflow is like this:
This workflow is awkward. Reference.
This change will end all the hassle in adding swift runtime to a project, and instead, make it as easy as adding the git repository to Package.swift:
The text was updated successfully, but these errors were encountered: