Remove limitation for a specific version of Boost.

[mxmauro]

On MSYS2 it is not possible to install a specific version of Boost. Also anyone with Boost installed would be forced to install a specific version.

[cce]

This module provides its own version of Boost, in the vendor directory, so no system installation is required. It should build successfully without this change and without any system Boost installation — does that work for you on Windows?

[cce]

We have a Windows+MSYS2 build for all master commits to go-algorand in (here's the latest build: https://github.com/algorand/go-algorand/actions/runs/6658548337/job/18095661027) that does not require any modifications like this PR. I had assumed the successful Windows builds rely on the vendored dependency in this module to work without changes to this package.

[mxmauro]

Hi @cce

This module provides its own version of Boost, in the vendor directory, so no system installation is required. It should build successfully without this change and without any system Boost installation — does that work for you on Windows?

Hi @cce.

After cloning the go-algorand repo, go mod vendor does not download the boost subdirectory of this repo. I'm not sure if changing the include <> to include "" fixes the issue because mod vendor tries to download only required files.

The environment is MSYS2/MingW64.

[cce]

Oh so you are using custom build tooling that uses go mod vendor to download dependencies? I think I understand why you had an issue. go get will put the required boost files in $GOPATH/pkg/mod/github.com/algorand/[email protected]/ but go mod vendor has different rules for what files and paths it puts in vendor.

What build tooling are you using, do you have custom build automation that uses vendor directories instead of the go package cache and go get?

The workaround/fix for this issue is to add dummy.go files into the necessary paths like https://github.com/algorand/go-algorand/blob/master/crypto/secp256k1/libsecp256k1/src/dummy.go

There are similar workarounds in
https://github.com/ethereum/go-ethereum/blob/master/crypto/secp256k1/libsecp256k1/include/dummy.go
https://github.com/karalabe/usb/blob/master/hidapi/libusb/dummy.go
https://github.com/crawshaw/sqlite/blob/master/c/dummy.go
and other projects that rely on C/C++ dependencies

However since Go modules are very well-adopted now, and vendoring is a legacy feature, it may be simpler to update your build scripts to use Go modules and the Go module cache.

[mxmauro]

I'll close this because was able to compile the node forcing the installation of go 1.20.2 on MSYS2.

Because MSYS2 does not provide environment isolation and faced similar issues in the past, will check deeper.

Thanks!