> > From: "Dave Korn" > > > >> Ummm, that doesn't really sound like a well thought through plan > >> to me. > > > > That only means it can still happen. > > Yes, but it suggests something about /how/ it should happen: it should be > designed and spec'd before it is implemented. That's just elementary good > practice.
Yeah, but how things *should* happen doesn't mean that this is how things *happen*. (-> elementary existing practice) > It's not like "adding a function" is such a complex change that > it's worth doing as a separate step before we have any idea what that function > is supposed to actually do. What the function is supposed to do is sufficiently clear from the name, and what it potentially could do is clear from its placement and the parameters that it takes. It's not a complex change, yes, but it's worth doing. > > Surprised? > > Why should I be? It's a blatant stitch-up. You haven't adequately > described the situation, you haven't told us what your code is doing > differently in any detail, so I don't see what I could base any expectation > *on*. The situation was described and we knew what we wanted to test. Shure, the result is unexpected, but that happens. My interpretation is simply that first we have already at least 2 path searches per command (grep "_fullpath"). It's difficult to say under what circumstances these are run now, but certainly they are unneccessary. Anyway, one more or less should really make no difference, so what really seems to count here is getting rid of the initial path search (grep "find_and_set_default_shell"). It is some crafted piece of code and must be really slooow, seen the results. Seen the test description, the conclusion is not so far away, no? http://lists.gnu.org/archive/html/make-w32/2007-10/msg00183.html --- grischka _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32
