* add ".exe" when cross compiling for windows
* add ".exe" when cross compiling for windows or on windows without cross-compiling
* wait until 1.23 is released
Follow-up to #69
I had a situation where caddy/v2 v2.4.6 was in my go.mod and a replace
on it to use local caddy repo.
When I ran `xcaddy run` to test a caddy module, it failed to run because
the replace included the version v2.4.6, even though somehow the buildenv
go.mod had v2.6.1 (the latest), and the replace directive specified
@v2.4.6 only, so the replacement didn't happen.
I don't think versions in the replacement source/origin are
really that useful for xcaddy.
If experience proves this wrong, we can figure out a better solution.
Add environment variable
XCADDY_GO_BUILD_FLAGS
to override default build arguments from environment (#102).
To support flags with variable arguments Unix-style quoting is supported.
* fix: do not use only hardcoded "go"
* fixed comments and added env to readme
* move GetGo to an internal package
Co-authored-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* Parse JSON output of 'go list'
It's more robust in this way
* Handle all possible replacements properly for runDev()
1. Handle all possible replacements properly for runDev()
Replacement targets are not always paths.
Reference:
https://pkg.go.dev/cmd/go/internal/list#pkg-variables
2. Parse replacement info from 'go list -m -json all'
It's more robust in this way
* Test the 'go list -m -json all' parsing logic
* Call 'go list' command only once
`go list -m -json all` contains all informations we need so we don't
need extra `go list -m -json` call.
* main_windows_test.go: Make tests for Windows
* Support Go 1.16
* Use struct instead of map[string]interface{}
* extract and unexport the `module` struct
Co-authored-by: Mohammed Al Sahaf <msaa1990@gmail.com>
* accept replacements with branches of github forks
Closes#50
* remove `!filepath.IsAbs(repl)` when checking path of replacement
If the replacement path starts with a `.`, then the path is definitely not absolute.
When I first wrote xcaddy I was on macOS which does not
require permission to bind to low ports. Now I'm on Linux.
The XCADDY_SETCAP env var will cause xcaddy to run setcap
on the generated temporary binary before executing it
so that it can bind to low ports. This requires sudo.
* Fix main.go generation when executing on a windows machine
When normalizing the `importPath` it will try to write on `main.go` files with imports
like `github.com/caddyserver/xcaddy/c:\xcaddy`
* Apply CR suggestions
* Add test cases for sub-paths on normalizeImportPath
* Run windows tests only when GOOS matches
* support go.mod replace version pinning
* use string replace instead of regex
* Minor cleanups
Co-authored-by: Matthew Holt <mholt@users.noreply.github.com>
