bison: update to 3.0.2

[akimd (Akim Demaille)]

This version addresses the problem of the yacc man page.

--- /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/bison/Portfile	2013-08-03 00:30:21.000000000 +0200
+++ /tmp/Portfile	2013-11-29 18:30:50.000000000 +0100
@@ -1,9 +1,10 @@
+# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
 # $Id: Portfile 108830 2013-08-02 22:11:18Z jeremyhu@macports.org $
 
 PortSystem 1.0
 
 name                bison
-version             2.7.1
+version             3.0.1
 epoch               1
 categories          devel
 maintainers         mww
@@ -20,8 +21,8 @@
 
 homepage            http://www.gnu.org/software/bison/
 master_sites        gnu
-checksums           rmd160  933257e61c1098160d4fd71063f340b2ee304671 \
-                    sha256  b409adcbf245baadb68d2f66accf6fdca5e282cafec1b865f4b5e963ba8ea7fb
+checksums           rmd160  bc2357e0253857e6c5b19ad1b4c6e5f27472bd28 \
+                    sha256  944efb03b46d831cef452bfa44620e5b30f7de999902a70d96021a0a77f5a2cb
 use_xz              yes
 
 depends_lib         port:gettext port:m4 port:libiconv
@@ -46,10 +47,6 @@
         calc++-scanner.cc calc++-scanner.ll calc++.cc location.hh \
         position.hh stack.hh test \
         ${destroot}${docdir}/examples/calc++
-    # yacc manpage gets installed even with '--disable-yacc'
-    if {! [variant_isset yacc]} {
-        delete ${destroot}${prefix}/share/man/man1/yacc.1
-    }
 }
 
 variant yacc description "enable yacc compatibility" {
@@ -59,4 +56,3 @@
 livecheck.type      regex
 livecheck.url       http://ftp.gnu.org/gnu/bison/?C=M&O=D
 livecheck.regex     ${name}-(\\d+(?:\\.\\d+)*)
-

[cooljeanius (Eric Gallager)]

bison3 has incompatibilities with bison2: see #39910

[akimd (Akim Demaille)]

Hi Eric,

Thanks for pointing the ticket to me, I had not seen it. However, it is my reading of a ticket that the upstream packages have been fixed, so maybe we could try again with Bison 3? One of the issues shows an easy workaround for packages that have still not been updated, namely %lex-param { LEX_PARAM } (works with both 3 and pre-3 Bisons). I'd be happy to give a hand to adjusting remainnig packages that don't work with Bison 3, just tell me where to look at.

[akimd (Akim Demaille)]

Hi,

Bison 3.0.2 is out too.

--- Portfile.2.7.1	2013-12-09 14:07:38.000000000 +0100
+++ Portfile.3.0.2	2013-12-09 14:09:33.000000000 +0100
@@ -1,9 +1,10 @@
+# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
 # $Id: Portfile 108830 2013-08-02 22:11:18Z jeremyhu@macports.org $
 
 PortSystem 1.0
 
 name                bison
-version             2.7.1
+version             3.0.2
 epoch               1
 categories          devel
 maintainers         mww
@@ -20,8 +21,8 @@
 
 homepage            http://www.gnu.org/software/bison/
 master_sites        gnu
-checksums           rmd160  933257e61c1098160d4fd71063f340b2ee304671 \
-                    sha256  b409adcbf245baadb68d2f66accf6fdca5e282cafec1b865f4b5e963ba8ea7fb
+checksums           rmd160  0a945ce5710a79332fbe594255305f244c24dd74 \
+                    sha256  a2c3e8528bdb50567d6fa26deeb493dc5ccd7e277b865251608a9e43ac928f3c
 use_xz              yes
 
 depends_lib         port:gettext port:m4 port:libiconv
@@ -46,10 +47,6 @@
         calc++-scanner.cc calc++-scanner.ll calc++.cc location.hh \
         position.hh stack.hh test \
         ${destroot}${docdir}/examples/calc++
-    # yacc manpage gets installed even with '--disable-yacc'
-    if {! [variant_isset yacc]} {
-        delete ${destroot}${prefix}/share/man/man1/yacc.1
-    }
 }
 
 variant yacc description "enable yacc compatibility" {
@@ -59,4 +56,3 @@
 livecheck.type      regex
 livecheck.url       http://ftp.gnu.org/gnu/bison/?C=M&O=D
 livecheck.regex     ${name}-(\\d+(?:\\.\\d+)*)
-

[akimd (Akim Demaille)]

Ping! There are features on Bison 3.0 that some packages use, and currently one has to install it by hand instead of relying on MacPorts.

[cooljeanius (Eric Gallager)]

Cc Me!

[mf2k (Frank Schima)]

Please instead attach your .diff file(s) instead of pasting them inline.

[akimd (Akim Demaille)]

2.7.1 to 3.0.2

[ryandesign (Ryan Carsten Schmidt)]

So, have we verified that e.g. #39909 doesn't happen anymore with bison 3.0.2?

[akimd (Akim Demaille)]

Seems to work.

$ sudo port build gstreamer1
--->  Computing dependencies for gstreamer1
--->  Dependencies to be installed: gzip
--->  Fetching archive for gzip
--->  Attempting to fetch gzip-1.6_0.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/gzip
--->  Attempting to fetch gzip-1.6_0.darwin_13.x86_64.tbz2.rmd160 from http://lil.fr.packages.macports.org/gzip
--->  Installing gzip @1.6_0
--->  Activating gzip @1.6_0
--->  Cleaning gzip
--->  Fetching distfiles for gstreamer1
--->  Attempting to fetch gstreamer-1.2.2.tar.xz from http://lil.fr.distfiles.macports.org/gstreamer1
--->  Verifying checksums for gstreamer1
--->  Extracting gstreamer1
--->  Configuring gstreamer1
--->  Building gstreamer1
$ /opt/local/bin/bison --version
bison (GNU Bison) 3.0.2
Écrit par Robert Corbett et Richard Stallman.

Copyright © 2013 Free Software Foundation, Inc.
Ce logiciel est libre; voir les sources pour les conditions de
reproduction. AUCUNE garantie n'est donnée; tant pour des raisons
COMMERCIALES que pour RÉPONDRE À UN BESOIN PARTICULIER.

[akimd (Akim Demaille)]

Ping!

[c9s (Yo-An Lin)]

Ping!

[RJVB (René Bertin)]

Cc Me!

[akimd (Akim Demaille)]

Ping again. Can we please get rid of 2.7?

[RJVB (René Bertin)]

There are applications that don't work with bison 3 (xxdiff comes to mind). So I'd be all for keeping a bison-2 port in addition to having the latest version.

[akimd (Akim Demaille)]

It seems that xxdiff was fixed, ​http://sourceforge.net/p/xxdiff/bugs/229/

We won't know much about the programs that still need to be adjusted if we don't move to Bison 3.

[RJVB (René Bertin)]

Replying to akim.demaille@…:

It seems that xxdiff was fixed, ​http://sourceforge.net/p/xxdiff/bugs/229/

Indeed, but it also seems that the patch hasn't yet made it to a source tarball. Nor is it clear what exactly the patch is, the author mentions "another patch" a few months after someone posted one.

We won't know much about the programs that still need to be adjusted if we don't move to Bison 3.

Fair enough, but for those ports it'd be nice if Bison 2 remained available, so that their maintainers can tweak their build system to use that version.

[akimd (Akim Demaille)]

Ping again. This ticket is one year old. What can we do to have this go forward?

[evandrix (Lee Wei Yeong)]

Cc Me!

[etienne.renault@…]

Cc Me!

[akimd (Akim Demaille)]

Bison 3.0.4 was released. Can someone please upgrade this port? What can I do to help?

[RJVB (René Bertin)]

Replying to akim.demaille@…:

What can I do to help?

Apply the diff, build the 3.0.4 version of the port as well as the bison-2 subport, and check things.

[akimd (Akim Demaille)]

Replying to rjvbertin@…:

Apply the diff, build the 3.0.4 version of the port as well as the bison-2 subport, and check things.

<3 you!

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

Apply the diff

Please attach a unified diff.

[larryv (Lawrence Velázquez)]

Replying to akim.demaille@…:

I have fixed the install rules so that all the examples be installed. It's a pity that Bison does not install them by itself.

Do we really want to install the examples’ intermediate products (e.g., calc++-parser.cc, calc++-parser.hh, etc.)? Seems really weird to me.

[larryv (Lawrence Velázquez)]

Does omitting the --disable-yacc configure option change the build (other than installing the yacc executable, static library, and man page)? Is there a good reason we shouldn’t just do that always and get rid of the yacc variant?

[larryv (Lawrence Velázquez)]

The ​PACKAGING file suggests distributing Bison as two separate packages, but that file hasn’t changed much during its ​decade of existence, and my cursory examination of ​Arch’s and ​Debian’s packaging suggests that other distributions tend to disregard it.

Does upstream (i.e., you) care about this? It would be easy enough to split the port, but I don’t want to do so if PACKAGING is no longer relevant.

[RJVB (René Bertin)]

Who is *you* here?

Currently the portfile indicates that it doesn't install libraries, and that appears to be true. I don't think it's a particularly good idea to split up the package in this case. There are times where I appreciate Debian's way of splitting up things and wished things were done the same way in MacPorts, but most of the time it just adds extra work. Remember that Debian creates split-up packages *after* building the full project *once* (I presume Arch would do the same). MacPorts doesn't allow that kind of efficiency AFAIK.

I'd be in favour of merging the +yacc variant into the main port, and also wondered about the examples. In fact, I'd be in favour of moving the examples to a variant; most people are probably not interested in them anyway because they install bison only as a result of some automatic dependency. (And most who do use the application won't need examples anymore.)

[akimd (Akim Demaille)]

Replying to larryv@…:

Replying to akim.demaille@…:

I have fixed the install rules so that all the examples be installed. It's a pity that Bison does not install them by itself.

Do we really want to install the examples’ intermediate products (e.g., calc++-parser.cc, calc++-parser.hh, etc.)? Seems really weird to me.

Hi!

You are right, this is debatable.

Besides, since I first discovered that Bison did not install the examples itself, I fixed it in the following release (and the "intermediate products" are _not_installed, only the sources). So I expect that this part of the patch is no longer needed. I don't have time right now to check that, but unless someone beats me, I will in the near future.

[akimd (Akim Demaille)]

Replying to larryv@…:

Does omitting the --disable-yacc configure option change the build (other than installing the yacc executable, static library, and man page)? Is there a good reason we shouldn’t just do that always and get rid of the yacc variant?

if ENABLE_YACC
bin_SCRIPTS = src/yacc
endif
EXTRA_SCRIPTS = src/yacc
MOSTLYCLEANFILES += src/yacc

So if --disable-yacc is passed, yacc is not built by default (i.e., make) but make src/yacc would work.

I personally don't understand the point of not installing yacc. Bison is designed to provide compatibility with yacc (when given --yacc), and that's precisely the point of yacc: to provide the user with a POSIX Yacc. We are talking about a shell-script of a couple of lines, why the bother? Byacc has always been called byacc, not yacc.

[akimd (Akim Demaille)]

Replying to larryv@…:

The ​PACKAGING file suggests distributing Bison as two separate packages, but that file hasn’t changed much during its ​decade of existence, and my cursory examination of ​Arch’s and ​Debian’s packaging suggests that other distributions tend to disregard it.

Does upstream (i.e., you) care about this? It would be easy enough to split the port, but I don’t want to do so if PACKAGING is no longer relevant.

The double packaging issue here is really special: bison generates parsers that can generate error messages that are translatable (and whose translation is provided by the suggested second package). So it may perfectly happen that a package that uses a parser generated by bison will produce translated error messages except parse-error error messages. Unless you install Bison just to get the translation of the its error message.

So it is "benign" in the sense that the only damage is that parser error messages will be in English. I personally don't care much if there is a single package, but I would understand if someone were to have a different opinion.

[akimd (Akim Demaille)]

Replying to rjvbertin@…:

Who is *you* here?

Currently the portfile indicates that it doesn't install libraries, and that appears to be true. I don't think it's a particularly good idea to split up the package in this case.

Actually POSIX requires that we provide a liby. It's stupid and useless, but that just POSIX conformance. And since I would rather recommend installing yacc, I would also recommend installing liby. *However*, you can rest assured that no serious project would ever use this liby, it's really only meant for beginner experimenting their first parser. So do not bother making a separate package for liby, it really makes no sense.

The case of the internationalization of the error messages is more relevant, however.

I'd be in favour of merging the +yacc variant into the main port, and also wondered about the examples. In fact, I'd be in favour of moving the examples to a variant; most people are probably not interested in them anyway because they install bison only as a result of some automatic dependency. (And most who do use the application won't need examples anymore.)

I disagree here. Bison is rarely a dependency since most packages ship their generated parser and don't need Bison at all from the end user point of view. So installing Bison is rather to use Bison yourself. In which case the documentation (and the examples do belong to the documentation) makes perfect sense.

[RJVB (René Bertin)]

AFAIAC it's become (or has been becoming) practice in MacPorts to provide documentation and/or examples in separate variants. But there doesn't appear to be a configure option to skip building the examples, right?

Oh, and I have about 61 ports that are registered rdependents on bison, 8 direct dependents (including big ones like kde4-runtime and webkit-gtk*), and yet I rarely if ever used bison myself.

[RJVB (René Bertin)]

Does this look complete (from 3.0.4)?

 ll -R bison-mp9-work/destroot/opt/local/share/doc/bison/
bison-mp9-work/destroot/opt/local/share/doc/bison/:
total 520
12538176   0 drwxr-xr-x 3 bertin admin    340 Mar  4 17:28 ./
12538175   0 drwxr-xr-x 3 bertin admin    102 Mar  4 17:28 ../
12538226   4 -r--r--r-- 1 bertin admin   1460 Mar  4 17:28 AUTHORS
12538227  36 -r--r--r-- 1 bertin admin  35147 Mar  4 17:28 COPYING
12538228 348 -r--r--r-- 1 bertin admin 355453 Mar  4 17:28 ChangeLog
12538229 100 -r--r--r-- 1 bertin admin 100610 Mar  4 17:28 NEWS
12538187   4 -rw-r--r-- 1 bertin admin   2289 Mar  4 17:28 README
12538230  12 -r--r--r-- 1 bertin admin   8610 Mar  4 17:28 THANKS
12538231  16 -r--r--r-- 1 bertin admin  14141 Mar  4 17:28 TODO
12538177   0 drwxr-xr-x 5 bertin admin    170 Mar  4 17:28 examples/

bison-mp9-work/destroot/opt/local/share/doc/bison/examples:
total 0
12538177 0 drwxr-xr-x 5 bertin admin 170 Mar  4 17:28 ./
12538176 0 drwxr-xr-x 3 bertin admin 340 Mar  4 17:28 ../
12538178 0 drwxr-xr-x 2 bertin admin 238 Mar  4 17:28 calc++/
12538221 0 drwxr-xr-x 2 bertin admin 136 Mar  4 17:28 mfcalc/
12538224 0 drwxr-xr-x 2 bertin admin 102 Mar  4 17:28 rpcalc/

bison-mp9-work/destroot/opt/local/share/doc/bison/examples/calc++:
total 20
12538178 0 drwxr-xr-x 2 bertin admin  238 Mar  4 17:28 ./
12538177 0 drwxr-xr-x 5 bertin admin  170 Mar  4 17:28 ../
12538179 4 -rw-r--r-- 1 bertin admin  653 Mar  4 17:28 calc++-driver.cc
12538180 4 -rw-r--r-- 1 bertin admin 1009 Mar  4 17:28 calc++-driver.hh
12538183 4 -rw-r--r-- 1 bertin admin 1442 Mar  4 17:28 calc++-parser.yy
12538181 4 -rw-r--r-- 1 bertin admin 1921 Mar  4 17:28 calc++-scanner.ll
12538182 4 -rw-r--r-- 1 bertin admin  438 Mar  4 17:28 calc++.cc

bison-mp9-work/destroot/opt/local/share/doc/bison/examples/mfcalc:
total 12
12538221 0 drwxr-xr-x 2 bertin admin  136 Mar  4 17:28 ./
12538177 0 drwxr-xr-x 5 bertin admin  170 Mar  4 17:28 ../
12538222 4 -rw-r--r-- 1 bertin admin  555 Mar  4 17:28 calc.h
12538223 8 -rw-r--r-- 1 bertin admin 4700 Mar  4 17:28 mfcalc.y

bison-mp9-work/destroot/opt/local/share/doc/bison/examples/rpcalc:
total 4
12538224 0 drwxr-xr-x 2 bertin admin  102 Mar  4 17:28 ./
12538177 0 drwxr-xr-x 5 bertin admin  170 Mar  4 17:28 ../
12538225 4 -rw-r--r-- 1 bertin admin 1445 Mar  4 17:28 rpcalc.y

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

Who is *you* here?

Akim, who is one of the upstream maintainers.

[RJVB (René Bertin)]

I understood that now, but his rather urgent request to provide an updated portfile suggested otherwise, at first glance :)

[larryv (Lawrence Velázquez)]

Replying to akim.demaille@…:

Besides, since I first discovered that Bison did not install the examples itself, I fixed it in the following release (and the "intermediate products" are _not_installed, only the sources). So I expect that this part of the patch is no longer needed.

You’re right, the example source gets installed fine without the extra build targets. Most of the post-destroot script is now unnecessary, too.

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

AFAIAC it's become (or has been becoming) practice in MacPorts to provide documentation and/or examples in separate variants.

Sort of. We prefer installing documentation unconditionally, but some maintainers don’t because their ports have a significant amount of it or require extra dependencies to build it (AsciiDoc, doxygen, Sphinx, etc.).

[RJVB (René Bertin)]

Well, this user also prefers it, because documentation (and internationalisation) files can add up to a significant amount of disk space ... and I rarely use it. Except for some documentation that I installed explicitly (Qt & KDE docs). And except manpages (but those seem to be becoming a rare commodity).

[RJVB (René Bertin)]

2.7.1 -> 3.0.4 with a bison-2 subport

[akimd (Akim Demaille)]

Hi!

Replying to rjvbertin@…:

Does this look complete (from 3.0.4)?

It looks perfect, thanks!

[akimd (Akim Demaille)]

Hi!

Thanks for your time spent on this issue.

Replying to rjvbertin@…:

Well, this user also prefers it, because documentation (and internationalisation) files can add up to a significant amount of disk space ... and I rarely use it. Except for some documentation that I installed explicitly (Qt & KDE docs). And except manpages (but those seem to be becoming a rare commodity).

We're taking about an info file here, which is 537KB uncompressed, and 147KB when gzipped, and 112KB with bzip2, all of which are properly read by the info reader. Why do we install man pages compressed, but no info files? And why keep all the ChangeLog etc. uncompressed too? (Heck, I'd rather see those 355KB of ChangeLog not be installed at all, and have the documentation! The priorities are really wrong here IMHO).

FWIW, this is a Debian machine:

~ % ls /usr/share/info/
automake-1.14.info.gz    fastjar.info.gz              help2man-de.info.gz  recode.info-5.gz
automake-1.14.info-1.gz  find.info.gz                 help2man-fr.info.gz  recode.info-6.gz
automake-1.14.info-2.gz  flex.info.gz                 help2man-pl.info.gz  recode.info-7.gz
autosprintf.info.gz      flex.info-1.gz               help2man-uk.info.gz  rluserman.info.gz
bc.info.gz               flex.info-2.gz               kpathsea.info.gz     screen.info.gz
bzip2.info.gz            fontname.info.gz             latex2e.info.gz      screen.info-1.gz
coreutils.info.gz        freeipmi-faq.info.gz         latex2e-es.info.gz   screen.info-2.gz
cvs.info.gz              gettext.info.gz              latex2man.info.gz    screen.info-3.gz
cvsclient.info.gz        gnupg.info.gz                libffi.info.gz       screen.info-4.gz
dc.info.gz               gnupg1.info.gz               m4.info.gz           screen.info-5.gz
diffutils.info.gz        gnupg-card-architecture.png  m4.info-1.gz         screen.info-6.gz
dir                      gnupg.info-1.gz              m4.info-2.gz         sed.info.gz
dir.old                  gnupg.info-2.gz              maplev.gz            stow.info.gz
dvipng.info.gz           grep.info.gz                 menu.info.gz         tds.info.gz
dvips.info.gz            groff.info.gz                mf2pt1.info.gz       texdraw.info.gz
ed.info.gz               groff.info-1.gz              nano.info.gz         time.info.gz
emacs-23/                groff.info-2.gz              recode.info.gz       tlbuild.info.gz
emacs-24/                grub.info.gz                 recode.info-1.gz     web2c.info.gz
emacs-goodies-el.gz      grub-dev.info.gz             recode.info-2.gz     wget.info.gz
eplain.info.gz           gzip.info.gz                 recode.info-3.gz
epspdf.info.gz           help2man.info.gz             recode.info-4.gz
~ % ls -l /usr/share/doc/bison
total 436
-rw-r--r-- 1 root root   1460 Aug  2  2013 AUTHORS
-rw-r--r-- 1 root root  13081 Feb 16  2013 ChangeLog-1998.gz
-rw-r--r-- 1 root root 275117 Aug  2  2013 ChangeLog-2012.gz
-rw-r--r-- 1 root root  32035 Dec  5  2013 NEWS.gz
-rw-r--r-- 1 root root   2289 Aug  2  2013 README
-rw-r--r-- 1 root root   3649 Nov 15  2013 THANKS.gz
-rw-r--r-- 1 root root   6403 Aug  2  2013 TODO.gz
-rw-r--r-- 1 root root   5744 Dec 17  2013 changelog.Debian.gz
-rw-r--r-- 1 root root  83271 Dec  5  2013 changelog.gz
-rw-r--r-- 1 root root   1846 Dec 10  2013 copyright

I don't know why they prefer gzip, bzip2 seems to be much more efficient (and in the case of Bison, xz is not, with default settings).

Yet, I am really surprised by your figures (the number of packages that do depend on Bison explicitly to build), so my point is moot. I can live with the documentation not being installed by default (in which case it should be the same for the examples: they also belong to +doc).

Cheers!

[RJVB (René Bertin)]

Replying to akim.demaille@…:

We're taking about an info file here, which is 537KB uncompressed, and 147KB when gzipped, and 112KB with bzip2, all of which are properly read by the info reader.

I know, which is why I didn't insist. But you'll agree with me that if one is to have a policy on this kind of question, you should start with applying it regardless of the size ;)

Why do we install man pages compressed, but no info files? And why keep all the ChangeLog etc. uncompressed too? (Heck, I'd rather see those 355KB of ChangeLog not be installed at all, and have the documentation! The priorities are really wrong here IMHO).

Good point on the info files (I'd add: who uses info files these days? The times I venture there they were strict but less readable copies of the manpages.)

Note though that HFS+ can handle compression, and there is already a patch to portimage.tcl that causes the install (activation) of a port to be done using hfs compression. AFAIK that uses zip compression, which can already give appreciable gains.

As to installing the ChangeLog et al.: that doesn't appear to be standard with MacPorts. I was under the impression that you added them to comply with FOSS guidelines and how things are done on Linux. Maybe the official port maintainer had the same impression, maybe it's he who decided to do this.

Yet, I am really surprised by your figures (the number of packages that do depend on Bison explicitly to build), so my point is moot.

If I'd had to guess, I'd say that this may be due to the fact that a considerable number of FOSS packages have to invoke autogen etc. before they can be built. That may make it necessary to parse the bison/yacc source files, or maybe they just have to be regenerated for OS X for other reasons. The only project where I've had to deal with bison explicitly, xxdiff, ships only the yacc sources and than invokes bison through qmake or through the qmake generated Makefile. (Reminds me I should check if it is still incompatible with bison 3 ...)

I can live with the documentation not being installed by default (in which case it should be the same for the examples: they also belong to +doc).

I'll leave this up to the official port maintainer to decide, as with the ChangeLog etc. thing.

[akimd (Akim Demaille)]

Replying to rjvbertin@…:

Note though that HFS+ can handle compression, and there is already a patch to portimage.tcl that causes the install (activation) of a port to be done using hfs compression.

I was unaware of the feature.

As to installing the ChangeLog et al.: that doesn't appear to be standard with MacPorts. I was under the impression that you added them to comply with FOSS guidelines and how things are done on Linux. Maybe the official port maintainer had the same impression, maybe it's he who decided to do this.

ChangeLog, imho, is completely useless: it is a compilation of the commit messages, so it's really for people who want to contribute to the sources of Bison. NEWS, on the other hand, is part of the documentation: it tell users about the new features, and possible compatibility issues.

I can live with the documentation not being installed by default (in which case it should be the same for the examples: they also belong to +doc).

I'll leave this up to the official port maintainer to decide, as with the ChangeLog etc. thing.

Sure. Thanks!

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

As to installing the ChangeLog et al.: that doesn't appear to be standard with MacPorts.

It is quite standard. Try searching the ports tree for “README”.

I'll leave this up to the official port maintainer to decide, as with the ChangeLog etc. thing.

I will not be splitting the documentation out into a variant.

[RJVB (René Bertin)]

BTW, the portfile claims that mww is the maintainer, is that no longer the case?

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

BTW, the portfile claims that mww is the maintainer, is that no longer the case?

This ticket is well past the ​maintainer timeout period.

[mkae (Marko Käning)]

Cc Me!

[larryv (Lawrence Velázquez)]

I don’t think it’s necessary or desirable to keep Bison 2 around. The fewer versioned ports we have, the better.

I’ve been testing the ports that mention “bison” somewhere in their portfiles. Currently, the following 79 ports declare a dependency on bison and build fine with Bison 3.0.4 installed. (I didn’t verify that the builds actually used Bison.)

• acpica
• aegis
• aide
• argus
• argus-clients
• bash
• boxes
• bro
• chuck
• cproto
• cvs-fast-export
• cxref
• doxygen
• elftoolchain
• fhist
• flasm
• gnubg
• gnupg2
• gnupg21
• gpg-agent
• gringo
• grok
• gr1c
• gstreamer010 (fixed by r133796)
• gstreamer1
• ispc
• iverilog
• jags
• jq
• kdelibs4
• kde4-runtime
• libidl
• lilypond
• lilypond-devel
• LyX
• Maude
• mdbtools
• mdk
• mesa
• monit
• mp3cue
• nco
• nonpareil
• octave
• omnicompiler
• openmotif
• openscad
• pcc
• postgresql80
• postgresql81
• postgresql82
• postgresql83
• postgresql84
• postgresql90
• postgresql91
• postgresql92
• postgresql93
• postgresql94
• p5.20-config-autoconf
• qgis
• qore
• qore-devel
• qucs
• ragel
• roll
• sc
• shakespeare
• spim
• swig
• webkit-gtk
• webkit-gtk-devel
• webkit-gtk-2.0 (fixed by r133867)
• webkit-gtk3
• webkit-gtk3-devel
• webkit-gtk3-2.0 (fixed by r133867)
• wine
• wine-crossover
• wine-devel
• xmms

These 5 6 5 fail with Bison-related errors.

• libgnomeprint (update: fixed by r133896)
• nwntools (update: #47184, fixed by r134346)
• openvas-libnasl (update: #47164, fixed by r133989 and r133990)
• rb-ripper
• xpkg (update: fixed by r134203)
• xxdiff (update: fixed by r133941)

These 11 10 11 fail with errors that don’t seem related to Bison. I haven’t poked around too much, though.

• asterisk (buildslave failures: ​Lion, ​Mountain Lion, ​Mavericks, ​Yosemite)
• cableswig (update: fixed by r136207:136208)
• dwarf (#40408)
• jnethack (patching fails, #47203)
• InsightToolkit
• InsightToolkit312 (presumed to fail based on InsightToolkit test)
• InsightToolkit314 (presumed to fail based on InsightToolkit test)
• lparse (update: fixed by r134117:134122 and r134129)
• nefu (#47205)
• rb-ripper (actually broken in ​a ​great ​number ​of ​ways)
• stp (update: mostly fixed by r134149)
• xxdiff (outdated)

I can’t test this one because I don’t have a PowerPC machine available.

• postgresql7

An 82% success rate seems good enough to me.

[RJVB (René Bertin)]

I don't think users of the remaining 18% will think the same. I'm one of them, being a very regular user of xxdiff. If MacPorts had a feature to "hold" specific ports or if bison were a huge port things would be different, but as it is I don't think that the benefits of removing the bison-2 subport outweigh the disadvantages for some.

[akimd (Akim Demaille)]

Replying to larryv@…:

I don’t think it’s necessary or desirable to keep Bison 2 around. The fewer versioned ports we have, the better.

I share this opinion.

I’ve been testing the ports that mention “bison” somewhere in their portfiles. Currently, the following 79 ports declare a dependency on bison and build fine with Bison 3.0.4 installed. (I didn’t verify that the builds actually used Bison.)

You did an amazing job! Congrats!

These 5 fail with Bison-related errors.

• libgnomeprint
• nwntools
• openvas-libnasl
• rb-ripper
• xpkg

I'll try to have a look at these to fix their errors. Do you think the the patches will have chances of being accepted?

These 11 fail with errors that don’t seem related to Bison. I haven’t poked around too much, though.

• asterisk
• cableswig
• dwarf
• jnethack
• InsightToolkit
• InsightToolkit312 (presumed to fail based on InsightToolkit test)
• InsightToolkit314 (presumed to fail based on InsightToolkit test)
• lparse
• nefu
• stp
• xxdiff (outdated)

[akimd (Akim Demaille)]

Replying to rjvbertin@…:

I don't think users of the remaining 18% will think the same. I'm one of them, being a very regular user of xxdiff. If MacPorts had a feature to "hold" specific ports or if bison were a huge port things would be different, but as it is I don't think that the benefits of removing the bison-2 subport outweigh the disadvantages for some.

But leaving installed an old version promotes old and deprecated interfaces. How about updating these packages instead?

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

I don't think users of the remaining 18% will think the same. I'm one of them, being a very regular user of xxdiff. If MacPorts had a feature to "hold" specific ports or if bison were a huge port things would be different, but as it is I don't think that the benefits of removing the bison-2 subport outweigh the disadvantages for some.

I will not be committing a Bison 2 port, so the Bison 3 update will just have to wait until I fix the broken dependencies. I’ll update my earlier comment as I make progress.

[akimd (Akim Demaille)]

Hi Larry,

Could you please also attach the complete Portfile (not just the diff, it does not apply cleanly on my machine) so that I may give a hand?

[larryv (Lawrence Velázquez)]

portfile for 3.0.4

[larryv (Lawrence Velázquez)]

Sure, here’s my portfile​. I’d appreciate it if you could look at nwntools in particular.

[akimd (Akim Demaille)]

Replying to larryv@…:

Sure, here’s my portfile​.

Thanks! It depends on a skip-runtime.patch file though.

I’d appreciate it if you could look at nwntools in particular.

Wow, this stuff is incredibly old... I have tons of warnings I had not seen in years (e.g., storing constant string in char* without const). Is it still used?

It had very advanced uses of Bison. Actually, it was using things I would consider today as internals.

I have attached a patch, but could not finish the compilation for other reasons, not related to Bison. If the package is still alive, it should probably be forwarded, other distros must face the same issues I guess.

[akimd (Akim Demaille)]

A patch to update to using Bison 3

[larryv (Lawrence Velázquez)]

Replying to akim.demaille@…:

Thanks! It depends on a skip-runtime.patch file though.

Oops, here it is​.

Wow, this stuff is incredibly old... I have tons of warnings I had not seen in years (e.g., storing constant string in char* without const). Is it still used?

No idea, to be honest.

I have attached a patch, but could not finish the compilation for other reasons, not related to Bison. If the package is still alive, it should probably be forwarded, other distros must face the same issues I guess.

I adapted your patch manually, combining it with the already existing patches, and it builds successfully. I’ve opened #47184 for it.

[larryv (Lawrence Velázquez)]

Alright, nwntools is the last straggler that’s definitely broken by Bison 3 — and I suspect #47184 will ​time out by this weekend — so…

r134195:134201

Sorry it took so long to get this done. I think we were all just afraid of another #39923.

[larryv (Lawrence Velázquez)]

I think I’ll take a nap now.

[akimd (Akim Demaille)]

Replying to larryv@…:

I think I’ll take a nap now.

Well deserved!