I misunderstood when I agreed with Glenn.... I was thinking that the
compiled shell scripts would be used on the build system to expedite the
build, not as deliverables to the target system in their own right.
In the former case, testing exec() seems appropriate. The latter case
should probably just be avoided, although I suppose you could deliver
the binaries "knowing" that exec "must be there". (I.e. we know the
target system, no need to "test for it".)
-- Garrett
Keith M Wesolowski wrote:
> On Tue, Apr 15, 2008 at 09:32:26AM -0400, Glenn Fowler wrote:
>
>
>> shouldn't the test be that exec(2) recognizes shcomp binaries?
>>
>
> No! As James Carlson pointed out, doing tests against the build
> system is fundamentally wrong. You cannot assume that every (or even
> any) system on which the software will be installed looks like the
> build machine. Nor is it acceptable to generate materially different
> build products on multiple build systems meeting known requirements.
>
> Therefore "tests" during the build process are virtually always
> unnecessary and wrong. Why perform a complicated test on the contents
> of the proto area to ensure that a shcomp format binary will be
> executable on an installed system? Instead you should just develop,
> test, and integrate the two changes together and *know* that the
> installed system will work. ON is an integrated, self-consistent
> piece of software with specific and well-defined build system
> requirements. The ability to build and then run pieces of it on
> systems with arbitrary software installed is a non-requirement. Code
> added for this purpose is at best superfluous and likely harmful.
>
> No autotools-like behaviour in ON, please. Bad enough that SFW is
> allowed to get away with it.
>
>
