We use stringer in some platform-specific code. In order to keep the code compiling, we need the code that stringer outputs to be protected by a build tag.
I propose that stringer replicates into its output any build tags present in the file in which the type is defined. The type will only be defined when those build tags are present, so not doing this replication generates broken code.
We are currently manually editing the code after generation, which breaks our attempt to have CI check that go generate has been run. We put in this CI check after failure to run go generate caused bugs. Alas, not all code generation is amenable to tricks making such a CI check unnecessary.
Alternatives to this suggestion:
Add a -header flag that accepts text to be used. (Maybe also a -headerfile flag?) This would be useful for build tags as well as license header injection, but it requires manual maintenance.
Write a separate utility to inject headers. go generate doesn't define the order in which the generate commands run, and go generate supports running only a subset of generation commands, so for best effect this would have to be a single generate line, like //go:generate injectheader -header "some build tag" -run stringer -type=T, which is a bit of a mouthful.
These alternatives might be independently useful, but it seems to me that getting build tags right automatically is a good place to start.
cherrymui
commented
3 years ago
We use stringer in some platform-specific code. In order to keep the code compiling, we need the code that stringer outputs to be protected by a build tag.
I propose that
stringerreplicates into its output any build tags present in the file in which the type is defined. The type will only be defined when those build tags are present, so not doing this replication generates broken code.We are currently manually editing the code after generation, which breaks our attempt to have CI check that go generate has been run. We put in this CI check after failure to run
go generatecaused bugs. Alas, not all code generation is amenable to tricks making such a CI check unnecessary.Alternatives to this suggestion:
-headerflag that accepts text to be used. (Maybe also a-headerfileflag?) This would be useful for build tags as well as license header injection, but it requires manual maintenance.go generatedoesn't define the order in which the generate commands run, andgo generatesupports running only a subset of generation commands, so for best effect this would have to be a single generate line, like//go:generate injectheader -header "some build tag" -run stringer -type=T, which is a bit of a mouthful.These alternatives might be independently useful, but it seems to me that getting build tags right automatically is a good place to start.
cc @robpike @bradfitz