Premake doesn't set CC variable when generating gsys2 project files (Win10)

[SteelPh0enix]

What seems to be the problem? Premake doesn't set the CC variable with gmake and gmake2 generator when trying to build a C project

What did you expect to happen? I expected that i'll be able to build a simple Hello World with barebones premake copied from "Getting Started" guide.

What have you tried so far? I've managed to build the program after adding CC = gcc directly into generated *.make file.

How can we reproduce this?

• Create a simple *.c file
• Copy the premake5.lua example from https://premake.github.io/docs/Your-First-Script and put it alongside the *.c file
• premake5 gmake2
• mingw32-make
• get the error below:

  PS C:\Users\SteelPh0enixVM\C> mingw32-make
  "==== Building HelloWorld (debug) ===="
  Creating obj/Debug
  main.c
  process_begin: CreateProcess(NULL, cc -MMD -MP -g -o obj/Debug/main.o -MF obj/Debug/main.d -c main.c, ...) failed.
  make (e=2): The system cannot find the file specified.
  mingw32-make[1]: *** [HelloWorld.make:132: obj/Debug/main.o] Error 2
  mingw32-make: *** [Makefile:30: HelloWorld] Error 2

This issue happens when you either

• have language set to C in premake5.lua - fails on build due to lack of CC variable content
• try to build a C file in C++ project - same as above
• try to link the project with language set to C - fails on linking, because it's trying to use CC for final compilation step

What version of Premake are you using? premake5 (Premake Build Script Generator) 5.0.0-alpha16

Anything else we should know? I've tested it on my personal PC and in a clean virtual machine (both machines have latest Windows 10, MinGW-w64 (x86_64, 8.1.0 and latest Premake). I was able to reproduce the issue on both machines.

[SteelPh0enix]

Update: i've checked if issue happens on Linux too, but on latest ZorinOS everything seems to be working fine.

[samsinsane]

This looks to be a duplicate of #266?

[nickclark2016]

So I've had the chance to dig into this. I think it's an easy fix. This is what we currently do to get a tool:

function gcc.gettoolname(cfg, tool)
    if (cfg.gccprefix and gcc.tools[tool]) or tool == "rc" then
        return (cfg.gccprefix or "") .. gcc.tools[tool]
    end
    return nil
end

What I propose is that we change it to this:

function gcc.gettoolname(cfg, tool)
    local value = gcc.tools[tool]
    if type(value) == "function" then
        value = value(cfg)
    end
    return (cfg.gccprefix or "") .. value
end

This brings the gcc toolchain to work how the clang toolchain's gettoolname function works. So what does this mean? This means that we will always print the following block on windows when the toolchain "gcc" is specified:

  ifeq ($(origin CC), default)
    CC = gcc
  endif
  ifeq ($(origin CXX), default)
    CXX = g++
  endif
  ifeq ($(origin AR), default)
    AR = ar
  endif
  RESCOMP = windres

@samsinsane @starkos If this is desired behavior, I have this code and corresponding unit tests written up and can put in a PR.

[starkos]

This looks reasonable to me—thanks for looking into it!

[nickclark2016]

Sounds good. Let me go ahead an put in the PR

[nickclark2016]

Wow, did I never put in a PR for this? I'll add this to the top of my todo list for v5.

[SteelPh0enix]

hi, is this fixed already? I've noticed that this issue is still open