Re: Looking for speed increases in "make index" and pkg_version for ports



Not quite what you asked for but...

Given the size and complexity of the port system I have long
felt that rather than do everything via more and more complex
Mk/*.mk what is is needed is a ports server and a thin CLI
frontend to it.

This server can store dependency data in an efficient manner,
deal with conditional dependencies, port renames, security
and what not. It can build or fetch or serve packages,
handle updates etc. Things mentioned in UPDATING file can
instead be done by the server. In general it can automate a
lot of stuff, remove error prone redundancies etc. If it is
small enough and written in C, it can even be shipped with
the base system instead of various pkg_* programs.

It can provide two interfaces, one for normal users (with
commands like add, check, config, delete, info, search,
update, which) and one for port developers (command for
adding/remove/renaming ports, etc.). Initially it must work
with existing Makefiles.

I have been thinking a lot about looking for speed increases for "make
index" and pkg_version and things like that. So for example, in
pkg_version, it calls "make -V PKGNAME" for every installed package.
Now "make -V PKGNAME" should be a speedy operation, but the make has to
load in and analyze bsd.port.mk, a quite complicated file with about
200,000 characters in it, when all it is needing to do is to figure out
the value of the variable PKGNAME.

I suggest rewriting "make" so that variables are only evaluated on a
"need to know" basis. So, for example, if all we need to know is
PKGNAME, there is no need to evaluate, for example, _RUN_LIB_DEPENDS,
unless the writer of that particular port has done something like having
PORTNAME depend on the value of _RUN_LIB_DEPENDS. So "make" should
analyze all the code it is given, and only figure it out if it is needed
to do so. This would include, for example, figuring out .for and .if
directives on a need to know basis as well.

I have only poked around a little inside the source for make, but I have
a sense that this would be a major undertaking. I certainly have not
thought through what it entails in more than a cursory manner. However
I am quite excited about the possibility of doing this, albeit I may
well put off the whole thing for a year or two or even forever depending
upon other priorities in my life.

However, in the mean time I want to throw this idea out there to get
some feedback, either of the form of "this won't work," or of the form
"I will do it," or "I have tried to do this."

Best regards, Stephen
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: portmanager port upgrade question
    ... you have questions about the port system. ... The default port now is linux_base-fc4 and if someone tries to install ... the portstree should be up ta date (note the ...
    (freebsd-questions)
  • Re: Uninstalling Port installed applications
    ... I don't think the port system could help by itself, ... any of B, C, D, E) if the dependent port still exists in the ... You should consider installing portupgrade only if to keep the ...
    (freebsd-questions)
  • Re: FreeBSD 4.8: netscape + mozilla
    ... > This is a FAQ. ... You updated the gettext port, ... Without any further installations, updates, ..., or using the port system. ...
    (comp.unix.bsd.freebsd.misc)
  • Re: The case for FreeBSD
    ... To use this port, a newbie must be introduced to the port system. ... may accidently get a fortune tip to read 'man ports', ...
    (freebsd-current)
  • Re: py3k feature proposal: field auto-assignment in constructors
    ... I appreciate everyone's feedback on the topic. ... creating more complexity is not the way to go. ... This is probably even more preposterous than @host, @port, but to me ...
    (comp.lang.python)