[FFmpeg-devel] [PATCH] configure: support MSYS2

[Kacper Michajłow]

2015-01-25 21:36 GMT+01:00 Hendrik Leppkes <h.leppkes at gmail.com>:

> On Sun, Jan 25, 2015 at 7:44 PM, James Almer <jamrial at gmail.com> wrote:
>
> > On 25/01/15 2:47 PM, Hendrik Leppkes wrote:
> > > On Sun, Jan 25, 2015 at 6:43 PM, Michael Niedermayer <michaelni at gmx.at
> >
> > > wrote:
> > >
> > >> On Sun, Jan 25, 2015 at 05:02:58PM +0100, Reimar Döffinger wrote:
> > >>> On Sun, Jan 25, 2015 at 03:59:12PM +0100, Hendrik Leppkes wrote:
> > >>>> On Sun, Jan 25, 2015 at 3:26 PM, Hendrik Leppkes <
> h.leppkes at gmail.com
> > >
> > >>>> wrote:
> > >>>>
> > >>>>> MSYS2 uses a system name of "MSYS_NT-6.3" instead of
> > >> "MINGW32_NT-6.3" in
> > >>>>> MSYS1.
> > >>>>>
> > >>>>
> > >>>> Apparently this isn't quite correct, and you have to start MSYS2
> with
> > a
> > >>>> special batch file that overrides this for you.
> > >>>> Just running bash.exe or sh.exe from a DOS prompt results in this
> and
> > >> is
> > >>>> apparently considered "wrong usage".
> > >>>
> > >>> I don't really see anything wrong with this, however I'd rather have
> > >>> a compiler-based detection.
> > >>> I.e. if the compiler define __MINGW32__ set the host to mingw (unless
> > >>> set explicitly).
> > >>
> > >>> This should also address my other annoyance that you have to specify
> > >>> --host when it really should be obvious that you are cross-compiling
> to
> > >>> MINGW for example.
> > >>
> > >> i dont use "--host*" for my mingw building
> > >> just -cc='ccache x86_64-w64-mingw32-gcc' --arch=x86_64
> > --target-os=mingw32
> > >> --cross-prefix=x86_64-w64-mingw32- --target_exec=wine
> > >>
> > >> the rest i use should not be mingw specific
> > >>
> > >>
> > > I've never had to specify --host things either, the only problem with
> > MSYS2
> > > I ran into was that you still need to specify --target-os unless you
> use
> > > their fancy batch file, and that tripped me up a bit.
> > > Never a problem with old MSYS and my own gcc build.
> >
> > As you said the old MSYS uses "MINGW32" as part of the system name, while
> > the
> > normal batch file for MSYS2 sets it as "MSYS".
> > If you instead use the x86 batch file it will be set as "MINGW32", or
> > "MINGW64"
> > if you use the x86_64 batch file.
> >
> > The different batch files exist not just to change the output of uname,
> > but also
> > to change the PATH environment variable too include either /mingw32 or
> > /mingw64
> > respectively. Their package manager offers a complete toolchain and
> > precompiled
> > libraries, which get installed in one of the two folders above.
> > Ideally speaking, if you don't want to use their gcc toolchains, you
> should
> > install your own in some other folder (/usr/local, /opt, etc) and use the
> > normal
> > batch file.
> >
> > configure currently only checks for mingw32 since that's what MSYS sets,
> > so it
> > needs to be updated to also check for mingw64 and msys, so this patch is
> > IMO
> > correct but incomplete as its missing the check for the former.
> >
> >
> My problem really is with their choice of default. Apparently (or so I am
> told), the MSYS_* string is for building things actually for MSYS itself,
> which is imho a bad default.
> If I just call sh/bash.exe (like I do in a multitude of my scripts), I
> wouldn't want that to be the default value, especially since it breaks with
> compat for all sorts of projects (we're not the only project with that
> problem)
>
> I agree that this change of behavior comparing to MSYS1 can be confusing.
But I think they made it sane enough. If we set MSYSTEM environmental
variable to MINGW32 anywhere before call to sh/bash.exe it will present
itself as MINGW32_* and work fine. This doesn't require any tricks just one
env variable to be set. Additionally when calling "bash --login" it will
alter PATH to include /mingw32 bin dir, but this is optional if we take
care about it ourself.

As for the path itself I think it is incorrect because we can't consider
MSYS and MINGW the same thing.

- Kacper