Re: [Mingw-cross-env-list] /usr/bin vs /usr/$TARGET/bin

[Dmitry Groshev]

Hello!

You wrote:
> saves a lot of work in the long run. The prefixed versions are
> unambiguous - you're looking through a log file and see "ar" and know
> exactly what is wrong.

Maybe so. But if I can get a package to compile, I do not *need* to
know whether something was or wasn't wrong in its buildscripts.

> How do you identify the packages that need this?

By trial and error, naturally. If something doesn't compile with
prefixed binaries only, I try compiling it with unprefixed+prefixed.
Basically, if I see that providing a different PATH value fixes build
problems for some package, then I feel no need for more complex fixes.
Simpler solutions are better.

> Are you using just the basic
> toolchain from mingw-cross-env and then building other libraries with
> your own script?

Naturally so. For my project, I need DLLs, not static libraries alone;
and specific versions (stable, known, and patched), not
latest-and-greatest (and buggiest). So I need only what "make gcc"
produces - everything else I need, gets built with my own script.
I normally use my own cross-MinGW build for that, but decided that
supporting other existing cross-MinGW variants, including
mingw-cross-env, will be useful.

> How do you deal with packages that have native build steps and
> debugging in a terminal? I'm like the idea of "ephemeral" PATHs, but
> they've never really worked out in practice for me.

I give them PATH with native unprefixed binaries in it.


-- 
-= With best regards, Dmitry Groshev =-