Bug #30708 make relies GNU extentions
Submitted: 29 Aug 2007 22:36 Modified: 20 May 2010 15:58
Reporter: Brian Aker Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Compiling Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: Jonathan Perkin CPU Architecture:Any

[29 Aug 2007 22:36] Brian Aker
Description:
We are now requiring gnu make. 

We get this error:
BUILD/Makefile.am:69: `%'-style pattern rules are a GNU make extension
Docs/Makefile.am:69: `%'-style pattern rules are a GNU make extension
client/Makefile.am:122: `%'-style pattern rules are a GNU make extension
client/Makefile.am:82: compiling `mysqlslap.c' with per-target flags requires `AM_PROG_CC_C_O' in `configure.in'
client/Makefile.am: installing `./depcomp'
cmd-line-utils/Makefile.am:24: `%'-style pattern rules are a GNU make extension
cmd-line-utils/libedit/Makefile.am:100: `%'-style pattern rules are a GNU make extension
cmd-line-utils/readline/Makefile.am:37: `%'-style pattern rules are a GNU make extension
dbug/Makefile.am:65: `%'-style pattern rules are a GNU make extension
debian/Makefile.am:117: `%'-style pattern rules are a GNU make extension
extra/Makefile.am:54: `%'-style pattern rules are a GNU make extension
extra/yassl/Makefile.am:6: `%'-style pattern rules are a GNU make extension
extra/yassl/src/Makefile.am:7: wildcard ../include/*.hpp: non-POSIX variable name
extra/yassl/src/Makefile.am:7: (probably a GNU make extension)
extra/yassl/src/Makefile.am:7: wildcard ../include/openssl/*.h: non-POSIX variable name
extra/yassl/src/Makefile.am:7: (probably a GNU make extension)
extra/yassl/src/Makefile.am:11: `%'-style pattern rules are a GNU make extension
extra/yassl/taocrypt/Makefile.am:2: wildcard mySTL/*.hpp: non-POSIX variable name
extra/yassl/taocrypt/Makefile.am:2: (probably a GNU make extension)
extra/yassl/taocrypt/Makefile.am:5: `%'-style pattern rules are a GNU make extension
extra/yassl/taocrypt/benchmark/Makefile.am:9: `%'-style pattern rules are a GNU make extension
extra/yassl/taocrypt/src/Makefile.am:13: wildcard ../include/*.hpp: non-POSIX variable name
extra/yassl/taocrypt/src/Makefile.am:13: (probably a GNU make extension)
extra/yassl/taocrypt/src/Makefile.am:16: `%'-style pattern rules are a GNU make extension
extra/yassl/taocrypt/test/Makefile.am:9: `%'-style pattern rules are a GNU make extension
extra/yassl/testsuite/Makefile.am:13: `%'-style pattern rules are a GNU make extension
include/Makefile.am:82: `%'-style pattern rules are a GNU make extension
libmysql/Makefile.shared:119: `%'-style pattern rules are a GNU make extension
libmysql/Makefile.am:29:   `libmysql/Makefile.shared' included from here
libmysql/Makefile.am:117: `%'-style pattern rules are a GNU make extension
libmysql/Makefile.shared:119: `%'-style pattern rules are a GNU make extension
libmysql_r/Makefile.am:30:   `libmysql/Makefile.shared' included from here
libmysql_r/Makefile.am:47: `%'-style pattern rules are a GNU make extension
libmysqld/Makefile.am:234: `%'-style pattern rules are a GNU make extension
libmysqld/examples/Makefile.am:55: `%'-style pattern rules are a GNU make extension
man/Makefile.am:25: `%'-style pattern rules are a GNU make extension
mysql-test/Makefile.am:165: `%'-style pattern rules are a GNU make extension
mysql-test/ndb/Makefile.am:23: `%'-style pattern rules are a GNU make extension
mysys/Makefile.am:130: `%'-style pattern rules are a GNU make extension
etc...

How to repeat:
See above. Run ./BUILD/compile-amd64-max

Suggested fix:
Rewrite :)
[30 Aug 2007 3:53] Valeriy Kravchuk
Thank you for a problem report. I'd treat it as feature request, but as our manual (http://dev.mysql.com/doc/refman/5.0/en/quick-install.html) does NOT say explicitely that GNU make is needed while installing from source, let this be a bug.

Note that http://dev.mysql.com/doc/refman/5.0/en/installing-source-tree.html do have an explicit GNU make recommendation:

"You need GNU make, autoconf 2.58 (or newer), automake 1.8.1, libtool 1.5, and m4 to run the next set of commands. Even though many operating systems come with their own implementation of make, chances are high that the compilation fails with strange error messages. Therefore, it is highly recommended that you use GNU make (sometimes named gmake) instead."
[30 Aug 2007 4:06] Brian Aker
We should either remove the dependency or add a rule to configure.in to check for the correct make version.
[14 Sep 2007 12:09] Bent Terp
How can this problem surface on a Fedora 7 box?
[bent@localhost ~]$ rpmquery automake autoconf make gcc
automake-1.10-5
autoconf-2.61-8.fc7
make-3.81-6.fc7
gcc-4.1.2-17

Weirdness.
[14 Sep 2007 12:37] Bent Terp
Ah, okay! Adding -Wno-portability to automake seems to do the trick
[11 Jan 2008 15:11] Jonathan Perkin
As far as I can see, we have four options:

1.  Require GNU make.  Probably the easiest to implement, but decreases portability, which would be a real shame if the only reason for doing so were to be to workaround this SCCS issue.  Ideally GNU make would have a more portable way of turning off builtin rules (via MAKE_OPTIONS or something).

2.  Change the SCCS handling to instead redefine 'GET = :', turning the rule into a nop.  Unfortunately, as make outputs the commands being ran, this ends up looking rather ugly given it is ran for every target, for example:

  $ make -f Makefile
  :   SCCS/s.Makefile.am
  :   SCCS/s.configure.in
  make  all-recursive
  Making all in .
  make[2]: Nothing to be done for `all-am'.
  Making all in include
  :   ../SCCS/s.configure.in
  make  all-am
  :   ../SCCS/s.configure.in
  Making all in Docs
  :   ../SCCS/s.configure.in
  [...]

3.  Move SCCS handling into a seperate GNUmakefile which includes the main Makefile.  GNU make will use GNUmakefile and correctly disable the SCCS handling, while other make implementations will Makefile and happily ignore it.  Perhaps the most pragmatic solution, however it bulks the source tree out with many extra files just to accomodate this one problem, and poses possible confusion as you now have two active makefiles.

4.  Remove the SCCS handling and revert to default GNU make behaviour.  Developers would (as I understand it), be forced to build in clean trees to avoid the make failing when a writeable checked-out file exists and the SCCS version is newer.

Comments appreciated.
[13 Jan 2008 16:25] Sergei Golubchik
I'd prefer the 4th option. auto-checkout is convenient, sometimes I even want it (and for such a case I have a script that removes SCCS line in all Makefile's in a tree)
[22 Feb 2008 21:34] Omer Barnir
workaround: Use GNU
[12 Dec 2008 13:09] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/61481

2796 Jonathan Perkin	2008-12-12
      bug#30708: make relies GNU extensions.  Now that we no longer use
      BitKeeper we can safely remove the SCCS handling with no loss of
      functionality.
[16 Dec 2008 17:10] Joerg Bruehe
Approved.

We still have some warnings about other GNU-specific features, but IMO we should leave them to a second round:

extra/yassl/src/Makefile.am:7: wildcard ../include/*.hpp: non-POSIX variable name
extra/yassl/src/Makefile.am:7: (probably a GNU make extension)
extra/yassl/src/Makefile.am:7: wildcard ../include/openssl/*.h: non-POSIX variable name
extra/yassl/src/Makefile.am:7: (probably a GNU make extension)

extra/yassl/taocrypt/Makefile.am:2: wildcard mySTL/*.hpp: non-POSIX variable name
extra/yassl/taocrypt/Makefile.am:2: (probably a GNU make extension)

extra/yassl/taocrypt/src/Makefile.am:13: wildcard ../include/*.hpp: non-POSIX variable name
extra/yassl/taocrypt/src/Makefile.am:13: (probably a GNU make extension)
[16 Mar 2009 17:04] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/69325

2744 Jonathan Perkin	2009-03-16
      bug#30708: make relies GNU extensions.  Remove the last couple of '%'-style
      pattern rules.
[6 May 2009 14:08] Bugs System
Pushed into 6.0.12-alpha (revid:svoj@sun.com-20090506125450-yokcmvqf2g7jhujq) (version source revid:timothy.smith@sun.com-20090402052930-78npdzhwd7hg7dav) (merge vers: 6.0.11-alpha) (pib:6)
[28 Sep 2009 18:23] Jonathan Perkin
Patches to remove SCCS handling were pushed into 6.0 tree and will hopefully make their way to a release one day.
[19 May 2010 13:01] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/108625

3052 Alexander Nozdrin	2010-05-19
      Another incarnation of the patch for Bug#30708
      (make relies GNU extentions). The patch was partially
      backport from 6.0.
      
      Original comment:
      bug#30708: make relies GNU extensions.  Now that we no longer use
      BitKeeper we can safely remove the SCCS handling with no loss of
      functionality.
[20 May 2010 10:03] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100520100225-oe4iuu5kuzsx0knq) (version source revid:alik@sun.com-20100520100057-rmn5y3o3ij726bm7) (merge vers: 6.0.14-alpha) (pib:16)
[20 May 2010 10:04] Bugs System
Pushed into 5.5.5-m3 (revid:alik@sun.com-20100520100041-rf8ujv598zf86wjt) (version source revid:alik@sun.com-20100520100041-rf8ujv598zf86wjt) (merge vers: 5.5.5-m3) (pib:16)
[20 May 2010 10:06] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100520100140-5bzrtadw4w419i3m) (version source revid:alik@sun.com-20100520100049-1njm09rkvnhmysnr) (pib:16)
[20 May 2010 15:58] Paul Dubois
Noted in 5.5.5, 6.0.14 changelogs.

MySQL Makefiles relied on GNU extentions.