On Wed, Jul 22, 2015 at 8:28 AM, Martin Storsjö <[email protected]> wrote: > 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.
Well it does say that but in a vague way. Also renaming msys "link.exe" to "link" should work and not break much in the whole environment. But that's not enough as long as we have ld_default="link". Hence this patch. There is not a case where MS link.exe will not be named link.exe. Unless you mess with your environment seriously, in which case you're on your own. >> 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. I understand and I agree. > // Martin > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
