relying on user's $PATH can break build about minimal HOT 6 CLOSED

@dbc - I'm happy to hear you were able to resolve this issue quickly! Good work!

The MLL project provides a relatively simple build infrastructure and there might be some other glitches like this one. I'm using Ubuntu and Linux Mint as test machines and I'm using the defaults provided by these machines. This is why I haven't faced this issue in particular.

from minimal.

Well, you shouldnt have relative paths in $PATH anyway...
relying on $PATH is good, as you can include wrappers like ccache, icecc and other wrappers.

from minimal.

Well, when I first started using Unix on a PDP-11 over 35 years ago I was taught that the user's $PATH was expected to be different for every user, it's theirs to control. So a script that depends on the user's path contents and order is broken by definition. Portable scripts and makefiles use explicit paths to executables.

from minimal.

Well, the problem with GNU/Linux based operating systems is that there is no easy way to tell where the dependencies have been installed. Unlike BSD, where we have common physical layout, in GNU/Linux world we have complete mess of different folders and software pieces which can be invoked in many different ways.

That said, if the user is experienced enough to change the $PATH shell variable, then the same user should be also skilled enough to figure out what is wrong if something doesn't work as expected.

from minimal.

You do speak truth. Although the minimal build scripts only use a small handfull of tools. It might be worth going through them to see if they are all mentioned in LSB file system layout, in which case portability should be pretty good. Or to be really pedantic, every script could start with some common boilerplate like: CP=/usr/bin/cp and then refer to the tools as $CP, etc.

The only script that tripped for me was 09_, which is when busybox appears in the local directory, and the busybox version of cpio doesn't support -R. The scripts may have been picking up busybox in other places but I didn't notice because the functionality lines up and of course I wasn't cross-compiling.

from minimal.

The MLL build infrastructure relies on already existing source bundles and their internal build processes which in most cases are defined via Makefile. That said, MLL is just a 'mediator' between the build host and the actual build process for the specified source bundle. There are some source bundles which use a lot of build dependencies (glibc is one of them) and it will be really hard to implement all proper checks in order to avoid collisions with modified $PATH variables.

I agree there is issue here but the potential impact in reality is really low.. Besides, in your particular use case you were able to fix this problem - so I'm closing the issue.

from minimal.