automake/autoconf

[Rainer Müller]

On 2015-01-18 12:22, jerryyhom at gmail.com wrote:
> Okay, thanks Ryan and Josh for clarifying.  I was confused by two
> separate issues which led me to a wrong conclusion.  I can use
> autoreconf though it seems like overkill in this situation.

autoreconf is just running a few more tools such as autoheader, aclocal,
etc. Unless you specify --force, only modified files should cause the
tools to run at all (neglecting the overhead for the check).

> As for the bug, I was about to ask, as an enhancement request, if the
> logic which expands use_auto{tools} could also determine a unified set
> of dependencies.  Is this reasonable?

I fixed the immediate bug in r131824 [1].

In general, handling this option as a set with unique entries instead of
a list would make sense. With semantics for a set instead of a list
adding the same depspec multiple times would not cause any problems.
Currently all options are treated as lists.

We had a similar discussion before. Clemens also implemented something
on his branch quite a while ago:
https://lists.macosforge.org/pipermail/macports-dev/2013-October/024615.html

However, I would be very conservative to change this behavior without
increasing the PortSystem version as it is very likely to break existing
Portfiles. Also, as a Portfile author you would then need to know
whether this option is treated as a set or a list.

Another possibility would be to give the -append procs an argument that
makes it not add entries if they already exist, for example:

   depends_lib-append -unique port:foo

Rainer

[1] http://trac.macports.org/changeset/131824