incremental ports/INDEX builder

Mark Linimon linimon at lonesome.com
Tue Jun 22 11:28:40 PDT 2004


> Besides, you have to feed the list of updated files to some script
> to update the depedency database, which won't work with a pure
> `make -V' solution.

I don't use the dependency information in portsmon.

> The database has more information, like that 149 ports depend on
> x11/kde3/Makefile.kde, but if you don't want to know then simply
> don't ask.

You don't understand the question that I need to ask.  The question I need
to ask is "for newly modified port Makefile X, show me the list of ports
that its modification might affect".  Therefore I need a mapping, and for
performance reasons it needs to be the most minimal mapping possible.
Your solution adds 149 ports to the map that (by inspection) I can assert
that I don't need in the map.

In fact, the Makefile-based solution (plus patching 40 degenerate ports)
will save me from having at least 250 ports in that map that your solution
would add.  (I know this because I have, myself, viewed these ports'
Makefiles).  In each of these cases there is a .include of some kind of
common logic which doesn't affect the "interesting" variables.

So, there is no meaning to "don't ask".  I run a make -V when a ports'
Makefile changes in CVS.  (Well, actually, I run a special make target
when M* changes, but no matter).

> Tell me some names, and I will tell you what my script delivers. You
> still owe me a sample where my script is wrong.

You have asked this many times.  I have given you the explanation that
your script provides a strict superset of what I want.  It is not "wrong",
it is "too much".  I am sorry that you will not accept my explanation that
it is due to performance reasons that I wish to have the minimal set.

I also do not understand enough about your script to assess its performance
impact, nor am I likely to without many hours of refactoring out only what
I need and testing and retesting (and probably learning Perl in the
process).  I simply don't have that kind of time at the moment, as
evidenced by an overflowing freebsd.todo mbox, which is mostly full of
things I've already told someone else I will do.

mcl


More information about the freebsd-ports mailing list