I was thinking more upon startup, but you're right, the performance hit may not be worth it. Maybe a lazier approach might work, though. For example, what if this test were done when it sees that it needs to know whether the command is a built-in or not? Of course, once the test is done, it won't need to do it again for future executions of the command.
I completely agree that runtime testing is both too slow and too complicated. I know nothing about autotools/configure stuff but is it not possible for the ./configure script to determine whether the /bin/sh on that platform uses builtins? That might be worth looking into.
Anyway, from what I understood of David's numbers, perl will build only 1% faster. Is it really worth the added complexity?
I didn't mention it before but the real issue - and the reason I noticed it in the first place - shows up when you start doing more advanced things with build scripts. E.g. when distributing builds to other systems there's a much higher fixed cost per script. Simply executing "/bin/true" or even "/bin/sh -c /bin/true" isn't such a big deal but when you start running the equivalent of "rsh <host> /bin/true" you begin to feel the pain.
But again, the pain is bearable and in my own toolset I can optimize it out in another layer anyway. I just thought the question of whether to inline "true" should be considered ("false" is less important as it's unlikely to be run more than once in a build).
-David
_______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
