Also use correct `;` divider. Otherwise the build fails with:
```
nimbus@windows-01 MINGW64 /d/beacon-node-holesky-libp2p/repo (nim-libp2p-auto-bump-unstable)
$ make libminiupnpc.a --debug
Reading makefiles...
Updating makefiles....
Updating goal targets....
File 'libminiupnpc.a' does not exist.
File 'sanity-checks' does not exist.
Must remake target 'sanity-checks'.
Successfully remade target file 'sanity-checks'.
Must remake target 'libminiupnpc.a'.
process_begin: CreateProcess(NULL, git rev-parse --short HEAD, ...) failed.
Makefile.mingw:56: pipe: No error
gcc: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
compilation terminated.
make[1]: *** [Makefile.mingw:121: wingenminiupnpcstrings.exe] Error 1
make: *** [vendor/nimbus-build-system/makefiles/targets.mk:134: libminiupnpc.a] Error 2
```
Resolves:
https://github.com/status-im/nimbus-eth2/issues/5507
I still don't get why this `PATH` modification is even necessary, it works without it.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
When `build_nim.sh` detects that `skipIntegrityCheck` is supported,
it runs the upstream toolchain for building Nim, ignoring the locally
checked out `Nim-csources-v1` and `nimble` sub-repositories. So, having
those repos checked out is not useful in that scenario.
When `skipIntegrityCheck` is unsupported, `build_nim.sh` uses the local
sub-repositories if they are available. But, it also clones them if they
are unavailable using commits as specified by environment variables.
Because the clone will happen as part of the script, having the repos
linked as sub-repositories is also not useful. Even worse, if the script
has different commit hashes than the subrepository, the behaviour is
different depending on whether `build_nim.sh` is run before or after
the submodules are checked out.
Therefore, we can remove the `Nim-csources-v1` and `nimble` sub-repos,
using the upstream build system if available, or the hardcoded commits
inside `build_nim.sh` to have a manual build, as before.
Also moves the various variables that control the used versions into
the manual section to emphasize that these only take effect in manual
mode, but not when using upstream build system (`skipIntegrityCheck`).
If one wants to use a custom `Nimble` version, fork `Nim` and adjust the
config in that fork. That also works with the upstream build system.
To configure submodule specific config overrides, allow passing
`$(GIT_SUBMODULE_CONFIG)` to `update-common`. Use case for `nimbus-eth2`
is to exclude a large file that we don't need from LFS checkout.
In #61 a regression was introduced where Nimble fails to build packages.
```
Prompt: No local packages.json found, download it from internet? -> [forced yes]
Downloading Official package list
Tip: 6 messages have been suppressed, use --verbose to show them.
Error: Refresh failed
... Could not download: No SSL/TLS CA certificates found.
Error: Process completed with exit code 1.
```
Ensure that CA cert is being downloaded once more, even when `koch`
supports `skipIntegrityCheck`.
* Fix checking out of recent Nim tags in shallow repo
When calling `git fetch` on a shallow repo, recent
tags or commits are refused. Fetching with `--tags`
ensures that the latest tags and the commits that
they point to are fetched.
More info:
https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---update-shallow
Co-authored-by: Tanguy <tanguy@status.im>
The model where nimbus-build-system.paths were generated as a dependency
from `update-common` proved to create various issues in practice:
* It was not working properly during the repository bootstrapping
because the paths file generation script is assuming that all
submodules are already checked out
* It was not always triggered from builds of the top-level targets
due to missing or already satisfied dependencies on `update-common`.
A more proper solution would structure the dependencies like this:
top-level-project -> nimbus-build-system.paths -> vendor-modules
... but this requires a larger refactoring of the Makefiles, so I'm
merging this interim solution as a way to improve the status quo.
Scripts sourcing a project env.sh file (e.g. direnv's .envrc) can specify
the `NBS_ONLY_LOAD_ENV_VARS` env variable to avoid any attempts from NBS
to execute a target script. Previously, the script was trying to detect
only sourcing from an interactive shell.
narimiran
andri lim
tersec
Etan Kissling
Jacek Sieka
Etan Kissling
richΛrd
Jakub Sokołowski
markspanbroek
Tanguy
Zahary Karadjov
Jordan Hrycaj
Ivan Yonchovski