Refactor language flags to go through the language API. #686

tvandijck · 2017-01-31T20:11:14Z

So you can use 'language "C++11"' instead of 'flags { "C++11" }'

samsinsane · 2017-02-01T01:27:28Z

modules/codelite/codelite_project.lua

@@ -366,7 +366,10 @@
 	end

 	function m.completion(cfg)
-		_p(3, '<Completion EnableCpp11="%s" EnableCpp14="%s">', iif(cfg.flags["C++11"], "yes", "no"), iif(cfg.flags["C++14"], "yes", "no"))
+		local cpp11 = (cfg.language == 'gnu++11') or (cfg.language == 'C++11') or cfg.flags["C++11"]


This should probably be a function, to allow others to add other language extensions like GNU++11. For example, VS2015 Update 3 (probably VS2017 too) allows you to specify "C++Latest", we should have support for this to translate to C++17. When C++20 starts happening, it will need to map to that, and changing it everywhere is going to be time consuming.

samsinsane · 2017-02-01T01:31:53Z

modules/xcode/xcode_common.lua

-		settings['GCC_C_LANGUAGE_STANDARD'] = 'gnu99'
+		if (p.languages.isc(cfg.language)) then
+			if cfg.language ~= "C" then
+				settings['GCC_C_LANGUAGE_STANDARD'] = cfg.language:lower()


Based on previous comment, this will need to handle things like "C++Latest" (but a C equivalent), so it's probably best this entire block for adding GCC_C_LANGUAGE_STANDARD be a function instead, same for the C++ block.

samsinsane · 2017-02-01T01:33:02Z

src/_premake_init.lua

+	api.deprecateValue("flags", "C++14", 'Use `language "C++14"` instead', function(value) end, function(value) end)
+	api.deprecateValue("flags", "C90",   'Use `language "C90"` instead',   function(value) end, function(value) end)
+	api.deprecateValue("flags", "C99",   'Use `language "C99"` instead',   function(value) end, function(value) end)
+	api.deprecateValue("flags", "C11",   'Use `language "C11"` instead',   function(value) end, function(value) end)


Shouldn't these all set the language?

@starkos suggested we don't do that in his last comment on this thread: #659

We could though, I don't think with the changes I made it would break anything.

Agreed, shouldn't break anything. Just thought it would be easier to handle both the language and the flags at the point of application, which you did.

I think the suggestion was ultimately the correct one:

api.deprecateValue("flags", "C++11", 'Use `language "C++11"` instead', function(value) language "C++11" end, function(value) <what to do here> ??? end)

I've tried a few things,

removelanguage "C++11" or language "C++"

but they all break...

Add a Default value to language? I'm picturing a situation like this:

project "NiceProject" language "C++14" files { "**.h", "**.c" } filter { "files:RealCFiles/**.c" } language "Default"

Would the language value flow down regardless of extension? Assuming it would, the above might be desired functionality?

Ah that's right, forgot about that part. We need the ability to set the language (or standard, or whatever) for each "dialect".

clanguage "C99" cpplanguage "C++14"

We can still have the generic language, which is used if a more specific value hasn't been set. And of course this needs to extend to any supported language:

dlanguage "SafeD"

So yeah…there's that. Not sure if there is a more elegant/transparent way to express this?

You could just do:

language "C++14" filter { "files:*.c" } language "C99"

but that said, if we went the "dialect" route, I would certainly prefer to actually use that name.
So either:

dialect { cpp = "C++14" c = "C90", d = "D3.4", -- if such a thing was a thing. }

or as suggested:

cdialect 'C90' cppdialect 'C++14' ddialect 'D3.4"

I'm somewhat indifferent to the approach, I think both have merit..

You guys want me to prototype that instead??

You could just do:

language "C++14" filter { "files:*.c" } language "C99"

You're quite right, I was overthinking. It is really only an issue in multi-language (or dialect) projects, and this suggestion is the right way to go.

tvandijck · 2017-02-09T19:00:47Z

Can we merge this? or is there more work left?

samsinsane · 2017-02-10T03:31:47Z

@tvandijck There's a few places where you remove checks for iscpp, these should probably stay. In some cases, there's more code in the function and by removing the check you're causing module developers to copy code from core. vs2010.generateProject is a good example of this, the D module will end up generating a .vcxproj and .visualdproj if you select any VS action for a D project.

tvandijck · 2017-02-10T17:13:18Z

by removing the check you're causing module developers to copy code from core.

not sure I understand this...

the D module will end up generating a .vcxproj and .visualdproj if you select any VS action for a D project.

I see that one, but the check was wrong... vcxproj is for both C and C++ projects.
I guess I can add a check to check for either.. I'm just wondering where this is needed exactly.

In that same boat, I then also think the "project.isnative" method is confusing, because there really isn't such a thing...

samsinsane · 2017-02-13T03:59:43Z

Well, ideally, we'd change the functions so that generic and specific code don't exist in the same function. Maybe for now, the best move would be to check for C and C++ and then, eventually, we can move the generic code out. Thoughts?

neico · 2017-03-06T04:56:05Z

While you're at it, add the new switches for Visual Studio as well?
See: https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switches-in-the-compiler/

["C++"] = "/std:c++latest",
["C++14"] = "/std:c++14"

imo it's a horrible thing that MS did there, especially since "some" of the standards aren't locked behind the switches, I really hope they'll sort this out in the future and maybe add switches for the older standards as well...

/permissive- will also need a place somewhere, but I'm not sure where that'd be (see https://blogs.msdn.microsoft.com/vcblog/2016/11/16/permissive-switch/)

tvandijck · 2017-04-06T19:05:59Z

@samsinsane what changes do we still need here? other then what @neico suggests to add?

samsinsane

I have this feeling that this will break at least one of my modules, but I'm not sure which one or where, and I'm just not that bothered to find out exactly how. Something else has probably already broken them, so let's move forward and I'll submit a PR if something needs to be fixed.

So you can use 'language "C++11"' instead of 'flags { "C++11" }'

tvandijck · 2017-04-11T19:45:25Z

I rebased this, and made some more modifications to solve some of the comments @samsinsane made about me removing some of the required "iscpp" calls... I think I got them all correct now, but please review.

tvandijck · 2017-04-11T19:49:06Z

@neico this commit just modifies the flag/api.... I've not actually implemented usage of it inside of the Visual Studio action at all... Feel free to submit further PR's on top of this change for that once this is merged (or even against this PR).

samsinsane · 2017-04-12T05:38:42Z

modules/xcode/xcode_common.lua

+				end
+			end
+		else
+			settings['GCC_C_LANGUAGE_STANDARD'] = 'gnu99'


Should this map to one of the C11 standards when the language is C++17? I believe C++17 is based on C11, rather than C99, or is it the plan for the next C++ standard to be on C11?

samsinsane · 2017-04-12T05:43:37Z

src/actions/vstudio/vs2005.lua

@@ -51,16 +51,14 @@
 			if #user > 0 then
 				p.generate(prj, ".csproj.user", function() p.outln(user) end)
 			end
-
-		elseif premake.project.iscpp(prj) then
+		else


Technically, this should probably have the check for C/C++, but I'm happy to ignore this since it's for VS2005 and VS2008, and VS2008 will be EOL in a little under a year.

starkos · 2017-04-12T18:37:50Z

Are we good to merge? I think it looks pretty good, major props to @tvandijck for putting it together!

ghost · 2017-04-13T11:42:45Z

Looks like the line endings in src/actions/vstudio/vs2010_vcxproj.lua have changed, so I'm getting a huge merge conflict with #734. I feel like we should revert this and fix the line endings here.

samsinsane · 2017-04-13T11:48:28Z

~~I've noticed that line ending issue, I'm fairly certain it was already in master from somewhere else.~~ My apologies, I was talking about the line ending issue that existed prior to these changes. Technically, this PR is actually fixing the line endings, they were actually broken in #732. For some weird reason git won't show that anything changed, even though I'm looking at a diff between 4670158 and f3dae94 and it couldn't be more obvious that the line endings are different.

ghost · 2017-04-14T10:58:37Z

I fixed this in my branch by running git rebase master -s recursive -X ignore-space-change and then manually fixing up line endings in every commit that touches src/actions/vstudio/vs2010_vcxproj.lua.

I think git provides facilities to automatically normalize line endings on push with a .gitattributes file, so we might want to look into that at some point.

neico · 2017-04-14T18:35:27Z

@aleksijuvani .gitattributes and .editorconfig together can avoid any of those.

if you throw in .clang-format you get even actual style guidelines enforced.

So yeah, imo any git project should at least use the first 2 mentioned files.

tvandijck mentioned this pull request Jan 31, 2017

Add C11 flag support for GCC #659

Merged

samsinsane reviewed Feb 1, 2017

View reviewed changes

tvandijck force-pushed the language-api branch from 48377b0 to d1bf9be Compare February 1, 2017 17:30

samsinsane approved these changes Apr 7, 2017

View reviewed changes

Refactor language flags to go through the language API.

d285fa6

So you can use 'language "C++11"' instead of 'flags { "C++11" }'

tvandijck force-pushed the language-api branch from b44feab to d285fa6 Compare April 11, 2017 19:44

samsinsane approved these changes Apr 12, 2017

View reviewed changes

starkos approved these changes Apr 12, 2017

View reviewed changes

samsinsane merged commit 9572876 into premake:master Apr 13, 2017

neico mentioned this pull request Apr 22, 2017

"Unsupported language 'C++11'" on Windows and Linux #750

Closed

tvandijck deleted the language-api branch April 24, 2017 21:04

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor language flags to go through the language API. #686

Refactor language flags to go through the language API. #686

tvandijck commented Jan 31, 2017

samsinsane Feb 1, 2017

samsinsane Feb 1, 2017

samsinsane Feb 1, 2017

tvandijck Feb 1, 2017

starkos Feb 1, 2017

tvandijck Feb 1, 2017

samsinsane Feb 2, 2017

starkos Feb 2, 2017 •

edited

Loading

tvandijck Feb 3, 2017

starkos Feb 3, 2017

tvandijck commented Feb 9, 2017

samsinsane commented Feb 10, 2017

tvandijck commented Feb 10, 2017

samsinsane commented Feb 13, 2017

neico commented Mar 6, 2017 •

edited

Loading

tvandijck commented Apr 6, 2017

samsinsane left a comment

tvandijck commented Apr 11, 2017

tvandijck commented Apr 11, 2017

samsinsane Apr 12, 2017

samsinsane Apr 12, 2017

starkos commented Apr 12, 2017

ghost commented Apr 13, 2017

samsinsane commented Apr 13, 2017 •

edited

Loading

ghost commented Apr 14, 2017

neico commented Apr 14, 2017 •

edited

Loading

Refactor language flags to go through the language API. #686

Refactor language flags to go through the language API. #686

Conversation

tvandijck commented Jan 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

starkos Feb 2, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tvandijck commented Feb 9, 2017

samsinsane commented Feb 10, 2017

tvandijck commented Feb 10, 2017

samsinsane commented Feb 13, 2017

neico commented Mar 6, 2017 • edited Loading

tvandijck commented Apr 6, 2017

samsinsane left a comment

Choose a reason for hiding this comment

tvandijck commented Apr 11, 2017

tvandijck commented Apr 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

starkos commented Apr 12, 2017

ghost commented Apr 13, 2017

samsinsane commented Apr 13, 2017 • edited Loading

ghost commented Apr 14, 2017

neico commented Apr 14, 2017 • edited Loading

starkos Feb 2, 2017 •

edited

Loading

neico commented Mar 6, 2017 •

edited

Loading

samsinsane commented Apr 13, 2017 •

edited

Loading

neico commented Apr 14, 2017 •

edited

Loading