[50222] trunk/dports/graphics

[Ryan Schmidt]

On Apr 27, 2009, at 19:48, Darren Weber wrote:

> On Mon, Apr 27, 2009 at 5:01 PM, Ryan Schmidt wrote:
>
>> Since this port uses cmake, have you considered using the cmake  
>> portgroup
>> to simplify it?
>
> No, I didn't know such a portgroup exists and I have no idea how to  
> use a
> portgroup.

Portgroups are basically include statements, allowing you include a  
set of definitions that are common to a class of ports. There is a  
section on portgroups in the guide. Unfortunately it does not have  
any general explanation of what a portgroup is. It just describes the  
options available in some of the existing portgroups.

http://guide.macports.org/#reference.portgroup

The cmake portgroup is new and not yet documented in the guide, but  
you can read its source code here to see what it does:

http://trac.macports.org/browser/trunk/dports/_resources/port1.0/ 
group/cmake-1.0.tcl

Basically, all ports that use cmake need to do certain similar  
things, for example depend on the cmake port, use cmake in the  
configure phase, specify the prefix using -DCMAKE_INSTALL_PREFIX  
instead of --prefix, etc.; the cmake portgroup exists to simplify  
such ports.


>>> +configure {
>>> +    system "cd ${workbuildpath} && ${configure.env} && cmake
>>> ${configure.args} ${worksrcpath}"
>>> +}
>>>
>>
>> configure.env is not a command; running it by itself doesn't have any
>> effect, as far as I know. If you want those environment variables  
>> to have
>> effect for the cmake command, you would not separate configure.env  
>> from the
>> cmake command with "&&".
>
> configure.env settings will be dropped, completely (see your  
> comment below
> also).

That's what it looked like to me. And I assume that's not what you  
want. Anyway, using the cmake portgroup will take care of this for  
you automatically.


>>> +build {
>>> +    system "cd ${workbuildpath} && gmake"
>>> +}
>>> +destroot {
>>> +    system "cd ${workbuildpath} && gmake install DESTDIR=$ 
>>> {destroot}"
>>> +}
>>
>> Why override all these phases? Using the cmake portgroup will take  
>> care of
>> the configure phase for you, and the build and destroot phases are  
>> better
>> implemented by just setting the relevant .cmd.
>>
>> build.cmd gmake
>> destroot.cmd gmake
>>
>> Actually you can omit "destroot.cmd gmake" since the default for
>> destroot.cmd is the value of build.cmd.
>
> It's possibly pedantic to be explicit about using gmake, but there  
> it is.
> The option to set build.cmd occurred to me.


Actually, an even better way than specifying build.cmd is to use  
build.type. MacPorts knows about bsdmake (which it uses by default)  
and gnumake (a.k.a. gmake) which you can request by using:

build.type gnu

http://guide.macports.org/#reference.phases.build


> However, the default build
> location is ${worksrcpath} and I want to use an out-of-source build  
> path,
> hence the specification to "cd ${workbuildpath}".  The reason is  
> that I hope
> to be able to install both static and dynamic libraries from this  
> vtk port
> and it might be wise to build out of source into several different  
> build
> paths.  The current incarnation uses only a dynamic build by  
> default.  It
> should be possible to add a +static variant that doesn't conflict  
> with the
> dynamic build.  I expect this will be built into $ 
> {workstaticbuildpath}.
>
> I don't see any variable settings for doing out-of-source builds in
> macports.  So, the overrides may stand as is.

The existing variable to do that is called build.dir. You should use  
that instead of your own invention of workbuildpath.


>>> +default_variants \
>>> +    +cocoa \
>>> +    +data \
>>> +    +examples \
>>> +    +shared
>>> +
>>> +variant data description {Install the example data [default]} {
>>> +}
>>> +
>>> +
>>> +variant doc description {Build the doxygen documentation} {
>>> +    depends_build-append \
>>> +        port:doxygen
>>> +    configure.args-append \
>>> +        -DBUILD_DOCUMENTATION:BOOL=ON
>>> +}
>>> +
>>> +
>>> +variant examples description {Build and install VTK examples  
>>> [default]} {
>>> +    configure.args-delete \
>>> +        -DBUILD_EXAMPLES:BOOL=OFF
>>> +    configure.args-append \
>>> +        -DBUILD_EXAMPLES:BOOL=ON
>>> +}
>>>
>>
>> Having fewer variants is better, and since you already make +data and
>> +examples default variants, why not just incorporate them into the  
>> port
>> proper and remove the variants?
>
> Simple -- choice.  Anyone can select -data or -examples, but only  
> if they
> are variants.

And only if they remember to do so every time they want to upgrade or  
reinstall the port.

sudo port upgrade vtk-devel -data -examples

If they do not, your default variants will cause those variants to be  
re-added.

So a user will have to go to some effort to remove the data and the  
examples. Is there any reason anyone would want to do so? They don't  
add dependencies. How much additional disk space do they require? How  
much additional time to they take to build? If the additional build  
time and disk space are small, enable them by default. If they take  
awhile or are large, consider separate ports as you pointed out some  
other distributions do.

More choice is not necessarily better. Giving the user a choice means  
they have to choose, which takes time, effort and knowledge.


>> I would also prefer that the port have no default variants. If  
>> something
>> should be in the port by default, make it so; if necessary, offer  
>> variants
>> to turn the feature off again, e.g. a "no_shared" or a "no_data"  
>> variant.
>> However think carefully about whether anyone really needs to turn  
>> that
>> feature off. If not, don't give the option.
>
> Probably a difference of opinion or just a matter of style.  Using  
> default
> variants allows other ports to get "essential" features without  
> having to
> depend on any variant.  Users can switch it off with -<variant> and  
> I prefer
> to stick with +<variant> or -<variant> rather than introduce double
> negatives like +<no_variant>.  Furthermore, the variant syntax  
> provides
> additional benefits, like description information to 'port variants
> <portname>' and the capacity to specify requires and conflicts, with
> additional stage processing options within the variant.

The problem is that MacPorts always selects default variants, so even  
you had deselected them at install time, MacPorts will select them  
again for you at upgrade time. Therefore it is preferred to enable a  
feature in the port by default and offer a no_whatever variant to  
disable it, if there is really a reason to offer that choice. This is  
why ports have no_x11 variants, instead of an x11 variant that is  
specified as a default variant.

>>> +variant carbon conflicts {cocoa x11} description {Build with  
>>> Carbon} {
>>
>> So we have the choice between carbon, cocoa, and x11, and only 1  
>> can be
>> chosen. But you have made cocoa a default variant. You should only  
>> make
>> cocoa the default variant if x11 or carbon have not already been  
>> chosen. See
>> any of several ports for examples of how to handle this, such as  
>> minivmac or
>> pdftk.
>
> I guessed that when the command line specifies +x11, for instance, the
> variant conflict statment would automatically override the default  
> +cocoa
> variant.  So that's not true?

If the default_variants line specifies +cocoa, MacPorts will select  
the +cocoa variant, unless the user types "-cocoa" at the command line.

If the user only types "+x11", then MacPorts will print a message  
stating that +x11 conflicts with +cocoa and will abort. This is not  
user-friendly, therefore you should only specify +cocoa as a default  
variant if the user has not already selected +x11 or +carbon, as  
exemplified in minivmac or pdftk.


>>> +variant mysql description {Build the MySQL driver for  
>>> vtkSQLDatabase} {
>>> +    depends_build-append \
>>> +        port:mysql5
>>
>> Please use path:bin/mysql_config5:mysql5 for any mysql5  
>> dependency, so that
>> mysql5-devel would also be able to satisfy it.
>
> Huh?  Is there a path: syntax to the depends_build option?

It's not specific to depends_build. All depends_* options can use all  
dependency types. The available types are port:, bin:, lib: and path:.

http://guide.macports.org/#reference.dependencies.types

port: syntax only allows exactly the specified port to satisfy the  
dependency. bin: and lib: should not usually be used because a binary  
or library installed as part of Mac OS X would satisfy the  
dependency, and our policy is to require MacPorts versions of things.  
Older ports might still use bin: and lib: because port: syntax was  
added to MacPorts at a later date. There are also certain exceptions,  
like texlive, for which the bin: or lib: style is preferred. path:  
syntax should be used when more than one port exists which provides  
the necessary functionality. In the case of mysql5, a mysql5-devel  
port exists for the next development version of MySQL. To allow users  
using either mysql5 or mysql5-devel to use this variant of your port,  
use a path:-style dependency and list the path (relative to $ 
{prefix}) of a file provided by the port. I generally try to use  
pkgconfig files or _config scripts if they're available, so the  
mysql_config5 script in the case of MySQL. IMHO we should strive to  
always use path:-style dependencies and move away from using port:- 
style dependencies, because you never know when someone will want to  
add a -devel version of a port.


>> It would be easier to understand the port if you put the parts  
>> that are
>> specific to a variant inside that variant declaration.
>>
>> So, instead of what you have:
>>
>>
>> variant examples {
>>    ...
>> }
>> variant testing {
>>    ...
>> }
>> variant shared {
>>    ...
>> }
>> post-destroot {
>>    ...
>>    if {[variant_isset examples]} {
>>        ...
>>    }
>>    if {[variant_isset testing]} {
>>        ...
>>    }
>>    if {[variant_isset shared]} {
>>        ...
>>    }
>> }
>>
>>
>> Do this:
>>
>>
>> variant examples {
>>    ...
>>    post-destroot {
>>        ...
>>    }
>> }
>> variant testing {
>>    ...
>>    post-destroot {
>>        ...
>>    }
>> }
>> variant shared {
>>    ...
>>    post-destroot {
>>        ...
>>    }
>> }
>> post-destroot {
>>    ...
>> }
>
> Difference of opinion.  I find it easier to have it all in the post- 
> destroot
> because the variables for the doc and data path are set right  
> before it and
> most of the work in post-destroot is clearer when you can see those
> variables defined right above it.  If all the post-destroot is  
> split up all
> over the variants, it's harder to see what the post-destroot is doing.

Ok, I see the point regarding the variables. It can be worked around  
if desired by making them global variables.

I suppose you're right, it's a stylistic issue and could go either way.

Note that some older existing ports do it the way you do only because  
that used to be the only way MacPorts would function correctly.  
Phases defined in variants used to not be cumulative; they would  
override each other, and thus not do what you might expect. Now that  
MacPorts knows to run e.g. each of the post-destroot phases  
specified, instead of just one of them, it can be done either way.  
The guide has not yet been updated for this.

http://trac.macports.org/ticket/18359