Closed kabiroberai closed 10 months ago
Maybe add a short info to the README about files generated via BuildToolPlugin
s like this one will not be displayed in the source folders?
Otherwise people might wonder why they cannot specify the output directory as they're used to by the old workflow.
Because modifying source files isn't allowed (nor needed) by Xcode/SwiftPM. Instead everything generated has to be placed into the pluginWorkingDirectory.
@kabiroberai @bspinner @MatyasKriz what is the status of the PR? We would like to use the functionality in our app
@bohdansasko Unfortunately I'm waiting for a response just like you.
Currently I am using the 'package-plugin' branch of my fork:
Hey, I don't think I'll be merging this PR, as it's been abandoned and I've already started working on TOML configuration file to go with the new release and merging this would require users to migrate twice.
I don't have an ETA if that's on your mind, so go ahead and use the unofficial integration in the meantime if you need it. 🙂
Hey, I don't think I'll be merging this PR, as it's been abandoned and I've already started working on TOML configuration file to go with the new release and merging this would require users to migrate twice.
I don't have an ETA if that's on your mind, so go ahead and use the unofficial integration in the meantime if you need it. 🙂
May I help you somehow to speed up the feature development?
Hey, I don't think I'll be merging this PR, as it's been abandoned and I've already started working on TOML configuration file to go with the new release and merging this would require users to migrate twice.
I don't have an ETA if that's on your mind, so go ahead and use the unofficial integration in the meantime if you need it. 🙂
May I help you somehow to speed up the feature development?
You're too kind, but I need to let this slowly brew little by little when I have the time. I've managed to add TOML configuration support quite easily thanks to a great library as well as parser and generator concurrency. But I'm not done yet, along with it the README needs to be refurbished using the knowledge I've gathered during implementation. I'd like to include this plugin support as well if possible since we have a configuration file ready for it.
What I fear a little is caching which wasn't done before in this project, so that might be a challenge, though I might release that as 2.1 additionally.
Just to chime in, I unfortunately haven't had time to work on this as of late and since @MatyasKriz is working on a TOML config I agree that it doesn't make sense to pursue this PR any further. Now that Swift Macros are stabilized IMO it makes more sense to adopt those instead of a package plugin, but that would be source-breaking so I can see arguments both for and against taking that approach.
@MatyasKriz want me to close this PR? Or should I leave it open for posterity until the new configuration system is implemented?
Please keep it open for now so that I don't forget to credit you, I'll use your implementation minus the JSON as it looks solid to me.
I haven't had much opportunity to dabble with macros yet, mostly because when I tried them, they were SPM-only, which is kinda lame. Is it any better now? Also I can't think of a way to use macros without editing existing source code as this the library's way.
I've managed to get the SPM integration working in Cuckoo 2.0, though I'm not satisfied with how generator versions are handled for Cocoapods and Carthage, so I'll have to fix that before a beta is available.
Thank you @kabiroberai for the initial implementation! It was insanely helpful during adaptation for the TOML configuration that Cuckoo 2.0 uses.
I'll close the PR in favor of the SwiftSyntax PR that has the SPM plugin contained within.
Closes #438.
Using the plugin is simple: just add
plugins: [.plugin(name: "CuckooPlugin", package: "Cuckoo")]
to the correspondingtestTarget
. The plugin currently passes all modules that are direct dependencies of the test target to the generator.Since there's no API for directly configuring plugins from Package.swift yet, the plugin currently looks for a
cuckoo.json
file in the package root dir, which can currently be used to supply additional command-line options. IMO using json makes sense for now because it's one of the easiest formats to parse in Swift. We can always switch to something more expressive like YAML in the future, since the config file is versioned and YAML is designed to be backwards-compatible with JSON.