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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
