krzysztofzablocki / Sourcery

Meta-programming for Swift, stop writing boilerplate code.
http://merowing.info
MIT License
7.69k stars 618 forks source link

Use SPM to build swift templates #509

Closed ilyapuchka closed 7 months ago

ilyapuchka commented 6 years ago

Currently swift templates are compiled using swiftc, which requires to pass it some non-trivial arguments and perform additional step to properly link SourceryRuntime. Instead we can generate package manifest for each template (or a single manifest with executable for each template) and use SPM to build and run them. This will also let us remove all additional steps and code related to caching as SPM should handle it already. It also will allow to use swift templates with SPM Sourcery installation as it will be possible to add SourceryRuntime as dependency for templates, so SPM will build and link it. With swiftc we can only link to framework (though there might be a way to link SPM-build SourceryRuntime, but it will make users to manually build it). This though might increase build times of templates as it will need to build SourceryRuntime at least once, but as it does not change SPM should be able to cache it after first build.

Liquidsoul commented 6 years ago

I've been thinking about doing this for a while. This would potentially open some powerful new features like using library code in Swift templates allowing a nice "plugin" system. One question we must answer is how we will maintain the version of SourceryRuntime contained in the Package.swift Swift templates will use?

ilyapuchka commented 6 years ago

SourceryRuntime version should be the same as version of sourcery tool.

felix91gr commented 6 years ago

Question: can one replace the Swift templates with Stencil ones? Or are there things that are only possible from Swift templates?

krzysztofzablocki commented 6 years ago

Swift ones are more powerful as they are full language, Stencil isn't Turing complete

ilyapuchka commented 6 years ago

The problem with swift templates though is ABI stability, as they currently rely on linking framework shipped with Sourcery, so templates and this framework should be compiled with one version of swift. If you want full power - use EJS, but I think they will work on macOS only, JavaScriptCore does not work on Linux AFAIK

felix91gr commented 6 years ago

so templates and this framework should be compiled with one version of swift.

Ahh, of course. And that's why you'd need to build the SourceryRuntime every time you build a SPM package that uses Swift templates. Right?

ilyapuchka commented 6 years ago

Yes, we copy the framework from Sourcery bundle and link it to template executable. But that makes it impossible to use swift templates with SMP installation because SMP builds do not produce dynamic frameworks.

ilyapuchka commented 6 years ago

Ahh, of course. And that's why you'd need to build the SourceryRuntime every time you build a SPM package that uses Swift templates. Right?

we don't actually use SPM to build swift templates, we use swiftc

felix91gr commented 6 years ago

I see. Yeah, that makes sense.

You'd think that ABI stability is only important for Apple frameworks and such. But no, dynamic frameworks like Sourcery need ABI stability by construction 😄

Stencil isn't Turing complete.

That makes sense. Hmm. I guess it's a bummer, but I could wait and use Stencil for now until ABI stability enables the rest of Sourcery to be used easily outside of Darwin.

anandabits commented 6 years ago

Swift ones are more powerful as they are full language

@krzysztofzablocki I've been working with Swift templates lately and this doesn't appear to be accurate. It looks like Sourcery inlines the template into a function so we aren't able to make use of top-level only language features such as protocols and extensions in a Swift template (please correct me if I have missed something here). I would love to see that limitation eventually.

Right now I'm using include to reference .swift files but that is just a textual include of the source into a function in the main.swift Sourcery creates when compiling a Swift template. Maybe using SPM would make it possible to have real references to .swift files that the compiler sees as files. That is necessary to make the entire language work as expected (including access control, etc).

krzysztofzablocki commented 6 years ago

@anandabits that might be the case, didn't think about those top level only features, I guess you could modify our templating system to support that if you like, we are always happy to accept prs :)

art-divin commented 1 year ago

👋🏻 Hi all,

this issue looks hard enough for me to not understand it. So I might just do this 🦾 Hardest tasks are the most fun ones 🤓 .

I'll update you on this later.

krzysztofzablocki commented 1 year ago

We might already be using spm for this @art-divin

art-divin commented 1 year ago

@krzysztofzablocki huh, go figure 😓 I wonder, if the topic was something about using SPM to create a package and build that, instead of invoking swift build -c release in SwiftTemplate.swift:249 we'd create an SPM package with swift package command, and compile just that, somehow 🤔

art-divin commented 7 months ago

In fact, this is already the case. Closing.