MinGW-w64 - for 32 and 64 bit Windows

Hi, I recently got a patch pushed to CMake master so that it works with mingw-w64/w32 out of the box. Only one thing that's wrong: when you run cmake -G"MinGW Makefiles", it searches for mingw32-make, and can't find it unless you rename gmake to mingw32-make. What is the long term plan concerning the naming of the make utility? (Right now I'm forced to make a copy of gmake named mingw32-make for Qt configure and CMake). I'd ask these projects to "fix" their naming if I can confirm gmake is going to be the official name for almost eternity :) Thanks

First off, this project doesn't officially distribute make, I just put it in my personal builds for users' convenience. And since kmx from the stawberry-perl project said that there should be a difference between the make version from mingw32 project and ours, I found it reasonable and I since rename it to gmake which is a well known conventional name for "gnu make". <rant> It is utterly unfathomable for a project to search for 'mingw32-make' and not 'gmake'. </rant> Now you just tell me what "I" should do with this ?!?!

Sounds like a rather flaky design in cmake.

Ok ok, hold your horses! Where could one officially get a "supported" make distribution then? I'm guessing a toolchain isn't of much use when the glue between all tools is missing? I'll (try to) get Qt and CMake to fix their shizzle.

and voila: http://public.kitware.com/Bug/view.php?id=10690

Where could one officially get a "supported" make distribution then? Well, you can find make packages, by yours truly, under the "External binary packages (Win64 hosted)" section, but they also have the tool as gmake.exe. and voila: http://public.kitware.com/Bug/view.php?id=10690 Thanks!

looks like I was too late... AFAIK, Gnu make comes in 2 variants in the same source package, one for unix, the other for win32. Anyway, "mingw32-make" is a name to tell win32 "make" apart from MSYS make, and "gmake" is used to tell apart whatever make the current platform has with gnu make. IMHO, if "our" make is plainly windows make, it should be named "mingw32-make" as opposed to the standard unix gnu make that understands some of the unix-ish conventions.

looks like I was too late... AFAIK, Gnu make comes in 2 variants in the same source package, one for unix, the other for win32. Anyway, "mingw32-make" is a name to tell win32 "make" apart from MSYS make, and "gmake" is used to tell apart whatever make the current platform has with gnu make. IMHO, if "our" make is plainly windows make, it should be named "mingw32-make" as opposed to the standard unix gnu make that understands some of the unix-ish conventions. Exactly why I asked here :) So what's the definite plan on this?

I assume we are using plain win32 make with "MinGW Makefiles" generator, so IMHO, we rename ours to mingw32-make, since its already compatible with mingw.org's native make. There is also a "MSYS Makefiles" and "UNIX Makefiles" generator, clearly not for native win32 make.

Ok, let's hope Sezero's build will include the change in the next release. thanks for clearing this up jon_y!

UPDATE: Please let me/everyone know what the decision is. Bill Hoffman (Kitware/CMake) wants to know so he knows what to do of course :) Thanks.

sezero: Are you OK with doing a new "mingw32-make" package?

sezero: Are you OK with doing a new "mingw32-make" package? Well, I would, I can keep two exe copies in the packgage: gmake.exe and mingw32-make.exe. (hell I can keep 3 if I include make.exe.) This whole thing is pointless, and I didn't know that a decision of a puny unofficial packager could affect so many things, but OK...

Sezero, This naming thing is just to prevent confusion and provide a good out-of-the-box experience IMO. A lot of projects depend on some standard naming to be present in the toolchain (which may not always be the *correct* naming). I strongly believe once an official release of mingw-w64 comes (and work starts on a 1.1 or 2.0 branch) that there needs to be uniformity in such things, for one because other projects might depend on a stupid thing like the name of a program. PS: a "make.exe" would not be such a good idea, because when that is present in PATH and you're running MSYS, calling make from the MSYS shell is broken.

> I strongly believe once an official release of mingw-w64 > comes (and work starts on a 1.1 or 2.0 branch) that there > needs to be uniformity in such things, for one because As I said before, the make thing is not an official part of mingw-w64 and I provide the tool in my personal builds only for convenience. If the mingw-w64 project ever makes it part of it and agrees on a policy of its name someday, I would then follow it. > PS: a "make.exe" would not be such a good idea, because > when that is present in PATH and you're running MSYS, > calling make from the MSYS shell is broken. Well, then a developer should be able to delete the thing, won't he? In any case, I made new make packages containing the same tool with all three names where the developer will be able to choose the name he likes, admires, adores the most. The package also have them in a non-standart bin_x86 and bin_amd64 paths, so the user will have to copy his choice therefore I won't be the one who breaks something (if any).

Please let me/everyone know what the decision is. Bill Hoffman (Kitware/CMake) wants to know so he knows what to do of course I see no reason for this project to release some sort of official naming of the make utility. It's not part of the toolchain, and we can't cater to the absurd detection scheme of CMake. This naming thing is just to prevent confusion and provide a good out-of-the-box experience IMO. On the contrary, it sounds like it's adding a lot of confusion. A lot of projects depend on some standard naming to be present in the toolchain (which may not always be the *correct* naming). Yes, the *toolchain*. Make is not part of it. I'm not saying that everything might change in the future, but I have never seen someone define the toolchain as "gcc, binutils, libc,..... and make." I strongly believe once an official release of mingw-w64 comes (and work starts on a 1.1 or 2.0 branch) that there needs to be uniformity in such things, for one because other projects might depend on a stupid thing like the name of a program. We can't cater to idiotic policies of other projects. If their detection mechanism is so bad that it assumes that a windows platform cannot have a program called "gmake.exe", then this is just yet another reason why CMake is a poor product. Have it do a real test to see what version of make it's using (hint: start with running make -v), and not rely on completely ad hoc, meaningless naming conventions that have no basis in being a "standard".

unfortunately make -v doesn't really tell which command set to use (eg "del" vs "rm"). IMHO, "mingw32-make" means "use windows command prompt style commands" make, similar to what mingw.org is already doing for mingw32-make. If we do distribute "make", we should not create another "gmake.exe" or "make.exe" to fill that similar functionality.

First let me make it clear (pun intended) that I understand sezero and nightstrike's view on this, but that I must disagree. I will take into account several other "toolchains": MSVC: comes with compilers/binutils (cl, link, lib...) and two (now three) "make"-like utilities: nmake, vcbuild, and msbuild GNU/GCC: I have never compiled a linux program without the use of make && make check && make install GCC/MINGW: ditribute two flavors of make: one UNIX/MSYS variant, and one native windows variant (mingw32-make), which is what we're talking about in principle. Some "standards" have been established by being used for years, and everyone is accustomed to them, and other projects rely on those "self-established" standards. IMHO, it's not strange that a program that works differently on another platform gets another name. mingw32-make=/=(g)make, it's make for the win32 platform. I strongly agree with jon_y on this, and add to his arguments that compatibility is one of this projects key strengths? Then a compatible naming of the make distributed should be held to. PS: on a sidenote, webkit devs are looking into the WebKit JIT for mingw64 right now, aren't I awesome :)