Roland Mainz writes:
> # use "shcomp" if present to compile the shell script,
> # otherwise just copy it:
> $(ROOTUSR)/usr/bin/foo: foo.sh
> if [[ -x /usr/bin/shcomp ]] ; then \
> shcomp foo.sh >$(ROOTUSR)/usr/bin/foo \
> else \
> cp foo.sh $(ROOTUSR)/usr/bin/foo \
> fi
This means that different users running builds on different build
systems can end up with different results *SILENTLY*. That doesn't
seem right at all.
I'd prefer to see the build fail if the required components to do the
build aren't present -- it should just invoke shcomp and die if that
doesn't work.
But if that's not possible for some reason then at least do something
like (changing ROOTUSR to ROOT, as I think that's what was wanted):
else \
echo "WARNING: shcomp not found; using uncompiled script">&2 \
cp foo.sh $(ROOT)/usr/bin/foo \
fi
For what it's worth, there are other problems here. This should be
using a common install rule such as $(INS.file) rather than explicitly
copying things into $(ROOTUSR).
> ... I belive the answer is "no" ... but I better ask before starting to
> add some kind of staged putback monstrosity...
It's not really a question about what's "allowed." It's more a
question about values -- and for ON I place a higher value on things
that produce deterministic results than things that try to "cope" with
a damaged build system.
> 2. The same question for the SFW gate - AFAIK the answer should be "yes"
> since stuff like "configure" could pick-up "shcomp" automagically
> anyway...
It seems almost equally incorrect there, for exactly the same reasons
as above (the risk of unreproducible results), but you're right that
GNU autoconf tends to hide atrocities.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
