Add mingw/msys support

[therustmonk]

This PR makes similar what #10 does, but with premakes and offered to devel branch.

I've implemented MinGW/MSYS support. It builds:

$ cd build/gmake_windows
$ make
==== Building nfd (release_x64) ====
Creating ../lib/Release/x64
Creating ../obj/x64/Release/nfd
nfd_common.c
nfd_win.cpp
Linking nfd
==== Building test_opendialog (release_x64) ====
Creating ../bin
Creating ../obj/x64/Release/test_opendialog
test_opendialog.c
Linking test_opendialog
==== Building test_opendialogmultiple (release_x64) ====
Creating ../obj/x64/Release/test_opendialogmultiple
test_opendialogmultiple.c
Linking test_opendialogmultiple
==== Building test_savedialog (release_x64) ====
Creating ../obj/x64/Release/test_savedialog
test_savedialog.c
Linking test_savedialog

I've checked all tests, It works!

P.S. I made changes with linux, but checked it with windows+msys.

[therustmonk]

@mlabbe There is an instruction how to install msys2 and a download link: http://msys2.github.io/

This bootstraps a development environment:

# updates (got it from doc)
pacman -Sy pacman
pacman -Syu
pacman -Su

# git + compilers collection
pacman -S git
pacman -S mingw-w64-x86_64-toolchain

[mlabbe]

Msys2 corrupts itself running the second command in your instructions. I tried it on two different workstations. It errors out with:

3 [main] pacman (8536) C:\msys64\usr\bin\pacman.exe: *** fatal error - cygheap base mismatch detected - 0x180326400/0x18033A408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version should
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.

I do not have any cygwin dlls installed and cygwin is not in my search path. I rebooted, which had no effect.

[mlabbe]

Any suggestions, Denis? I have some bandwidth today to try again.

[therustmonk]

I haven't good ideas about it, but let's try to solve it.

Could you describe your environment? Did you use it with virtual environment or native? Do you have another Cygwin version installed? Which values does your PATH variable contain?

It looks like environment wasn't tuned. What kind of shell did you use? Did you work with mingw64.exe shell or cmd.exe?

It's strange why it needs cygwin1.dll, because mingw don't use it at all. I checked pacman.exe with Dependency Walker, it uses msys2.dll and no cygwin.

[rafalcieslak]

If this error happens on running the second command from these instructions, then clearly the first one - which updated pacman binary - must have downloaded the binary in an incompatible version, presumably newer than your MSYS2 environment (note that the MSYS2 installer, while convenient, does not provide the newest core binaries). I suggest trying to bring your MSYS2 core up to date before upgrading pacman (thus immediately after installing MSYS2 and before using pacman to download anything). This is fairly simple:

• First, run update-core, which will download and upgrade the MSYS2 core.
• Then close your MSYS2 environment entirely (close the shell/s), start it again. [If you skip this step, your MSYS2 installation is likely to become corrupt]
• Run pacman -Suu, which will upgrade all other packages.

If that succeeds, continue with Denis' instructions, skipping first three (updates).

[mlabbe]

@deniskolodin @rafalcieslak I don't know what to tell you. In addition to the two Windows 10 machines, I just built a Windows 7 machine from scratch and ran your instructions, and got the same results. These are not VMs, they are physical machines that have no similarities other than a few packages installed on them. In either case, I pruned the path.

@rafalcieslak Your pacman -Suu instruction corrupts msys entirely. I get the following error message:

:: Processing package changes...
(1/2) upgrading filesystem                           [##########################] 100%

      WARNING: the shell starting scripts have been unified. Please update your
      shortcuts to the following targets, otherwise they will STOP WORKING:

          * MSYS2_ROOT\msys2_shell.cmd -mingw32
          * MSYS2_ROOT\msys2_shell.cmd -mingw64
          * MSYS2_ROOT\msys2_shell.cmd -msys

(2/2) upgrading mintty                               [##########################] 100%
warning: terminate MSYS2 without returning to shell and check for updates again
warning: for example close your terminal window instead of calling exit

After this, msys2_shell.bat is fucking gone.

I have tried this ten times now on three different computers. Are you telling me these instructions are working for you when you test them before sending them to me? Are you trying these out on a fresh install? Because I've put in hour trying to get msys2 to work using your instructions and all it does is corrupt my filesystem.

[mlabbe]

Okay, I managed to get it installed. After update-core, I need to create new windows shortcuts. I don't know what the parameters do because I don't use this toolchain. And there is no "make", even after installing mingw-w64-x86_64-toolchain.

@deniskolodin:
Please give me full instructions on how to properly build this. I do not use these tools and your instructions end before the executable is built, in addition to corrupting the filesystem.

Test your instructions before sending them to me on a fresh machine, as your previous instructions corrupted my filesystem.

I am sure I could figure out something, but that's not good enough because I might go off the beaten path. And then I am not properly testing my own project.

[therustmonk]

Curious thing: I can build it locally (even I don't need any update after install), but I can't to do the same with AppVeyor. It fails with the same error. Branch: https://github.com/DenisKolodin/nativefiledialog/tree/fgw-appveyor

@mlabbe I'll send you AppVeyor config, when it works. Have you tried to build it locally or with AppVeyor? I'll try to test it with other hardware too...

@rafalcieslak Could you build it locally? Any errors?
To build use:

cd build/gmake_windows/
make

[mlabbe]

@deniskolodin I'm only trying to build it locally. When I get that to work, I'm going to focus in on getting it to work with BuildBot. AppVeyor doesn't support Mac OS and so I can't use it for NFD. I have a Linux, Mac and Windows buildbot cloud for my company.

[therustmonk]

I've made it right, friends! It was really fun thing. AppVeyor has an alternative cygwin1.dll version somewhere.
I've fixed it with:

-   PATH=%PATH%;C:\msys64\mingw%MSYS_BITS%\bin;C:\msys64\usr\bin
+   PATH=C:\msys64\mingw%MSYS_BITS%\bin;C:\msys64\usr\bin;%PATH%

@mlabbe You are right about AppVeyor, it's windows build system only. To build for linux or mac we can add Travis config too. What about to merge appveyor.yml script to this PR?

[mlabbe]

I don't want to use two cloud build systems to "automatically" build something. There is nothing automatic about maintaining two build systems to cover 3 OSes.

I will be using my BuildBot network for that.

[mlabbe]

@deniskolodin After bootstrapping msys2, I get:

mlabbe@x:~$ make
bash: make: command not found

GCC works:

mlabbe@x:~$ which gcc
/mingw64/bin/gcc

Pls advise

[therustmonk]

In this case you should install toolchain:

pacman -S mingw-w64-x86_64-toolchain

I'm ready to help if it won't work.

[mlabbe]

I already did that and it didn't do anything. pacman -S make worked.

[mlabbe]

Okay! I merged the change after testing locally. The change is now in devel on the mainline which will be merged to master shortly. Thanks for your help.

[therustmonk]

@mlabbe It was merged! Thank you! It's a good start of this day )

About builds: Rust uses BuildBot to build releases and Travis to pass tests. It's useful, because with cloud build system you shouldn't maintain bots at all. Maintainers can check their PR's extremely easy, because build config is enough to use build system.

https://buildbot.rust-lang.org/waterfall?refresh=15
https://travis-ci.org/rust-lang/rust/

I'm ready to add AppVeyor any time if you want.

[mlabbe]

With NFD, all tests are passed when the executables are built without warnings in supported environments and architectures. There is no need to support another system for test harnesses.

My company, Frogtoss Games, has its own cloud because the existing solutions are insufficient. We build projects for RPi, Android, Linux, Mac and Windows, using Clang, GCC and Visual Studio. We also do more static analysis than is offered by the build clouds.

It is easy for me to extend our buildbot for this purpose.

I have added you into the readme.md credits for the mingw fix.

Michael Labbé

On Aug 14, 2016, at 8:25 PM, Denis Kolodin notifications@github.com wrote:

@mlabbe https://github.com/mlabbe It was merged! Thank you! It's a good start of this day )

About builds: Rust uses BuildBot to build releases and Travis to pass tests. It's useful, because with cloud build system you shouldn't maintain bots at all. Maintainers can check their PR's extremely easy, because build config is enough to use build system.

https://buildbot.rust-lang.org/waterfall?refresh=15 https://buildbot.rust-lang.org/waterfall?refresh=15
https://travis-ci.org/rust-lang/rust/ https://travis-ci.org/rust-lang/rust/
I'm ready to add AppVeyor any time if you want.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #19 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ABOUkbxXV5WFtcnoEbZo0smorU9LYj_rks5qf9xGgaJpZM4JecEA.

[therustmonk]

Thank you!