I am writing a Portfile and i would appreciate help

[Randall Wood]

On 11 Feb 2007, at 05:47, Andrea Cimino wrote:

> I am writing a Portfile for the "Parma Polyhedra Library" project  
> (http://www.cs.unipr.it/ppl)
> but i have some questions for you, developers.
>
> You can find a first snapshot of the Portfile here:
> http://www.cs.unipr.it/cgi-bin/viewvc/viewvc.cgi/ppl/ 
> DarwinPorts_Portfile?revision=1.1.2.1&view=markup&pathrev=ppl-0_9- 
> branch
>
> This is my first Portfile so i don't expect that meets the MacPorts  
> standards, here the questions:
>
> 1) Is really needed to have a ppl-dev package, with headers and so  
> on? Or we can just provide a 'ppl' package with everything  
> installed there?

No ppl-dev package is created. The whole thing, headers and all, goes  
in one package. MacPorts uses *-devel packages to note that the *- 
devel version is the non-stable version of a port.

Run the "port search swi-prolog" and "port search yap" commands and  
you will see what I mean.

You may wish to depend on swi-prolog and yap instead of on swi-prolog- 
devel and yap-devel.

> 2) The 'ppl' provides several Prolog interfaces so i decided to  
> write some variants: is this the right way to help MacPorts users  
> installing the 'ppl' and building the interfaces?

Yes, it is. However, your variants should ensure that ppl builds with  
the desired functionality only if the variant is selected using  
configure.args-append statements. You may wish to also name your  
variants enable_*/disable_*/with_*/without_* (so you have +with_yap  
instead of just +yap). Use the syntax most similar to the syntax used  
by the ppl build system (if it uses --include-something then the  
variant would be +include_something).

> 3) The 'ppl', depending on the presence of the 'glpk' library,  
> builds the optional tool 'ppl_lpsol'. The glpk dependency should be  
> declared in a variant or in the main section of the Portfile?

I would do this as a variant as well.

> Other suggestions obviously are welcome!

You may wish to make sure that for each variant you have, you have a  
conflicting variant that removes that variants functionality: for  
example:

default_variants +with_yap

variant with_yap conflicts without_yap { ... }

variant without_yap conflicts with_yap { ... }

This way if a user decides not to use the +without_yap variant, it  
will prevent the +with_yap variant from being used.

> Best regards,
> Andrea Cimino
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev


Randall Wood
rhwood at mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."