[42296] trunk/dports/databases/db46/Portfile
Ryan Schmidt
ryandesign at macports.org
Wed Nov 19 19:48:56 PST 2008
On Nov 19, 2008, at 16:19, Trannie Carter wrote:
>> One question and a little suggestion:
>> Why a variant for this small utility?
>
> You mean as opposed to making it part of the default build? I
> agree that it is
> a relatively small utility to get its own variant. The db44 port
> enabled
> db_dump185 by default and mentioned it in the port description. db46
> explicitly dropped that and I assumed there was a reason; Probably
> because not
> many people use db1.8 anymore :) But I found an old bdb file I
> needed access
> to, so I added a variant.
>
> I'll start posting to macports-dev when there's ambiguity. I'm
> still pretty
> new to ports best practices.
A variant should only be added if there is a really good reason why
someone would want to not use it. :) For example, a good reason would
be if the variant adds dependencies which are large or take a long
time to build, or when there are conflicting options to choose from.
Like php5 has mysql3, mysql4 and mysql5 variants; you must pick one
of these if you want MySQL support, but you have to choose the one
that matches your MySQL version. Also, e.g. mysql5 is a large
download (27MiB), takes a lot of space after install (41MiB) and
takes a long time to build (I forget how long at the moment).
You could ask whoever committed the removal of that program from db46
initially why they did so.
>> Instead of testing whether the variant is set, you could write
>> another
>> post-destroot block in the variant itself.
>
> Oh, I'm not familiar with that pattern. I modeled that section
> after the
> MacPorts Guide section 4.4.2 Variant Actions in a Phase. Maybe
> this new style
> is described in the trunk version of the guide.
The guide says [1]:
> If a variant requires options in addition to those provided by
> keywords using -append and/or -delete, in other words, any actions
> that would normally take place within a port installation phase, do
> not try to do this within the variant declaration. Rather, modify
> the behavior of any affected phases when the variant is invoked
> using the variant_isset keyword.
>
> post-destroot {
> xinstall -m 755 -d ${destroot}${prefix}/etc/
> xinstall ${worksrcpath}/examples/foo.conf \
> ${destroot}${prefix}/etc/
>
> if {[variant_isset carbon]} {
> delete ${destroot}${prefix}/bin/emacs
> delete ${destroot}${prefix}/bin/emacs-${version}
> }
> }
I have no idea why it says that. :) There's no reason I can think of
not to do it within the variant declaration; in fact, I think it's
preferable to keep all of the variant's dealings together in one
place (the variant declaration).
[1] http://guide.macports.org/#development.variants.phase
More information about the macports-dev
mailing list