Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#41600 closed update (fixed)

bison: update to 3.0.2

Reported by: akimd (Akim Demaille) Owned by: larryv (Lawrence Velázquez)
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: cooljeanius (Eric Gallager), RJVB (René Bertin), evandrix (Lee Wei Yeong), etienne.renault@…, mww@…, mkae (Marko Käning)
Port: bison

Description

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+)*)
-

Attachments (5)

bison.diff (2.8 KB) - added by akimd (Akim Demaille) 10 years ago.
2.7.1 to 3.0.2
bison-3.0.4.diff (4.1 KB) - added by RJVB (René Bertin) 9 years ago.
2.7.1 -> 3.0.4 with a bison-2 subport
Portfile (3.2 KB) - added by larryv (Lawrence Velázquez) 9 years ago.
portfile for 3.0.4
nwntools.2.3.2-bison-3.patch (34.5 KB) - added by akimd (Akim Demaille) 9 years ago.
A patch to update to using Bison 3
skip-runtime-po.patch (413 bytes) - added by larryv (Lawrence Velázquez) 9 years ago.

Download all attachments as: .zip

Change History (63)

comment:1 Changed 10 years ago by cooljeanius (Eric Gallager)

bison3 has incompatibilities with bison2: see #39910

comment:2 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Keywords: haspatch added
Owner: changed from macports-tickets@… to mww@…

comment:3 Changed 10 years ago by 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.

comment:4 Changed 10 years ago by akimd (Akim Demaille)

Hi,

Bison 3.0.2 is out too.

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.

To avoid cluttering the history of this ticket, this is a rewritten version of my previous answer.

--- Portfile.2.7.1	2013-12-09 14:07:38.000000000 +0100
+++ Portfile	2013-12-09 15:16:52.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
@@ -32,24 +33,33 @@
                     --mandir=${prefix}/share/man \
                     --disable-yacc
 
+build.args          examples/calc++/calc++ \
+                    examples/mfcalc/mfcalc \
+                    examples/rpcalc/rpcalc
+
 test.run            yes
 test.target         check
 
 post-destroot {
     set docdir ${prefix}/share/doc/${name}
-    xinstall -d ${destroot}${docdir}/examples/calc++
+    xinstall -d ${destroot}${docdir}
     xinstall -m 0444 -W ${worksrcpath} AUTHORS COPYING ChangeLog NEWS \
         THANKS TODO ${destroot}${docdir}
+    xinstall -d ${destroot}${docdir}/examples/calc++
     xinstall -m 444 -W ${worksrcpath}/examples/calc++  \
         calc++-driver.cc calc++-driver.hh calc++-parser.cc \
-        calc++-parser.hh calc++-parser.stamp calc++-parser.yy \
+        calc++-parser.hh calc++-parser.yy \
         calc++-scanner.cc calc++-scanner.ll calc++.cc location.hh \
-        position.hh stack.hh test \
+        position.hh stack.hh \
         ${destroot}${docdir}/examples/calc++
-    # yacc manpage gets installed even with '--disable-yacc'
-    if {! [variant_isset yacc]} {
-        delete ${destroot}${prefix}/share/man/man1/yacc.1
-    }
+    xinstall -d ${destroot}${docdir}/examples/mfcalc
+    xinstall -m 444 -W ${worksrcpath}/examples/mfcalc  \
+        calc.h mfcalc.c mfcalc.h mfcalc.y \
+        ${destroot}${docdir}/examples/mfcalc
+    xinstall -d ${destroot}${docdir}/examples/rpcalc
+    xinstall -m 444 -W ${worksrcpath}/examples/rpcalc  \
+        rpcalc.c rpcalc.h rpcalc.y \
+        ${destroot}${docdir}/examples/rpcalc
 }
 
 variant yacc description "enable yacc compatibility" {
@@ -59,4 +69,3 @@
 livecheck.type      regex
 livecheck.url       http://ftp.gnu.org/gnu/bison/?C=M&O=D
 livecheck.regex     ${name}-(\\d+(?:\\.\\d+)*)
-
Last edited 10 years ago by akimd (Akim Demaille) (previous) (diff)

comment:5 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:7 Changed 10 years ago by mf2k (Frank Schima)

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

Changed 10 years ago by akimd (Akim Demaille)

Attachment: bison.diff added

2.7.1 to 3.0.2

comment:8 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Summary: bison 3.0.1 is outbison: update to 3.0.2

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

comment:9 Changed 10 years ago by 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.

comment:10 Changed 10 years ago by akimd (Akim Demaille)

Ping!

comment:11 Changed 10 years ago by c9s (Yo-An Lin)

Ping!

comment:12 Changed 10 years ago by RJVB (René Bertin)

Cc: rjvbertin@… added

Cc Me!

comment:13 Changed 10 years ago by akimd (Akim Demaille)

Ping again. Can we please get rid of 2.7?

comment:14 Changed 10 years ago by 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.

comment:15 Changed 10 years ago by 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.

comment:16 in reply to:  15 Changed 10 years ago by 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.

comment:17 Changed 9 years ago by akimd (Akim Demaille)

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

comment:18 Changed 9 years ago by evandrix (Lee Wei Yeong)

Cc: evandrix@… added

Cc Me!

comment:19 Changed 9 years ago by etienne.renault@…

Cc: etienne.renault@… added

Cc Me!

comment:20 Changed 9 years ago by akimd (Akim Demaille)

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

comment:21 in reply to:  20 ; Changed 9 years ago by 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.

comment:22 in reply to:  21 Changed 9 years ago by 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!

comment:23 in reply to:  21 Changed 9 years ago by larryv (Lawrence Velázquez)

Cc: mww@… added
Owner: changed from mww@… to larryv@…
Status: newassigned
Version: 2.2.1

Replying to rjvbertin@…:

Apply the diff

Please attach a unified diff.

comment:24 in reply to:  4 ; Changed 9 years ago by 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.

comment:25 Changed 9 years ago by 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?

comment:26 Changed 9 years ago by 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.

comment:27 Changed 9 years ago by 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.)

comment:28 in reply to:  24 ; Changed 9 years ago by 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.

Last edited 9 years ago by akimd (Akim Demaille) (previous) (diff)

comment:29 in reply to:  25 Changed 9 years ago by 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.

comment:30 in reply to:  26 Changed 9 years ago by 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.

comment:31 in reply to:  27 Changed 9 years ago by 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.

comment:32 Changed 9 years ago by 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.

comment:33 Changed 9 years ago by 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

comment:34 in reply to:  27 Changed 9 years ago by larryv (Lawrence Velázquez)

Replying to rjvbertin@…:

Who is *you* here?

Akim, who is one of the upstream maintainers.

comment:35 Changed 9 years ago by RJVB (René Bertin)

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

comment:36 in reply to:  28 Changed 9 years ago by 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.

comment:37 in reply to:  32 Changed 9 years ago by 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.).

comment:38 Changed 9 years ago by 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).

Changed 9 years ago by RJVB (René Bertin)

Attachment: bison-3.0.4.diff added

2.7.1 -> 3.0.4 with a bison-2 subport

comment:39 in reply to:  33 Changed 9 years ago by akimd (Akim Demaille)

Hi!

Replying to rjvbertin@…:

Does this look complete (from 3.0.4)?

It looks perfect, thanks!

comment:40 in reply to:  38 ; Changed 9 years ago by 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!

comment:41 in reply to:  40 ; Changed 9 years ago by 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.

comment:42 in reply to:  41 Changed 9 years ago by 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!

comment:43 in reply to:  41 Changed 9 years ago by 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.

comment:44 Changed 9 years ago by RJVB (René Bertin)

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

comment:45 in reply to:  44 Changed 9 years ago by 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.

comment:46 Changed 9 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

comment:47 Changed 9 years ago by 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.

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

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.

Last edited 9 years ago by larryv (Lawrence Velázquez) (previous) (diff)

comment:48 Changed 9 years ago by 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.

comment:49 in reply to:  47 Changed 9 years ago by 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)

comment:50 in reply to:  48 Changed 9 years ago by 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?

comment:51 in reply to:  48 Changed 9 years ago by 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.

comment:52 Changed 9 years ago by 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?

Changed 9 years ago by larryv (Lawrence Velázquez)

Attachment: Portfile added

portfile for 3.0.4

comment:53 in reply to:  52 ; Changed 9 years ago by larryv (Lawrence Velázquez)

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

comment:54 in reply to:  53 ; Changed 9 years ago by 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.

Changed 9 years ago by akimd (Akim Demaille)

A patch to update to using Bison 3

Changed 9 years ago by larryv (Lawrence Velázquez)

Attachment: skip-runtime-po.patch added

comment:55 in reply to:  54 Changed 9 years ago by 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.

comment:56 Changed 9 years ago by larryv (Lawrence Velázquez)

Resolution: fixed
Status: assignedclosed

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.

comment:57 Changed 9 years ago by larryv (Lawrence Velázquez)

I think I’ll take a nap now.

comment:58 in reply to:  57 Changed 9 years ago by akimd (Akim Demaille)

Replying to larryv@…:

I think I’ll take a nap now.

Well deserved!

Note: See TracTickets for help on using tickets.