To clone the project locally, execute 'make build' and get the following error

[rnb3ds]

Description

To clone the project locally, execute 'make build' and get the following error:

Running go generate... no required module provides package code.gitea.i; to add it: go get code.gitea.i make: *** [makefile:782: generate-go] Error 1

Gitea Version

master

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

My running environment:

win10、Git Bash、make 4.2、go 1.22

Database

None

[rnb3ds]

Makefile is not modified, project new clone downloaded.

[lunny]

This is because windows command line has limitation for output. And since Gitea have more and more packages, GO_PACKAGES is too long.

[rnb3ds]

This is because windows command line has limitation for output. And since Gitea have more and more packages, GO_PACKAGES is too long.

That's the reason. Thank you！

[silverwind]

According to https://stackoverflow.com/questions/3205027/maximum-length-of-command-line-string and https://learn.microsoft.com/en-US/troubleshoot/windows-client/shell-experience/command-line-string-limitation, command length limit is either 32k or 8k (cmd.exe) on Windows. I think we'd need to avoid passing so long command lines to really fix it.

[silverwind]

So instead of passing almost all go files to go generate, I think we could pre-scan for //go:generate comments and only pass these.

Go generate scans the file for directives, which are lines of the form,

//go:generate command argument...

(note: no leading spaces and no space in "//go") where command
is the generator to be run, corresponding to an executable file
that can be run locally. It must either be in the shell path
(gofmt), a fully qualified path (/usr/you/bin/mytool), or a
command alias, described below.

[jolheiser]

Wait why are we not already running go generate ./...?

[silverwind]

#30529 should fix it. @rnb3ds can you try it?

[silverwind]

Wait why are we not already running go generate ./...?

No idea but it seems to have some useless exclusion of certain test files, at least for vet.

[lunny]

Wait why are we not already running go generate ./...?

No idea but it seems to have some useless exclusion of certain test files, at least for vet.

Because there are dependencies also include go generate when Gitea hasn't removed vendor directoy.

[silverwind]

We could alternative pass every known module that has go:generate statements, e.g.:

modules/charset/escape.go:4://go:generate go run invisible/generate.go -v -o ./invisible_gen.go
modules/charset/escape.go:6://go:generate go run ambiguous/generate.go -v -o ./ambiguous_gen.go ambiguous/ambiguous.json
modules/options/options_bindata.go:8://go:generate go run ../../build/generate-bindata.go ../../options options bindata.go
modules/templates/templates_bindata.go:8://go:generate go run ../../build/generate-bindata.go ../../templates templates bindata.go true
modules/migration/schemas_bindata.go:8://go:generate go run ../../build/generate-bindata.go ../../modules/migration/schemas migration bindata.go
modules/public/public_bindata.go:8://go:generate go run ../../build/generate-bindata.go ../../public public bindata.go true