[gmake2] Add specific support for std library

[diamante0018]

Currently, on Linux, if I want to steer off from my system's default "libstdc++" and specify a different standard library implementation (often a must when using a compiler that isn't GCC to prevent compilation errors due to the compiler not being able to compile with libstdc++) I must do the following:

buildoptions "-stdlib=libc++"
linkoptions "-stdlib=libc++"

Because in my actual project I will be using clang, this will tell the compiler and linker to use the std library from the llvm-project itself which will have optimal compatibility with the compiler. I found there are no shorter or other premake settings for achieving a similar result so it must be done manually via buildoptions and linkoptions

What problem will this solve?
The goal of this feature request is to have shorter Premake5 config files via specific premake5 config options that will convert the verbose buildoptions and linkoptions to one shorter setting.

What might be a solution?
A solution that could be ideal would be one option that supports either a predefined list of the most popular std libraries or any input it receives. For example:

Premake5.lua

library="libc++"

This setting will convert the input to the required build and link option without the user having to spend too much time on the task.
I lost a good amount of minutes because my project failed to link only to learn I was missing the "link option".

What other alternatives have you already considered?
There are no solutions apart from using the most basic build and link option settings

Anything else we should know?
This should only be an issue to tackle on gmake2 for Linux systems, I don't think on macos such a problem would ever arise but I personally do not know since I am not a macos user.
This would not be an uncommon Premake5 setting as there are many other Premake5 settings that convert simple inputs to trivial settings in the final makefile.

The simplest I can think of is the "symbols" Premake5 settings which depending on the input might only add an "-S" to the final build options.

[Jarod42]

That option is clang specific (I don't know if it requires special handling for "msvc-clang" though), so:

filter {"toolset:clang*"}
  buildoptions "-stdlib=libc++"
  linkoptions "-stdlib=libc++"
filter {} -- reset filter

[diamante0018]

I kind of overlooked that detail and it makes me think whenever this issue should be pursued or not.
I probably imagined GCC supported other std libraries but I was wrong.
I will have indeed those statements surrounded by the toolset filter.

[diamante0018]

I solved my issue here using your advice, only thing is I had to set -cc=clang from the command line so I don't have to hardcore "toolset clang" in the Premake5.lua itself, just in case someone (or myself) ends up having to compile my repo on some other machine with just GCC. So it may not be the best solution, but it seems to work fine for now.
Did not find any docs for -cc only a past issue on this repo though, maybe I missed them?

[Jarod42]

premake5 --help lists that option (but it doesn't list that you might add toolset version as available value so --cc=clang-14 should work too (with recent version of premake)).

[Peter0x44]

@diamante0018 GCC is claimed to support libc++ here:
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-stdlib
But it does say:
When G++ is configured to support this option
When I tried (arch linux, gcc 13.2) I was getting an error:
g++: error: unrecognized command-line option ‘-stdlib=libc++’
So maybe it's not common to configure gcc to support that, not sure. Perhaps it's something wrong with the arch gcc package.

[diamante0018]

Yeah, I understand that I'm asking really for something that may or may not be supported by one maybe two compilers and to save typing out two "long" premake5 directives vs one that is "short" (the short being what this feature is about).

At least with the help of various people here I was able to cleanup my premake5 file using the latest release by a lot and it is no longer hard coded to user either clang, libcxx or the lld linker which is a huge thing if my goal was to make my code as easy to share as possible

[Peter0x44]

I had some discussions on the gcc irc channels about -stdlib. Its reason for existing is compatibility with macos, and it requires to be enabled specifically with a configure option.

jwakely: Peter0x44: yeah like sam said, the -stdlib= option is enabled/disabled at configure time, via the --with-gxx-libcxx-include-dir option
jwakely: if you don't configure with a libc++ path, then the option isn't available
jwakely: for most linux distros it makes no sense to use it, because the libc++ version (and so the libc++ path) changes independently of the gcc version
jwakely: so you'd need to rebuild gcc every time you update llvm in the distro
jwakely: most distros don't want that coupling

Clang has the same trouble with libstdc++, but it queries gcc for its version to locate the relevant libraries for libstdc++.

So at the very least, this option wouldn't work correctly, with gcc as-is, until someone makes gcc query clang for its version to know how to locate libc++. The current dysfunction is primarily due to a lack of interest.

[Peter0x44]

I think this is generally outside of what premake can or should manage, and there is no really standard option for managing this, yet. Premake won't be able to do anything without upstream caring more about this point (for gcc, anyway).