[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tony Theodore
Subject: Re: [Mingw-cross-env-list] /usr/bin vs /usr/$TARGET/bin
Date: Thu, 20 Jan 2011 18:14:59 +1100

On 14 January 2011 04:26, Dmitry Groshev <address@hidden> wrote:
> Hello!
> You wrote:
>> I haven't experienced similar problems, but I think symlinking is only
>> a cover-up for underlying build/configure issues.
> And I think when one cross-compiling setup works OK with unmodified
> projects' files, while another setup cannot work without patching them
> - from the user's standpoint not the projects, but something else
> looks like having "issues". ;-)

There's always a balance between practicality and purity - in most
cross-compiling scenarios, I've found that adhering to conventions
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.

>> In my mind, this
>> directory ($PREFIX/$TARGET/bin) should only really have our test
>> programs (win32 executables) or cross-platform *config type scripts.
>> The *config scripts are really just a concession to how much time we
>> have to make every package cross-build friendly.
> Myself, I could care less - workaround for such a halfbaked setup is
> simple, and is now added to my cross-compiling script: creating such a
> directory-of-symlinks inside the builddir, and inserting it at the
> beginning of PATH when it's needed.

How do you identify the packages that need this? I think I don't fully
understand what you're trying to do. Are you using just the basic
toolchain from mingw-cross-env and then building other libraries with
your own script?


> By default it isn't needed in PATH, but for some packages, adding it
> to the beginning of PATH is by far the easier, and more generic,
> solution for the build problems, than identifying and patching the
> "underlying build/configure issues" in each affected package.

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]