yacc/bison

[Ryan Schmidt]

On Apr 7, 2009, at 09:59, Jeremy Lavergne wrote:

> I have a port that is using yacc.  Like g++/gcc, it can use the  
> system ones without a problem.  Should this not be marked as a  
> dependency then?

I suggest declaring a dependency on the bison port. I do this in my  
pure/pure-devel ports which need bison. This way, you won't be  
confused later when differences arise between the system bison and  
the MacPorts bison; you can be assured all users are using the  
MacPorts bison.

> If not, what ports provide bin/yacc besides bison +yacc?  It is my  
> understanding we can't dictate variants yet, so I'd like a better  
> solution than printing a ui_msg.

True. But:

The +yacc variant doesn't make bison take longer to build [1]. It  
doesn't add any dependencies. All it does is install a static library  
liby.a and install a wrapper script "yacc" which calls "bison -y".

The +yacc variant was added to the bison port in r10216 when it was  
updated to version 2.0. No explanation why it was a variant instead  
of always on.

This sounds like a great example of where we should remove the  
variant and have bison always include yacc support.



[1]

$ time port install bison +yacc
--->  Fetching bison
--->  Verifying checksum(s) for bison
--->  Extracting bison
--->  Configuring bison
--->  Building bison
--->  Staging bison into destroot
--->  Installing bison @2.4.1_0+yacc
--->  Activating bison @2.4.1_0+yacc
--->  Cleaning bison

real    0m46.056s
user    0m24.097s
sys     0m16.667s
$ port deactivate bison
--->  Deactivating bison
$ time port install bison
--->  Fetching bison
--->  Verifying checksum(s) for bison
--->  Extracting bison
--->  Configuring bison
--->  Building bison
--->  Staging bison into destroot
--->  Installing bison @2.4.1_0
--->  Activating bison @2.4.1_0
--->  Cleaning bison

real    0m44.871s
user    0m24.013s
sys     0m16.512s
$