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