Add C11 flag support for GCC

[vlad-ivanov-name]

Fixes #642

[samsinsane]

I can't really see any reason not to merge this after we merged the other C flags. Would be good to one day have an API instead, like we've done for other flags.

[starkos]

It would be great to get these moved to an API. Flags are bad enough, but multiple flags that compete with each other are the worst.

[tvandijck]

Let's merge this right now, and I'll have a look this month (now that I'm back from vacation) at moving these things into a proper API..

[TurkeyMan]

What happened to the discussion about using existing language API to support dialects?

language "C"
language "C11"
language "C++"
language "C++14"

Etc... ?

(I was actually against this at one point... but I thought it was more-or-less agreed at that time?)

[samsinsane]

I don't recall seeing this, may have been before my time, but I do recall seeing this for the toolset API. gcc5.0, clang3.5, etc, is this what you're thinking of?

[starkos]

I can't find the original discussion. The idea was to merge the language and the standard variant into one token, e.g. language "C++14". A few people were against the idea, though I don't recall the exact reasons. I was in favor, since I felt the two were intrinsically connected, e.g. this makes no sense: language "D"; standard "C++14".

As far as I know, no work has been done it so far.

[TurkeyMan]

@samsinsane It was well before your time ;)

[samsinsane]

@TurkeyMan Ahh, the curses of youth. :P

@starkos On the other hand, language "C++"; standard "gnu++14" does make sense, but language "GNU++14"/language "C++GNU++14" wouldn't really. Well, they don't seem to make sense to me, but you might feel differently? :) I imagine this is where the disagreement would come from though.

[starkos]

GNU++14 is a C++ language standard, so I would expect language "gnu++14" to imply C++.

[tvandijck]

I'm kind of in favor of the "language" modification... but it's a lot harder to keep that backwards compatible with the current flags.

[tvandijck]

	api.register {
		name = "language",
		scope = "project",
		kind = "string",
		allowed = {
			"C",
			"C++",
			"C#",
		},
	}

this is a problem..... that will have to move to the config scope, if we go that route...
Because it will become config specific, and in some cases you'd want to specify the language on a per file basis too... the project scope does not allow that.

project 'a'
    language 'gnu++14'

for example... what is the visual studio backend going to do with that?
so we'd have to write:

project 'a'
    filter { 'toolset:gcc' } 
         language 'gnu++14'
    filter { 'toolset:msc' } 
         language 'c++'

or something like that.
To be honest, the 'language' keyword is going to be extremely hard to modify to include this.

Adding a 'standard' or 'languagestandard' keyword is going to be a lot easier. What is indeed somewhat strange is that that could lead to language 'd', standard 'c++14', which makes no sense..
So I'm proposing to do the following:

	api.register {
		name = "languagestandard",
		scope = "config",
		kind = "string",
                dependencies = { 'language' },
		allowed = function(cfg)
...
                       if (p.project.iscpp(cfg.project) then
                            return { "c++02", "c++11", "c++14" }
                        end
...
                end
		},
	}

that would allow us to validate it based on prior settings...
I added the dependencies field so we can add code to make sure language is set before languagestandard gets called...

all this however, adds quite a bit of complexity to premake as a whole... Although I have in the past ran into similar requirements, so it would be a welcome addition.

[starkos]

Only a little time here, but...

this is a problem..... that will have to move to the config scope, if we go that route...

Agreed. You can already specify a mix of C and C++ files within a project.

what is the visual studio backend going to do with that?

Our choice. It can silently fall back to generic C++, raise a warning and fallback to C++, or error. For the sake of this discussion, the problem exists with both approaches (i.e. what would VS do with languagestandard "gnu++14"? Presumably the same thing it would do with language "gnu++14").

So I'm proposing to do the following

There is no way to get a meaningful value for project.iscpp() until after baking is complete. Even if you had a way to fetch the value at the time of the languagestandard() call, it could end up being changed later in the script.

[tvandijck]

There is no way to get a meaningful value for project.iscpp() until after baking is complete.

good point indeed... although at the same time... if I move it to a config scope, it won't ever have a meaning full value... since it is no longer a single value for the project. While it makes no sense from a usefulness point of view, this would now be legal premake:

filter { "debug" }
   language "C++11" 
   files { '*.cpp' }
filter { "release" }
   language "C#"
   files { '*.cs' }

so what is this code going to do now?

		if premake.project.isdotnet(prj) then
			premake.generate(prj, ".csproj", vstudio.cs2005.generate)
		elseif premake.project.iscpp(prj) then
			premake.generate(prj, ".vcproj", vstudio.vc200x.generate)

We need some form of validation that the input is sensible..

[starkos]

We need some form of validation that the input is sensible..

Maybe something like this? :)

[tvandijck]

yeah, exactly like that ;) I'll experiment a little with that this week then...
seems like a pretty big change, and not easy to keep backwards compatible...

[starkos]

It might not be that bad. I would deprecate the flags, but not try to translate them to the equivalent language. Instead, just test for both language and flag everywhere they are used. So in our GNU configmap, for instance, you might have (very off the top of my head, untested):

flags {
   ["gnu++14"] = "--gnu++14"
},
language {
  ["gnu++14"] = "--gnu++14"
}

Probably will also want a table to map these to generic values for iscppproject(), etc.

languageMap = {
  ["gnu++14"] = "c++"
}

[tvandijck]

I gave this a shot here
#686