Build fails with weird errors if git is not on path
RussKeldorph opened this issue · 7 comments
From @vitek-karas on February 13, 2018 15:31
Running the build.cmd script (on Windows) from VS development environment without having git on path fails the build in a really weird way which is hard to figure out.
If this happens the error reported is:
E:\coreclr\bin\obj\_version.h(19): error RC2001: newline in constant [E:\coreclr\bin\obj\Windows_NT.x86.Debug\src\tools
\crossgen\crossgen.vcxproj]
Looking into this the _version.h has a line like this:
#define VER_PRODUCTVERSION_STR "4.6.26211.0 @BuiltBy: vitkaras-VITKARASD @Branch: 'git' is not recognized as an internal or external command,
operable program or batch file."
If the build really needs git (which in this case it could put some string instead into the version), then it should fail up front with a clear error message. Currently it fails during compilation and keeps on trying to compile and so on.
Copied from original issue: dotnet/coreclr#16356
From @danmosemsft on February 13, 2018 20:53
@wtgodbe maybe this was the issue you were hitting..
I would prefer to see if we can remove the git dependency by using gitattributes. For example, the commit hash can be gotten with ident. I think the branch name could be gotten as well with a bit more work, but I haven't worked through it completely.
I see these used in the build, but there are others in the .targets files.
git rev-parse --abbrev-ref HEAD
git rev-parse HEAD
git show -s --format=%cd --date=short HEAD
On my Windows box it just says
'git' is not recognized as an internal or external command,
operable program or batch file.
but then carries on regardless.
Is there much value in eliminating a git dependency? It could regress periodically.
@danmosemsft What I'm proposing is in some sense not removing the Git dependency. It's just unifying it with the other dependency we already have--synch'ing the source tree with the remote. Git supports adding information like above to "meta-files" in the tree via variable substitution or other means. Then, at build time, rather than having to invoke Git, the info we need looks like it was checked in because it is generated at the same time Git last updated the tree.
The advantage is conceptually similar to the advantage of being able to restore everything necessary for the build and then drop the network dependency from that point forward. I acknowledge that dropping the Git dependency is less valuable given the pervasiveness of Git, but you could for example imagine someone expecting to use VS's Git client only without installing the official Git CLI.
I don't object to fixing this just by warning or erroring if the command fails, but I think there's a cleaner solution. I don't think it's more likely to regress if implemented properly.
In repo root, if you try cat .git/FETCH_HEAD, most likely it will list the current branch and hash etc.
This will probably be fixed by #1980 "Add graceful error handling to Git branch fetch" which I'm planning to do soon to remove a workaround in the dotnet/source-build repo. The plan is basically to start caring about the exit code, so it should catch this case.
This was fixed in #1977. (Thanks @vancem!) CoreCLR and CoreFX master got buildtools updates in the last few days, so they should have it.
I ran a clean CoreCLR build on linux with git renamed to git_. It logged git: command not found', and created version files that just didn't try to include the branch.