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.