CMake and "mingw32-make"/&q...

rubenvb
2010-05-08
2013-06-06
  • rubenvb

    rubenvb - 2010-05-08

    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

     
  • Ozkan Sezer

    Ozkan Sezer - 2010-05-08

    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 ?!?!

     
  • NightStrike

    NightStrike - 2010-05-08

    Sounds like a rather flaky design in cmake. 

     
  • rubenvb

    rubenvb - 2010-05-08

    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.

     
  • Ozkan Sezer

    Ozkan Sezer - 2010-05-08

    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!

     
  • Jonathan Yong

    Jonathan Yong - 2010-05-08

    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.

     
  • rubenvb

    rubenvb - 2010-05-08

    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?

     
  • Jonathan Yong

    Jonathan Yong - 2010-05-08

    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.

     
  • rubenvb

    rubenvb - 2010-05-08

    Ok, let's hope Sezero's build will include the change in the next release.

    thanks for clearing this up jon_y!

     
  • rubenvb

    rubenvb - 2010-05-08

    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.

     
  • Jonathan Yong

    Jonathan Yong - 2010-05-09

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

     
  • Ozkan Sezer

    Ozkan Sezer - 2010-05-09

    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…

     
  • rubenvb

    rubenvb - 2010-05-09

    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.

     
  • Ozkan Sezer

    Ozkan Sezer - 2010-05-09

    > 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).

     
  • NightStrike

    NightStrike - 2010-05-10

    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".

     
  • Jonathan Yong

    Jonathan Yong - 2010-05-10

    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.

     
  • rubenvb

    rubenvb - 2010-05-10

    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 :)

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks