Limitations of Ports System
david at vizion2000.net
Sat Dec 15 09:44:19 PST 2007
On Saturday 15 December 2007 08:04:31 Frank J. Laszlo wrote:
> 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.
> Frank Laszlo
And get this
I have been around the computer world using *nix long before freebsd came
along. That does not mean what I say today deserves to be judged other than
on its face value. However what over 40 years in IT has encouraged me to
think that those who invite people to judge a book by its cover have either
not read the book or can't be bothered to do so.
I am sure you have a lot of knowledge and experience but I doubt whether your
collegiality is more attractive than your sense of humour.
I recall you once said:
"remember sometimes my jokes are crude"
judging by your contributions to this thread am I not entitled to wonder if
your assessment of your jokes is also applicable to your general standard of
Now please take note;
1. This thread is entitled Limitation of Ports System. Please stay on topic.
2. If you want people to take you seriously either post some technical
information relevant to the topic that gains you some credibility or press
the delete key and keep quiet.
3. Please stop trolling.
4. You could start a thread "Why we should not discuss the limitations of Port
System and keep your contributions on topic there. I can assure you that I
will not be trying to highjack that dialogue.
More information about the freebsd-ports