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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

On 11 Feb 2007, at 06:43, Andrea Cimino wrote:

Randall Wood ha scritto:

...

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.

Thanks, i will fix the Portfile now.

...

...

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).

I understand. The point is that our configure script tries to automatically detect the Prolog systems installed and builds the corresponding interface, but we don't have an option named "-- disable-yap". I thought that having a variant like +yap, could help people to install the ppl configured in the right way. Do you think that is better to let the ppl build depending on the ports installed on the system? E.G. I have the Swi-prolog installed, so the ppl port builds also the Swi-prolog interface...

I would include yap and swi-prolog as dependents in the main portion of the Portfile and remove the variants then.

...

...

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.

We also don't have in this case an option named --disable-glpk. The ppl automatically checks for the Glpk and tries to build the ppl-lpsol tool. With the variant i would have forced to build the ppl_lpsol tool. What do you think we should do?

In cases like this I would put the dependencies in the main section of the portfile. Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

On Feb 11, 2007, at 05:05, Randall Wood wrote:

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.

I still don't understand this suggestion of providing both with_yap and without_yap variants. I haven't seen that in any existing ports, and don't see why you can't just have one of those variants, and not the other. If you have a variant called with_yap, then if you use the variant, you get yap; if you don't use the variant, you don't get yap. On the other hand, if you have a variant without_yap, and you use it, you don't get yap, and if you don't use it, you do get yap. Which variant you provide depends on whether you want yap to be enabled by default or not. I also don't see any need to use the default_variants feature.