Premake5, Windows7, and gmake

[VladimirMarkelov]

I tried to use premake5.0.0-alpha12 (instead of premake4) on my windows7. There are some issues and differences between premake4 and 5

Here is my sample premake5 project:

-- premake5.lua
workspace "demo"
   configurations { "Release" }

project "demo"
   kind "StaticLib"
   language "C"
   targetdir "%{cfg.buildcfg}"

   files { "**.h", "**.c" }
   includedirs { "lib/include" }

   filter "configurations:Release"
      defines { "NDEBUG" }
      optimize "On"

1. After running mingw32-make on Makefile's generated by premake5 I got library with extension '.lib'. While with premake4 I got correct GCC/MinGW extension '.a'

2. I cannot recompile the project after changing any file(with premake4 generated Makefile I saw no troubles). mingw32-make fails with 'A subdirectory or file obj already exists.'. It happens because compiling every file tries to create 'obj' directory that already exists. Workaround: manually edit generated 'demo.make' and add 'if exist ...' before every 'mkdir' call. Or manually delete 'obj' and targetdirs, 'make clean' does not help because : 'mingw32-make clean' cleans targetdir but does not remove the targetdir. Rebuild with premake5 files it tries to create targetdir every time and fails on mkdir

[samsinsane]

Regarding the first point, you can add targetextension '.a' to correct this. I'm not sure if there's any particular reason why .a isn't the default for gmake on Windows, my guess would be nmake support but I really don't know, I only use VS for Windows builds.

As for the second point, that's likely a bug that needs to be fixed. I don't believe there are many Premake developers that use MinGW or similar actively, so you might be better off submitting a PR for this. You can find the problematic code here(for gmake) and here(for gmake2). You may need to update some unit tests, if not, I recommend adding unit tests to ensure this continues to work for you. Since this doesn't seem to impact other toolchains, there's a good chance "unnecessary" checks will be cleaned up in the future.

[VladimirMarkelov]

I'm sorry. I used to 'gmake' in premake4 and did not notice 'gmake2' in premake5. So, it seems premake5 'gmake' did not work (while premake4 'gmake' worked smoothly). premake5 gmake2 works as expected after I added to premake5.lua script two lines: targetextension '.a' targetprefix 'lib' Now a library name is the same as premake4 generates by deafult for gmake. And with 'premake5 gmake2' I have no trouble when I recompile.

I am not sure what the difference between gmake and gmake2. 'premake5 --help' shows the same descriptions for both, wiki-docs does not have gmake2 in section 'using premake'. If gmake2 is future replacement for 'gmake' I think my issue can be closed.

[realvictorprm]

There's gmake2? OK what's going on lol 😄 ?

[VladimirMarkelov]

Yep :) I found it to my surprise and tried immediately because another solution was to use premake4.

[tvandijck]

gmake2 is the rewrite of the gmake module with added features such as per file configuration, and custom rule support... it fixes a bunch of things like precompiled headers, and some other dependency issues.. It was written at Blizzard, and eventually merged into core as an alternative to gmake, while leaving gmake in place because some other modules (such as the D module) depended on it, and we didn't want to break those.

The idea however is to eventually port things over to the new gmake2 module, and deprecate the gmake module... but as with all these things.. time and effort...

[realvictorprm]

Thanks for the clarification, we may add more documentation online here then.

[samsinsane]

Closing this as the issue was resolved by using gmake2.