Make zn_poly respect the CC environment variable, work around GCC 4.7.0 bug on ia64 (and clean up the spkg)

[ohanar]

The zn_poly spkg currently does not respect the CC environment variable, we should fix this (for instance for #12426).

New spkg: ​http://boxen.math.washington.edu/home/leif/Sage/spkgs/zn_poly-0.9.p8.spkg

md5sum: f0a331ed68c28b748c2d3ca3bade9865 zn_poly-0.9.p8.spkg

zn_poly-0.9.p8 (Leif Leonhardy, April 20th, 2012)

• #12433: Further reviewer changes / additions.
• Work around GCC 4.7.0 bug on ia64 (by almost completely disabling optimi- zation if the compiler is GCC 4.7.x, of course only on that platform); cf. #12751, #12765.
• Add a patch to avoid conflicting definitions (i.e., redundant typedefs) of ulong, by changing ulong to a macro.
• Don't hardcode the zn_poly version number in spkg-install; instead read it from the file VERSION, like the generated makefile does.
• Remove some of the code previously just commented out, as well as some obsolete comments.
• Document patches (and correct ticket reference in an old changelog entry).

zn_poly-0.9.p7 (Leif Leonhardy, April 8th, 2012)

• #12433: Reviewer changes.
• Restore upstream sources. (One file in src/tune/ was already patched.)
• Remove the obsolete Debian dist/ directory.
• Use patch to apply the patches.
• Remove patches/ from .hgignore! (And remove the prepatched files.)
• Add Python to the dependencies, since (some) Python is needed to create the Makefile during build / configure. (spkg/standard/deps already reflects this.)
• Rework (upstream's) makemakefile.py to create a proper Makefile, respecting CC, CXX, CFLAGS, CXXFLAGS, CPPFLAGS etc. with their *usual* meaning (i.e., not using CPP to compile C++!), and using LDFLAGS consistently, also not hardcoding e.g. -m64 (which was added by Sage).
• Do not add -O3 to CFLAGS (in spkg-install) without the possibility to get overridden by user-provided CFLAGS. Also honor SAGE_DEBUG=yes by completely disabling optimization in that case.
• Fix typo in spkg-check, which certainly would break building the test program when SAGE64=yes. (Although it is actually already built from within spkg-install.)
• Clean up spkg-install and spkg-check; redirect error messages to stderr, add more error checks, use $MAKE in spkg-check as well, quote more environment variables, use cp [-f] instead of $CP, don't create an absolute symbolic link on Cygwin.

zn_poly-0.9.p6 (R. Andrew Ohana, February 4th, 2012)

• #12433: Make spkg respect global CC flag

[ohanar]

for review purposes

[leif]

Same here: $CC has to be quoted.

[leif]

Oh, the zn_poly spkg is a real mess... :-)

I'll make a p7 cleaning up spkg-install and spkg-check, removing the obsolete Debian stuff, using patch to apply the patches, and -- more importantly -- modifying makemakefile.py to produce a proper Makefile, respecting CC (and CXX, not CPP!, likewise CXXFLAGS instead of CPPFLAGS, and using CPPFLAGS for what they're meant to be used), using LDFLAGS consistently...

Then we won't have to use $MAKE ... CC=... etc.

[leif]

Diff between Andrew's and my new spkg. For reference / review only.

[leif]

Diff between the previous spkg in Sage and my new spkg. For reference / review only.

[leif]

Ok, here's something to review... :P

Left a few TODOs, as well as a lot of (hopefully obsolete) code I just commented out right now.

I've attached diffs between the p5, p6 and p7 spkgs, and the new patch to makemakefile.py, too, for easier reviewing. (You don't have to apply any of these.)

[leif]

Personal note: Add a work-around for GCC 4.7.0 on ia64 (cf. #12765).

[leif]

Replying to leif:

Personal note: Add a work-around for GCC 4.7.0 on ia64 (cf. #12765).

... and probably add a patch to #define rather than typedef ulong.

[leif]

Replying to leif:

Replying to leif:

Personal note: Add a work-around for GCC 4.7.0 on ia64 (cf. #12765).

... and probably add a patch to #define rather than typedef ulong.

Did so.

David, does that fix your issue?

[leif]

Diff between my p7 and p8 spkgs. For reference / review only.

[jdemeyer]

Diff between the p5 and p8 spkgs. For reference / review only.

[jdemeyer]

New / modified patch to src/makemakefile.py. For easier review only; do not apply.

[jdemeyer]

Looks good to me. There will be a follow-up at #12751 to remove the GCC-4.7.x Itanium work-around.

[Snark]

I have two questions :

1. have the modifications to upstream makemakefile.py been forwarded upstream?
2. wouldn't it have been simpler to write an autotools-based build system? [to forward upstream too]

[jdemeyer]

Replying to Snark:

I have two questions :

1. have the modifications to upstream makemakefile.py been forwarded upstream?

I don't think so.

2. wouldn't it have been simpler to write an autotools-based build system? [to forward upstream too]

Certainly not simpler. Maybe better, yes. Also, would upstream accept it?