Aryeh M. Friedman wrote:
Your correct that there are 2 seperate issues at play here but there
is a common solution (and to be honest I have yet to see any
feature/issue discussed in any of the re-engineering threads that
doesn't at least become more manageable under this general design
concept I am working under).... I hate to keep referring to Miller97
but I think it highlights (directly or indirectly) every single issue
that has been discussed while a little off topic (and slightly self
serving) there is a good explanation of  the general idea behind what
I have in  mind in the  cook tutorial (I am the author thus it is
self-serving)
http://miller.emu.id.au/pmiller/software/cook/cook-2.30.tut.pdf..

In the the specific case of parallel builds once we pre-scan the DAG
it is trivial to do a *FULL* DFS on it and just say for any time two
ports are not in the same DFS generated subtree in respect to some
root target (can be recursive) they can be build in parallel.  Locking
is also trivial now that the decision on ordering is made by the ports
system and not indivual ports makefiles. (the indivual make files are
still needed to build the port but should not and by definition can
not contain knowledge about their depends).

Side note the more we discuss this the more obvious it becomes to me
it has to be in some OO lang and since C++ is the only one in the base
system it kind of forces C++ to be the implementation lang.

<...removing completely unnecessary CC list...>

Let me get this straight. You've been on this list for around 3 months, you do not maintain any ports, and about the only threads you've been involved in related to redesigning the ports? Please.. You really have no idea how complex a system you are attempting to engineer. I shouldn't even say attempting, because I have yet to see any code, ideas for code, or even talk of what language it will be in. (mind you, I haven't went back through the 3-4 threads on this same topic you've participated in) Please take this thread elseware, there is no need to make it public until you have something to show the masses.

Regards,
   Frank Laszlo
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to