{"action":"created","issue":{"url":"https://api.github.com/repos/premake/premake-core/issues/102","labels_url":"https://api.github.com/repos/premake/premake-core/issues/102/labels{/name}","comments_url":"https://api.github.com/repos/premake/premake-core/issues/102/comments","events_url":"https://api.github.com/repos/premake/premake-core/issues/102/events","html_url":"https://github.com/premake/premake-core/pull/102","id":86267206,"number":102,"title":"add new exceptionhandling and rtti API's, deprecate the corresponding flags.","user":{"login":"tvandijck","id":451515,"avatar_url":"https://avatars.githubusercontent.com/u/451515?v=3","gravatar_id":"","url":"https://api.github.com/users/tvandijck","html_url":"https://github.com/tvandijck","followers_url":"https://api.github.com/users/tvandijck/followers","following_url":"https://api.github.com/users/tvandijck/following{/other_user}","gists_url":"https://api.github.com/users/tvandijck/gists{/gist_id}","starred_url":"https://api.github.com/users/tvandijck/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tvandijck/subscriptions","organizations_url":"https://api.github.com/users/tvandijck/orgs","repos_url":"https://api.github.com/users/tvandijck/repos","events_url":"https://api.github.com/users/tvandijck/events{/privacy}","received_events_url":"https://api.github.com/users/tvandijck/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":13,"created_at":"2015-06-08T17:35:53Z","updated_at":"2015-06-15T11:30:14Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/premake/premake-core/pulls/102","html_url":"https://github.com/premake/premake-core/pull/102","diff_url":"https://github.com/premake/premake-core/pull/102.diff","patch_url":"https://github.com/premake/premake-core/pull/102.patch"},"body":"OK,\r\n\r\nSo with the \"flags\" system, you can set a flags, and later possibly remove it, which reverts the behavior to the \"default\" system behavior... which is not what I want... sometime I want to explicitly turn things ON or OFF, such as with these values..\r\n\r\nI don't want to have an external project having to add a \"removeflags { \"NoExceptions\" }\", because it needs exception handling, just because someone might add the flag. But more importantly, removeflags is just not enough, it only allows me to get the default behavior, which may or may not be exceptionhandling enabled.\r\n\r\nSo internally, we're deprecating ALL flags that have to do with compiler settings, and make proper API out of it...\r\n\r\nThe question in this case is however, should we have \"on\", \"off\" and \"default\" as possible flags, or should it just be \"on\" and \"off\" like what I have in this commit... The downside is pretty obvious to just having \"on\" and \"off\", since it invalidated a bunch of tests which I fixed, but it basically now always outputs these flags into the visual studio project... with \"default\" we could get around that, where \"default\" would mean, don't output anything into the vcxproj. But, if we go that route, I would want the same for \"editandcontinue\"\r\n"},"comment":{"url":"https://api.github.com/repos/premake/premake-core/issues/comments/112025115","html_url":"https://github.com/premake/premake-core/pull/102#issuecomment-112025115","issue_url":"https://api.github.com/repos/premake/premake-core/issues/102","id":112025115,"user":{"login":"TurkeyMan","id":1146706,"avatar_url":"https://avatars.githubusercontent.com/u/1146706?v=3","gravatar_id":"","url":"https://api.github.com/users/TurkeyMan","html_url":"https://github.com/TurkeyMan","followers_url":"https://api.github.com/users/TurkeyMan/followers","following_url":"https://api.github.com/users/TurkeyMan/following{/other_user}","gists_url":"https://api.github.com/users/TurkeyMan/gists{/gist_id}","starred_url":"https://api.github.com/users/TurkeyMan/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TurkeyMan/subscriptions","organizations_url":"https://api.github.com/users/TurkeyMan/orgs","repos_url":"https://api.github.com/users/TurkeyMan/repos","events_url":"https://api.github.com/users/TurkeyMan/events{/privacy}","received_events_url":"https://api.github.com/users/TurkeyMan/received_events","type":"User","site_admin":false},"created_at":"2015-06-15T11:30:14Z","updated_at":"2015-06-15T11:30:14Z","body":"It was a different pair of binary states though. Before it was 'undefined' or 'off'. Now it's 'on' or 'off'... I'm not actually sure it has any effect in terms of project generation, but there is a distinction regardless, and from that perspective, perhaps it would be an improvement to open it to a (preferable?) tri-state situation? I think supporting an 'undefined' state which simply implements the same behaviour that the undefined flag does now (I guess it implies 'on', but it's still not explicit), and adding an explicit on state is closer to the current implementation no?"}}