PATH must not be mangled in makefiles

[stsp]

Currently smallerc's makefiles
change PATH. This breaks
cross-compilation systems,
like Termux, because there
we need to run not exactly
the binaries that were built.

I'll patch that out myself.
However, the real problem
is that smallerc relies on
PATH at all, when searching
its components. It should
instead rely on prefix.

[alexfru]

Introduce a pull request with the desired changes and I may merge it.

[stsp]

But there is already this comment:
https://github.com/alexfru/SmallerC/blob/master/v0100/smlrcc.c#L242-L244

// TBD!!! I should probably abandon the idea of launching subordinates via
// shell (using system()) and instead use exec*()/CreateProcess() and such
// to avoid this quoting/escaping mess.

I believe removing system()
is quite a big refactor for just
"Introduce a pull request" things. :)
I can only patch out PATH mangling,
which I'll do for Termux, but its
insufficient for upstreaming here.

[stsp]

So would you like to first address
the TBD above? I'll test this out and
see what remains (if anything at all;
I suspect that would be sufficient)

[alexfru]

So, you want smlrcc to be able to substitute some other executable names for smlrpp, smlrc, smlrl, nasm, n2f?

[stsp]

No, but path may be different.
In general, PATH must not be
used. Prefix should be used
instead.
Say, if prefix=/usr/local then
smlrc must look up smlrpp
in /usr/local/bin, while the
PATH may point to some
completely different build
of smlrpp elsewhere.

[alexfru]

Right, I didn't say it clear enough. Those names may be path-prefixed.
There's already

#ifndef PATH_PREFIX
#define PATH_PREFIX "/usr/local"
#endif

in smlrcc.c. Seems like you want this (or a differently named macro) extended to cover subordinate executables.
Would it work for you?

[stsp]

Yes, sure.
Just don't use system()
and use PATH_PREFIX+execve()
or alike instead.

[alexfru]

I'm not so sure about using something other than system()... I mean, it may be OK for smlrcc.c, which is already quite ifdef'd for different OSes.
Exactly what do you have against system()?

[stsp]

Well, given that your makefiles
stop mangling PATH, maybe indeed
I have nothing against system(). :)
So if you want, we can make that
a final solution.

Its just that normally the compilers
support a "sysroot" setup - an
alternatively prefixed location
where PATH doesn't point to.
Like eg /usr/i386-pc-msdosdjgpp.
In that case, given that there
may ALSO be a non-sysrooted
compiler installed, with system()
the situation is possible when
the sysrooted compiler would
call something from non-sysrooted
one.

[stsp]

Oh, and of course the main problem
is gonna be that you add curdir to
PATH in makefile, like this:

PATH := $(.CURDIR):$(PATH)

If we want to remove that
(and yes, we want!), then you
need to use something else
than system() pretty much by
definition. So my idea is to use
prefix, and also allow to override
the built-in prefix with a cmdline
argument.