New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python source code build fails with old mercurial #56555
Comments
Trying to build 2.7.2 from source on RHEL5 32 bit get errors: gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE Would assume it is bad form for a release source bundle to depend on mercurial? Diffs against version of getbuildinfo.c from 2.7.1 indicate that this is a new dependency: $ find . -name 'getbuildinfo.c' | xargs diff -u
--- ./Python-2.7.2/Modules/getbuildinfo.c 2011-06-11 16:46:27.000000000 +0100
+++ ./Python-2.7.1/Modules/getbuildinfo.c 2010-05-09 15:46:46.000000000 +0100
@@ -28,30 +28,15 @@
#define SVNVERSION "$WCRANGE$$WCMODS?M:$"
#endif -/* XXX Only unix build process has been tested */
-#ifndef HGVERSION
-#define HGVERSION ""
-#endif
-#ifndef HGTAG
-#define HGTAG ""
-#endif
-#ifndef HGBRANCH
-#define HGBRANCH ""
-#endif
-
const char *
Py_GetBuildInfo(void)
{
- static char buildinfo[50 + sizeof(HGVERSION) +
- ((sizeof(HGTAG) > sizeof(HGBRANCH)) ?
- sizeof(HGTAG) : sizeof(HGBRANCH))];
- const char *revision = _Py_hgversion();
+ static char buildinfo[50];
+ const char *revision = Py_SubversionRevision();
const char *sep = *revision ? ":" : "";
- const char *hgid = _Py_hgidentifier();
- if (!(*hgid))
- hgid = "default";
+ const char *branch = Py_SubversionShortBranch();
PyOS_snprintf(buildinfo, sizeof(buildinfo),
- "%s%s%s, %.20s, %.9s", hgid, sep, revision,
+ "%s%s%s, %.20s, %.9s", branch, sep, revision,
DATE, TIME);
return buildinfo;
}
@@ -65,21 +50,3 @@
return svnversion; /* it was interpolated, or passed on command line */
return "Unversioned directory";
}
-
-const char *
-_Py_hgversion(void)
-{
- return HGVERSION;
-}
-
-const char *
-_Py_hgidentifier(void)
-{
- const char *hgtag, *hgid;
- hgtag = HGTAG;
- if ((*hgtag) && strcmp(hgtag, "tip") != 0)
- hgid = hgtag;
- else
- hgid = HGBRANCH;
- return hgid;
-} |
Some more information: It has picked up that I have mercurial installed: [gw56@ws050 Python-2.7.2_cci]$ cat config.log | grep HG however it happens to be rather an old version: [gw56@ws050 Python-2.7.2_cci]$ hg --version Copyright (C) 2005, 2006 Matt Mackall <mpm@selenic.com> so does not recognise the command-line options that you are using. |
It used to be that the svn version info was pulled from embedded constants in Makefile.pre.in. I agree that depending on having mercurial (and, presumably, a repo!) at build time is wrong. These constants need to be pre-computed when a release tarball is built and the mercurial dependency removed from the generated Makefile. I'm not sure how we make that work correctly in a development build, but I'm sure the release managers will figure something out. |
Indeed, I just confirmed that building with a recent version of mercurial installed from the release 2.7.2 source tarball from python.org, the make results in: abort: repository . not found! during the build of getbuildinfo.c. Fortunately the only effect seems to be that sys._mercurial returns ('CPython, '', '') instead of the correct info. |
Ah. For subversion there was a similar check, and the values were set to blank if the subversion binary was not found. For hg it looks like we need to add additional checks on whether or not there is a repo. (We can probably assume that if there is a repo the correct version of mercurial is installed). |
trunk configure.in contains code that checks for the existence of a .hg repository. |
That needs to be ported to the other branches, then. Ezio, on a completely unrelated note, notice what happened to Ralf's reference. I think the regexes may need to be reordered. |
The regexes are now in the right order. |
So, it seems the problem is not actually that the build depends on mercurial, it's that it fails with ancient mercurials. |
Only if Ralf's patch is applied to all branches. Otherwise the make step reports "abort: repository . not found!", which most users will ignore but a few will report here. It looks from Ralf's quoted changeset like it was only applied to default, but frankly I'm not comfortable enough with mercurial yet to be able to tell. If Ralf's patch is applied, then the lack of a repository would cause the old hg to not get called. If someone *has* a repository in the build dir, I think we can assume they used a new enough hg to check it out...and if they didn't, that *is* a bug in their setup they should fix. |
Yes, it was committed to default.
|
435eec7b41f0 transplanted to 3.2 in 4e0c1128cda2. |
Is there anything left to do here? It doesn't appear to be a release blocker anymore. |
This is not fixed in 2.7.10. |
Luke: since this issue is closed, please open a new 2.7 only issue with a reference to this one. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: