Improvements to buildGo

Improvements to buildGo

[Ali Abrar]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

Hi there,

I'm using buildGo and I have some patches that I'd like to submit upstream. The first, and most important, is adding support for embed configuration.

-embedcfg file
      Read go:embed configuration from file.
      This is required if any //go:embed directives are used.
      The file is a JSON file mapping patterns to lists of filenames
      and filenames to full path names.

I have added support for this on my fork and would be happy to contribute it.

I also have added a good number of go packages under third_party/gopkgs, but I'm not sure if you actually want that to become a big library of packages or if they are better placed elsewhere.

Last, I'm wondering if you had any thoughts on spinning up development environments for go packages that are packaged with buildGo.  If you've already got something in this vein that works, I'd love to borrow your ideas. Otherwise, I'd be happy to share what I come up with.

Thanks,
Ali


Ali Abrar

Partner, Obsidian Systems



(888) 611-7759 x102



ali.abrar@obsidian•systems

https://obsidian.systems



[-- Attachment #2: Type: text/html, Size: 7338 bytes --]

Re: Improvements to buildGo

[sterni]

On 10/14/25 03:17, Ali Abrar wrote:
> I'm using buildGo and I have some patches that I'd like to submit 
> upstream. The first, and most important, is adding support for embed 
> configuration.

embed and cgo support are the obvious missing pieces for buildGo, so 
you're welcome to submit your changes for review. Either via Gerrit (see 
<https://code.tvl.fyi/about/docs/REVIEWS.md>) or via mail if that's more 
convenient for you.

> I also have added a good number of go packages under third_party/gopkgs, 
> but I'm not sure if you actually want that to become a big library of 
> packages or if they are better placed elsewhere.

Given that we have no good way to (semi-)automatically update third 
party go packages in depot at the moment, I'd vote against accumulating 
packages which are not depended on in depot itself.

> Last, I'm wondering if you had any thoughts on spinning up development 
> environments for go packages that are packaged with buildGo.  If you've 
> already got something in this vein that works, I'd love to borrow your 
> ideas. Otherwise, I'd be happy to share what I come up with.

Nothing I'm aware of. In general, buildGo has mostly been in maintenance 
mode as of late. Almost every Go release manages to break buildGo in 
some way via often undocumented changes in the behavior of the CLI, so 
further developing has been feeling like a risk given that anything we 
built is almost certain to randomly break at some point (usually it is 
fixable after some head scratching, but that's anything but guaranteed).

~sterni