Added support for Objective-C and Objective-C++ in xcode and gmake2

[samsinsane]

• Added unit tests for Objective-C and Objective-C++
• Resolves Consider adding ObjectiveC flag #845
• Resolves Xcode has special behavior for disallowed languages #1085

[ratzlaff]

I remember seeing this language file config back when I was making compileas work (.c compiled as .cpp). I dismissed it as stale since I did not find any other references to 'language' as a file configuration parameter outside the xcode module and figured it was leftover cruft from the transition from premake-xcode to premake-core.

This seems like it is doing the same kind of deal as my PR, just with .cpp compiled as .mm. Is 'language' the preferred keyword (over 'compileas') for doing this kind of configuration? I am only asking in case I need to update my PR, which I will happily do.

[samsinsane]

I'm more than happy to change it to use compileas, I think compileas makes more sense. I found two places that used language and only one that used compileas, I wasn't sure why a new API was created and figured sticking to the "majority" was better. Again, I think compileas makes more sense, so I would actually prefer to use it over language. "Compile these files as X" makes more sense than "These files are this language".

[mihaisebea]

@samsinsane I would say that compileas is redundant (maybe it should be just an alias for language?) Ideally we shouldn't have two ways of doing the same thing as it's confusing.

[samsinsane]

There's been a few other discussions around language and it seems like it might be phased out. I believe that compileas is definitely the correct API to use for this particular PR. A file with the extension cpp is still a C++ file, but we're instructing the IDE/compiler/tool to treat it like a C, Objective-C or Objective-C++ file. I feel that using language instead of compileas would make it kind of confusing to read the Premake scripts, it would appear more like a typo than an intentional action.

I'm not sure when I'll get a chance to update this PR, but if there aren't any objections to using compileas I'll update it to use that instead.

[starkos]

It looks like we were waiting for some follow-up changes on this one; @samsinsane any interest in finishing this one up? I agree that compileras() is a better way forward than language().

[samsinsane]

@starkos unfortunately I won't be able to test it properly as I don't get a chance to work on a Mac very often. It might be better for someone else to pick it up? Or I can pick it back up when I get a chance to work on a Mac again.

[ratzlaff]

We are getting our macs here refreshed so I may be able to test this out

[starkos]

@samsinsane - How would you like to proceed with this? I'm inclined to rebase it and merge as is, but I'm not set up to test the resulting builds. What say you?

If you're against merging it, I'd like to close it as stale. It is linked to the related issues so it wouldn't be hard to resurrect if someone finds the need.

[samsinsane]

@starkos I updated the PR to use compileas instead of language, however, I still wasn't able to try to use it on a mac. I'm happy for this to be merged as-is if it helps people out.

[starkos]

I'm working up to a new release. Since we can't test this thoroughly ourselves let's hold off until the release branch is cut, and then I'll approve it.

[starkos]

Changed my mind; there will time enough to review before the release actually gets cut. Merged.