cal at macports.org
Sun Feb 24 16:05:31 PST 2013
On Sun, Feb 24, 2013 at 05:37:26PM -0500, Lawrence Velázquez wrote:
> The way things are now, all options are ordered and allow duplicates.
> This behavior is admittedly not semantically natural for all options
> (dependencies, most notably), but it's clear how they work, and it
> generally doesn't cause problems, as far as I can tell.
The problem with allowing duplicates and invalid values is comes back to
bite you in the wrong place as soon as you start putting data into a
format where that matters.
Just an example: If I want to store dependencies in SQL as a list (i.e.,
a proper separate table with a foreign key) and don't want to declare an
artificial primary key I need to use the combination
as primary key.
Now as you can see, having duplicate values in dependencies causes SQL
errors when trying to put the second dependency into the database. Ugh.
My point is: Options never have been semantically neutral. They have
always been interpreted in a certain way by base, but we didn't care and
did allow Portfile writers to do whatever they wanted with the options.
This leads to excessive delete and add operations if you want to make
sure dependencies dont't contain any duplicates.
We even have more options that shouldn't be handled like lists, as they
currently are. Have you ever used use_autoconf-replace? Or
use_autoconf-append? Did you ever set use_autoconf to 567? Should that
be supported? If base knew those were boolean options it could
automatically sanitize these values.
> In your branch, some options are ordered, others aren't. Some options
> retain duplicates, others eliminate them. A portfile author can never
> really be sure what the situation is, unless they're willing to peek
> into base or check the Guide whenever they use an option.
A Portfile author shouldn't even care whether a specific options allows
duplicates or not, because it automatically does the right thing for
him. There's no point in specifying dependencies twice, so why allow it?
Similarly, there's no point in setting
use_autoconf [list 4567 789]
so why would base accept that?
But I agree, this should be documented.
search for depends_lib-delete
More information about the macports-dev