#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)
Change History (63)
comment:1 Changed 11 years ago by cooljeanius (Eric Gallager)
comment:2 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | haspatch added |
---|---|
Owner: | changed from macports-tickets@… to mww@… |
comment:3 Changed 11 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 follow-up: 24 Changed 11 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+)*) -
comment:5 Changed 11 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:7 Changed 11 years ago by mf2k (Frank Schima)
Please instead attach your .diff file(s) instead of pasting them inline.
comment:8 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Summary: | bison 3.0.1 is out → bison: 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 11 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: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 follow-up: 16 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 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 10 years ago by akimd (Akim Demaille)
Ping again. This ticket is one year old. What can we do to have this go forward?
comment:20 follow-up: 21 Changed 10 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 follow-ups: 22 23 Changed 10 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 Changed 10 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 Changed 10 years ago by larryv (Lawrence Velázquez)
Cc: | mww@… added |
---|---|
Owner: | changed from mww@… to larryv@… |
Status: | new → assigned |
Version: | 2.2.1 |
comment:24 follow-up: 28 Changed 10 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 follow-up: 29 Changed 10 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 follow-up: 30 Changed 10 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 follow-ups: 31 34 Changed 10 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 follow-up: 36 Changed 10 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.
comment:29 Changed 10 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 theyacc
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 Changed 10 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 Changed 10 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 follow-up: 37 Changed 10 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 follow-up: 39 Changed 10 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 Changed 10 years ago by larryv (Lawrence Velázquez)
comment:35 Changed 10 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 Changed 10 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 Changed 10 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 follow-up: 40 Changed 10 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 10 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 Changed 10 years ago by akimd (Akim Demaille)
comment:40 follow-up: 41 Changed 10 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 follow-ups: 42 43 Changed 10 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 Changed 10 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 Changed 10 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 follow-up: 45 Changed 10 years ago by RJVB (René Bertin)
BTW, the portfile claims that mww is the maintainer, is that no longer the case?
comment:45 Changed 10 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:47 follow-up: 49 Changed 10 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.
- 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.
comment:48 follow-ups: 50 51 Changed 10 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 Changed 10 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 Changed 10 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 Changed 10 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 follow-up: 53 Changed 10 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?
comment:53 follow-up: 54 Changed 10 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 follow-up: 55 Changed 10 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 10 years ago by akimd (Akim Demaille)
Attachment: | nwntools.2.3.2-bison-3.patch added |
---|
A patch to update to using Bison 3
Changed 10 years ago by larryv (Lawrence Velázquez)
Attachment: | skip-runtime-po.patch added |
---|
comment:55 Changed 10 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 10 years ago by larryv (Lawrence Velázquez)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:57 follow-up: 58 Changed 10 years ago by larryv (Lawrence Velázquez)
I think I’ll take a nap now.
bison3 has incompatibilities with bison2: see #39910