Rupert Swarbrick <rswarbrick at gmail.com> writes:
> Aleksej Saushev <asau at inbox.ru> writes:
>>
>> $(echo *.lisp) has an undefined behaviour per standard, the correct way
>> to do this within automake framework is to maintain list of files
>> or utilize local targets. E.g.
>
> Thank you for finally telling us what your toolchain is.
>
> Are you saying that the build fails on NetBSD because of calling out to
> "echo" or are you saying that, while the build works, the Posix
> specifications say that calling echo like this invokes undefined
> behaviour?
You're confused. These keywords are generated automatically, they are
always $NetBSD$ for me, even when I work on FreeBSD, Solaris, or Linux.
> If the latter, I don't intend to apply your patch: although I don't have
> strong feelings about it, I really don't see the point. Maybe someone
> else does. If the former, obviously we should apply it.
The build completes, but since variables with names "echo *.lisp ..."
are undefined, a lot files are not installed.
> And why does this line invoke undefined behaviour?
This is not my invention, that's how the standard describes it.
> Is it just that I
> can't assume that echo does what I expect? Or something about the
> globbing? (But presumably then your fix wouldn't work either) Or is it
> something about expanding the results of shell functions in a Makefile?
> I don't have any experience of other Make implementations, but I'm
> really confused about how one could possibly behave differently from
> what I expected here.
POSIX says that the value of $(<string>) where the string contains spaces
is undefined, which is precisely what we observe.
--
BCE HA MOPE!