On Wed, 22 Jul 2015, Steve Lhomme wrote:
On Tue, Jul 21, 2015 at 6:45 PM, Martin Storsjö <[email protected]> wrote:
On Tue, 21 Jul 2015, Steve Lhomme wrote:
On Tue, Jul 21, 2015 at 4:46 PM, Martin Storsjö <[email protected]> wrote:
On Tue, 21 Jul 2015, Steve Lhomme wrote:
renaming /usr/bin/link.exe in msys2 to /usr/bin/link preserves the
pathes
and allows using MSVC when it's in the PATH
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
So this still requires you to hack your environment? I'd rather skip the
workaround if it requires you to have a nonstandard environment setup...
link in msys should be called without the exe all the time. So it's a
very minor tweak.
It still requires modifying the surrounding msys environment, which I'd
consider a no-no. (I.e., completely ok to in your local environment, but I
wouldn't go on and suggest it in the docs, even less change configure to
require/assume it).
Compared to messing with the PATH order, as suggested.
Uhm, your definition of "huge hack" is totally different than mine - nothing
anywhere _forces_ the msys paths to be before the msvc ones (keep in mind
that there is no full PATH that contains both msvc and msys in one single
line; it's all assembled by small pieces in your own environment, and that
environment may be very different from mine).
If possible, just make sure that the VC paths are earlier in the path
than
/usr/bin.
No, that is wrong. msys_shell.bat puts all the Msys env before
whatever was in PATH. And you don't want all kinds of things in your
PATH messing with msys. Nor rewrite the pathes to VS tools manually.
Yes, but please note that this assumes that you set up the environment in
one specific order (first the vcvars.bat, then msys on top of it) - nothing
really says that you need to do it that way; what if the msvc paths are
Yes:
https://wiki.libav.org/Platform/Windows#Microsoft_Visual_C.2B-.2B-_or_Intel_C.2B-.2B-_Compiler_for_Windows
http://www.ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b-or-Intel-C_002b_002b-Compiler-for-Windows
added _after_ initializing the msys environment? I'm aware this probably is
the way things are done in most cases (and that's what I do myself), but
don't assume this is the only way things can be done.
I'm using the official/endorsed way like any other developer looking
for a solution would do.
By default these instructions *do not* work with a clean environment.
You have to go further the tutorial to find out in all cases you *have
to* modify your environment for a chance to work. Except it doesn't
say how exactly you can achieve this change. Because it's not easily
manageable. You either have to modify MS batch files (not recommended)
or msys2 core files (not recommended) or create your own script to
reorder parts of the path (not explained and tricky).
So in short, building libav with MSVC is not working out of the box
and tricky or dirty. And the documentation is incomplete. IMO this is
not right.
I'm sorry, I don't follow here, what part of the documentation is
incomplete? It does say that you may need to check which link gets
invoked, and potentially rename the msys link.exe.
If there is a solution like my first one to use "which cl.exe" to find
the path to link.exe that is safe from spaces in the path and not
using cygpath, it should solve this cleanly. Unfortunately my whole of
shell scripting goes as far as what I proposed.
Yes, something similar to that patch would be preferrable, as long as it
doesn't rely on msys/cygwin specific tools (which would break msvc on
linux).
Please do understand that we've spent insane amounts of time on getting
this work already, and this is just as annoying to us as well. For now,
the current compromise has been deemed "the least bad one", but we are of
course interested in getting it even smoother. But I'd rather not pick a
solution that is only better in one way and worse in another.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
