Premake configurations with spaces does not follow Premake standard

[perseoGI]

Greetings from the Conan.io team.
We are trying to add this library to the Conan Center Index, here is the Pull Request.

Currently, we do not have the possibility in our PremakeToolchain to target other configurations but Release or Debug. I'm working on it.
But I found when testing that this project contains configurations with white spaces inside:

wxsqlite3/premake5.lua

Line 12 in 7c34be9

configurations { "Debug", "Release", "Debug wxDLL", "Release wxDLL", "Debug DLL", "Release DLL" }

If you check out Premake documentation, you won't find any configuration with spaces in between.

This is not a problem in Windows machines as Visual Studio generator will manage it.
But if there is any plan on adding premake support on OSX/Linx, notice that Make will crash when a space is found in the configuration name.

Example of makefile generated code in macos:

ifeq ($(config),debug_dll)
OBJDIR = obj/Debug DLL/foo

Sadly, Makefile will create two folders, obj/Debug and DLL/foo, and not obj/Debug DLL/foo, so this will result in a compilation crash.

Perhaps I should move this issue to the Premake core itself, but it would be nice if you could consider this behavior and possibly update the naming of the configurations.

Thank you in advance! 🐸

[utelle]

Greetings from the Conan.io team. We are trying to add this library to the Conan Center Index, here is the Pull Request.

I'm aware of that due to issue #128 opened by @uilianries.

Currently, we do not have the possibility in our PremakeToolchain to target other configurations but Release or Debug. I'm working on it.

The build files of wxSQLite3 contain 3 variations per Release resp Debug configuration:

• Release / Debug : wxSQlite3 and wxWidgets as static libraries
• Release DLL / Debug DLL : wxSQlite3 and wxWidgets as shared libraries
• Release wxDLL / Debug wxDLL : wxSQlite3 as static library and wxWidgets as shared libraries

But I found when testing that this project contains configurations with white spaces inside:

wxsqlite3/premake5.lua

Line 12 in 7c34be9
configurations { "Debug", "Release", "Debug wxDLL", "Release wxDLL", "Debug DLL", "Release DLL" }

If you check out Premake documentation, you won't find any configuration with spaces in between.

That's true, but also true is that it is nowhere stated that names with spaces are prohibited. IMHO it is a flaw in the gmake generator of premake.

This is not a problem in Windows machines as Visual Studio generator will manage it. But if there is any plan on adding premake support on OSX/Linx, notice that Make will crash when a space is found in the configuration name.

I know that, because I had to learn it the hard way a long time ago.

Therefore my premake script (in file premake/wxwidgets.lua) contains the following code to fix the problem:

premake.override(premake.modules.gmake, "target", function(base, cfg, toolset)
  local targetpath = string.gsub(premake.project.getrelative(cfg.project, cfg.buildtarget.directory), ' ', '_')
  premake.outln('TARGETDIR = ' .. targetpath)
  premake.outln('TARGET = $(TARGETDIR)/' .. cfg.buildtarget.name)
end)
  
premake.override(premake.modules.gmake, "objdir", function(base, cfg, toolset)
  local objpath = string.gsub(premake.project.getrelative(cfg.project, cfg.objdir), ' ', '_')
  premake.outln('OBJDIR = ' .. objpath)
end)

Spaces in directory names are replaced by underscores. Works flawlessly.

Example of makefile generated code in macos:

ifeq ($(config),debug_dll)
OBJDIR = obj/Debug DLL/foo

Sadly, Makefile will create two folders, obj/Debug and DLL/foo, and not obj/Debug DLL/foo, so this will result in a compilation crash.

That will not happen, if you adopt the premake code shown above.

Perhaps I should move this issue to the Premake core itself,

Yes, it should be fixed in premake itself - either by quoting paths properly or by replacing spaces by underscores (as I did).

but it would be nice if you could consider this behavior and possibly update the naming of the configurations.

Renaming the configurations would mitigate the problem, but not really solve it. For example, if someone specifies a target directory with spaces in its name, the build process would still crash.

[utelle]

BTW, premake explicitly allows spaces in configuration names (see premake docs):

names is a list of configuration names. Spaces are allowed, but may make using certain Premake features, such as a command-line configuration selection, more difficult.

That is, the problem should be addressed in premake itself resp in the gmake generator.

[perseoGI]

Thank you very much for your quick and detailed response!

This looks promising. I've tested locally in another project, and this code fixes the issue. Thank you very much for sharing your solution.

premake.override(premake.modules.gmake, "target", function(base, cfg, toolset)
  local targetpath = string.gsub(premake.project.getrelative(cfg.project, cfg.buildtarget.directory), ' ', '_')
  premake.outln('TARGETDIR = ' .. targetpath)
  premake.outln('TARGET = $(TARGETDIR)/' .. cfg.buildtarget.name)
end)
  
premake.override(premake.modules.gmake, "objdir", function(base, cfg, toolset)
  local objpath = string.gsub(premake.project.getrelative(cfg.project, cfg.objdir), ' ', '_')
  premake.outln('OBJDIR = ' .. objpath)
end)

I guess our Premake Toolchain could inject this code but I dont think that would be correct as it may override users custom code...

That is, the problem should be addressed in premake itself resp in the gmake generator.

Definitely, yes. Are you up to opening a ticket to Premake Core in order to fix this? I see you are far more familiar with Premake than I.

[utelle]

This looks promising. I've tested locally in another project, and this code fixes the issue. Thank you very much for sharing your solution.

You are welcome.

I guess our Premake Toolchain could inject this code but I dont think that would be correct as it may override users custom code...

You are probably right. Especially, because my workaround is not fully generic.

That is, the problem should be addressed in premake itself resp in the gmake generator.

Definitely, yes. Are you up to opening a ticket to Premake Core in order to fix this? I see you are far more familiar with Premake than I.

There already exists a ticket: premake/premake-core#2426. And a related PR: premake/premake-core#2433. However, the PR is open since Feb 2025.

It is known that GNUMake has problems in handling paths with spaces. Therefore avoiding spaces in path names is probably the best approach.

[uilianries]

@utelle Hello! 👋 I just want to thank you for your very detailed comment and support!