-
Notifications
You must be signed in to change notification settings - Fork 234
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
Support embeds with native golang rules #781
Comments
I was able to accomplish 90% of what's needed here, though not without some jank. I was able to generate the embedcfg with the following setup:
|
@mkditto This is good! I did a very similar thing but using regex matching to execute the patterns in starlark instead of running a helper binary, which was a good 90% solution. This was for a slightly different use case, which was generating a BUCK file from Some next steps:
|
I've been experimenting with building go with
buck2
, and up to this point I've had a pretty good experience. The one drawback I've had so far is using to goembed
package. Right now when building go with buck I have to manually create theembedcfg
for my embedded resources, and this comes with a few drawbacks:The documentation on the format of the embedcfg can be hard to find, so it takes a good bit of time to write one the first time. Since this is something that you don't have to do with standard go tooling, it's not something most regular go devs are familiar with doing.
The embedcfg needs to be a json source which you can either get with a genrule or by writing it to your repo directly.
If you choose to write a
genrule
, you have to write it for each library that requires embeds. Optionally, you can make this easier by writing your own macro wrapping thegenrule
, but now you have to maintain your own macro for something that feels like it should be supported by the native rules.If you choose to write the json sources to your repo directly, you'll pretty quickly run into issues because the embedcfg requires the absolute paths of the embedded sources, which is obviously not portable.
Abstracting away the generation of the embedcfg inside the standard
go_*
rules would be great and would save devs some effort learning how to write proper embedcfgs and maintaining their owngenrules
to generate them. This is fairly similar to what bazel already does with theembedsrcs
attribute on its go rules, and would probably look very much the same:Another option would be to add a macro to the prelude called
go_embedcfg
that can generate the embedcfg for you, which you can then depend on with the current ruleset. It would maybe be little bit more verbose than the above option, but would also work. Ergonomically I'd imagine it would look something like:(I think that by adding a
filegroup
to the second example it's no longer equivalent to the first, but I think it still demonstrates the point)The text was updated successfully, but these errors were encountered: