Order or choosing which arm-none-eabi-gcc to use incorrect

[OpenUAS]

The makefile first hardcoded searches for path to look for arm-none-eabi-gcc, but first the $ which arm-none-eabi-gcc should be used.Businesscase: Sometimes one has on a development machine with the offical paparazzi toolchain to test compatibility and the sat AND the latest gratest Linaro self from source also in another dir added to your path. Since its added to the path , obviously that should be the one used a priority. Only if that one is not found (common if you are a normal user) fall back to the Paparazzi included ones. so first a picking up the arm-none-eabi compiler from the path, otherwise use arm-elf then sat pprz included.

[flixr]

It was a deliberate choice at that time to prefer the paparazzi-arm-multilib over arm-none-eabi found in the path.
The problem was that someone had a different arm-none-eabi toolchain installed (to the normal /usr, etc paths from the package), but that didn't have multilib support and hence failed to compile paparazzi.

You can always find a case that doesn't fit someone... But if it is more convenient for the majority of people to prefer the system path, we can change the behavior again.

[OpenUAS]

Good leave it as is then, I adjust myself

[flixr]

Personally I would also prefer to search the path first...
I can't even remember who had that issue with which package... so maybe we should just change the behavior?

[OpenUAS]

Yes, i would love to adhere to the standard way of detecting, search the path first, Note: IMHO a path is a strong indicator that one has installed some toolchain for some reason. If all development for PPRZ was done, then yes we would not need new toolchains and I would agree to use the default pprz compiler.but as PPRZ is strongly evolving in the processor aspect and in flux with new libs, e.g. our DSP improvement and future support for STMF4, it is not yet the case. But then again if it make life easier for beginners with PPRZ, I can live with current solution. after a 4.0 release will come back to it.