homepage

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 \
 -DSVNVERSION="\"`LC_ALL=C svnversion .`\"" \
 -DHGVERSION="\"`LC_ALL=C hg id -i .`\"" \
 -DHGTAG="\"`LC_ALL=C hg id -t .`\"" \
 -DHGBRANCH="\"`LC_ALL=C hg id -b .`\"" \
 -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
hg identify: option -i not recognized
hg identify: option -t not recognized
hg identify: option -b not recognized
./Modules/getbuildinfo.c: In function ‘Py_GetBuildInfo’:
./Modules/getbuildinfo.c:45: error: missing terminating " character
./Modules/getbuildinfo.c:45: error: expected expression before ‘)’ token
./Modules/getbuildinfo.c:46: error: missing terminating " character
./Modules/getbuildinfo.c:46: error: missing terminating " character
./Modules/getbuildinfo.c:47: error: missing terminating " character
./Modules/getbuildinfo.c:47: error: missing terminating " character
./Modules/getbuildinfo.c:53: error: ‘buildinfo’ undeclared (first use in this function)
./Modules/getbuildinfo.c:53: error: (Each undeclared identifier is reported only once
./Modules/getbuildinfo.c:53: error: for each function it appears in.)
./Modules/getbuildinfo.c: In function ‘_Py_hgversion’:
./Modules/getbuildinfo.c:72: error: missing terminating " character
./Modules/getbuildinfo.c:72: warning: ‘return’ with no value, in function returning non-void
./Modules/getbuildinfo.c: In function ‘_Py_hgidentifier’:
./Modules/getbuildinfo.c:79: error: missing terminating " character
./Modules/getbuildinfo.c:79: error: expected expression before ‘;’ token
./Modules/getbuildinfo.c:83: error: missing terminating " character
./Modules/getbuildinfo.c:83: error: expected expression before ‘;’ token
make: *** [Modules/getbuildinfo.o] Error 1
gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE \
 -DSVNVERSION="\"`LC_ALL=C svnversion .`\"" \
 -DHGVERSION="\"`LC_ALL=C hg id -i .`\"" \
 -DHGTAG="\"`LC_ALL=C hg id -t .`\"" \
 -DHGBRANCH="\"`LC_ALL=C hg id -b .`\"" \
 -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
hg identify: option -i not recognized
hg identify: option -t not recognized
hg identify: option -b not recognized
./Modules/getbuildinfo.c: In function ‘Py_GetBuildInfo’:
./Modules/getbuildinfo.c:45: error: missing terminating " character
./Modules/getbuildinfo.c:45: error: expected expression before ‘)’ token
./Modules/getbuildinfo.c:46: error: missing terminating " character
./Modules/getbuildinfo.c:46: error: missing terminating " character
./Modules/getbuildinfo.c:47: error: missing terminating " character
./Modules/getbuildinfo.c:47: error: missing terminating " character
./Modules/getbuildinfo.c:53: error: ‘buildinfo’ undeclared (first use in this function)
./Modules/getbuildinfo.c:53: error: (Each undeclared identifier is reported only once
./Modules/getbuildinfo.c:53: error: for each function it appears in.)
./Modules/getbuildinfo.c: In function ‘_Py_hgversion’:
./Modules/getbuildinfo.c:72: error: missing terminating " character
./Modules/getbuildinfo.c:72: warning: ‘return’ with no value, in function returning non-void
./Modules/getbuildinfo.c: In function ‘_Py_hgidentifier’:
./Modules/getbuildinfo.c:79: error: missing terminating " character
./Modules/getbuildinfo.c:79: error: expected expression before ‘;’ token
./Modules/getbuildinfo.c:83: error: missing terminating " character
./Modules/getbuildinfo.c:83: error: expected expression before ‘;’ token
make: *** [Modules/getbuildinfo.o] Error 1
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
ac_cv_prog_HAS_HG=found
HAS_HG='found'
HGBRANCH='hg id -b $(srcdir)'
HGTAG='hg id -t $(srcdir)'
HGVERSION='hg id -i $(srcdir)'
however it happens to be rather an old version:
[gw56@ws050 Python-2.7.2_cci]$ hg --version
Mercurial Distributed SCM (version 0.9.3)
Copyright (C) 2005, 2006 Matt Mackall <mpm@selenic.com>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
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!
abort: repository . not found!
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.
See rev 435eec7b41f0 

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.
> 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.
Agreed.

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.