I have had smooth sailing using 'MSYS Makefiles' generator with some small modifications to the cmake scripting system. MSYS is a defined parameter upon cmake startup (even before project) and so I verify that in CMakeMSYSFindMake.com. Then, we are windows but uname works and so I dither with parameters in CMakeDetermineSystem. So we get MINGW and MSYS assigned. Libraries start out as /usr and /usr/local and are enhanced with the environment variables PKG_CONFIG_PATH (highest priority) and LDFLAGS (Lower priorit, but higher than /usr and /usr/local). You can also add paths with a LIBRARY_PATHS environment variable between PKG_CONFIG and LDFLAGS. libpaths.cmake does this work for MSYS and for unix. In the Platforms directory, Windows.cmake is modified to steer off MSYS cases, mingw only (not msys) falls through to the old behavior, I believe. So Mingw.cmake sets up the suffixes and calls libpaths just like UnixPaths would.
The link paths are still in MSYS form: I generally have to edit build.make to add in the proper device if I used msys shorthand .i.e., /mingw64/lib instead of C:/msys64/mingw64/lib: as usual, only the first one is properly translated. On Thu, Dec 4, 2014 at 8:11 AM, Jan Niklas Hasse <[email protected]> wrote: > 2014-08-25 22:30 GMT+02:00 Richard Shaw <[email protected]>: > > On Mon, Aug 25, 2014 at 2:50 PM, Matthieu Vachon > > <[email protected]> wrote: > >> > >> I think the patch works only when using mintty as the console. If you > >> use cmd directly and you start bash in it, the console is not a pipe > >> but a real tty. I may be wrong though as I did not test the Win32 API > >> calls inside the two "console". > >> > >> bash@mintty $ tty > >> /dev/pty3 > >> > >> bash@cmd $ tty > >> /dev/cons0 > >> > >> Moreover, someone redirecting cmake output to a file would also fail > >> into potential weird behavior I think. > >> > > Perhaps the best solution would be to go ahead and create a simple hack > > patch that just forces the default to be MSYS Makefiles. If you're using > the > > msys2 project then it should be a safe assumption. > > Any news on this? > > It would make patches like this unnecessary: > > https://github.com/bitshifter/glfw/commit/fbc6077d008cb942cfd9c5f179c6a211e6aa63bd > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > _______________________________________________ > Msys2-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/msys2-users >
CMakeMSYSFindMake.cmake
Description: Binary data
CMakeDetermineSystem.cmake
Description: Binary data
libpaths.cmake
Description: Binary data
MinGW.cmake
Description: Binary data
Windows.cmake
Description: Binary data
UnixPaths.cmake
Description: Binary data
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
