Nim: compilation instruction should work for old versions of Nim, too

[krux02]

The problem is in the following line:

git clone --depth 1 https://github.com/nim-lang/csources.git
and in the readme here

The problem is, this clone process always clones the newest version of the bootstrapping compiler. This works fine for the newest version of the compiler, but when you want to build an older version of the compiler it might break. Nim has subtile but breaking changes and you can't build older versions of nim with a newer compiler and vice versa. All bootstrapping compiler sources are still available, but it is hard to pick the correct one manually. This causes problems when somebody wants to find a regression that has been introduced a long time ago, like in this issue https://github.com/nim-lang/Nim/issues/8188

The solution that I suggest is to put a file in the sources that contains the correct git hash of the bootstrapping compiler. Then the git clone doesn't clone the HEAD, but the hash that is stored in this file. So every time you jump back to a version it reads that file, and build-all.sh can check if the _csources_ are in the correct version to build the bootstrapping compiler. This won't fix the problem for versions that have already been released, but future versions of Nim will be easier to bootstrap when they get older.

[Araq]

I don't see why it's necessary, you can download the old stable versions from the website, which include the C sources, no external dependencies.

[krux02]

Well being able to download old stable versions is definively a good thing, but for git bisect it should be possible to build any version of Nim without manual intervention.

[timotheecour]

i agree on need to automate building older versions of compiler; but this logic could be made in choosenim instead, so it'd also apply to older versions (before any such feature is implemented); see also:

• choosenim 0.16.0 works but nothing before 0.16.0 works, eg error: "Version 0.15.0 does not exist" #66

[Araq]

git bisect doesn't work well enough to make a strong case. Ymmv.

[krux02]

I have used git bisect already to find the commit that introduced a breaking change successfully.

I don't quite understand the resistance here. This change is really not big at all, and it improves Nim reliability.

[Araq]

A file with a commit hash in it, manually maintained, doesn't feel like improving "Nim's reliability". Maybe I misunderstand the proposal though.

[krux02]

I never said it should be maintained manually. Currently I don't know how the process to release a new version is, but a file that has only a commit hash in it can be maintained automatically. That is also the reason why I suggest to put the hash in its own file. A file that contains only a commit hash can easily and reliably written by a machine.

[Araq]

And would the addition of this file then change the commit hash? in other words, would it be part of the Nim repo itself?

[krux02]

Yes, the hash of the csources would be part of Nim repo. Is that a problem?

[timotheecour]

just like in git submodules, the git hash of the submodule is part of the parent repo. Same thing.

[krux02]

@timotheecour good that you mention it. Maybe submodules are the proper way to implement this. But I have to read about them first before I can say this for sure.

[krux02]

I just read about git submodules. They don't have much love, because they appear to be something that they are not causing all sorts of problems. here is a list of reasons not to use submodules. But even after reading this, I think submodules are exactly what we need to store the hash of the c sources. But on the other hand I think submodules are way too complicated for the fact that they are nothing more than a hash of a dependency. Like everything in git seems to be way too complicated.

@timotheecour what do you think? Do you like submodules for this use case?

[Araq]

Well the csources are tagged with a release version, and old broken commits stay broken with your idea too. Closing.