Visual Studio 2015, Android projects generator

[StiX]

I've started to work on a module, that can create VS 2015 Android projects. At the moment the module can create NDK project - only static and shared libs, no packaging projects at the moment (I hope to add it during the upcoming days).

Everything that I've tested so far work as expected.

I'd like to get some feedback from the community - would be awesome, if someone could review the code.

Module itself can be found at https://github.com/akaStiX/premake-vsandroid.git

[Damien Courtois]

Great ! I was planning to start something like this, so now I won't have to ^^
I will wait until the packaging part is done to test it, because this is the part that I need the most.
As for a code review, apart from commented codes, it seemed fine (although I don't know why you have a "vsandroid.lua" file almost empty, which just basically include the "vsandroid_vcxproj.lua" file ?)

[StiX]

I am using the packaging project, that is generated for default sample app, works like a charm :)

So you can start porting your code for this module.

[StiX]

I totally forgot.

I've discovered a bunch of issues related to Android builds inside VS. They can be found here: https://drive.google.com/open?id=1z0sMIcMcBju6TSQstWgeOy-p1GFTxvuQN1DMvyVgdtk

TL;TR, the summary:

MSBuild has no support for linker groups ATM - this was already reported to MS

[Manu Evans]

Interesting. Is there a reason not to start from here: https://github.com/TurkeyMan/premake-android ?

Looks good. I have been meaning to update mine. I have some bits yours is missing. These could probably be merged into a more complete solution.

[StiX]

I've used your module as an example :)

The reason, why I've created different module is that you create projects for this https://github.com/gavinpugh/vs-android and I create projects for MSBuild (VS2015 has built-in support for Android) and this projects are very different.

>I have some bits yours is missing.

Yes. This features are not available in VS2015 ATM or they are hidden in MSBuild (I do not expose hidden properties ATM). I've reported a lot of things to MS, so I hope they will add missing functionality in upcoming VS updates

[StiX]

The packaging part is done. However some things are still missing - like debugger settings (native or Java) and generation of project filter.
Otherwise I was able to generate, build and debug my personal project with help of this module.
P.S. It still misses the documentation, I plan to add it as soon as possible, but if you want to start without it, you can check _preload.lua for reference

[Sam Surtees]

I didn't realise you were working on a module, I've actually opened a PR for Manu's module that adds basic VS2015 support. I'm not sure if you want to merge your stuff in once my PR is accepted but it'd be good if you could, it's far better having a single module that supports everything Android than several modules with different APIs that make it difficult to use together.

[StiX]

This modules are totally incompatible. It's like merging vs2008 and vs2015 modules together.

[Sam Surtees]

Can you elaborate on how they're incompatible? I've added Microsoft's implementation to Manu's module, so I fail to see what's incompatible.

Also, the VS2008, VS2015 and all other VS generators are in the same repository, premake-core, which is exactly what I'm suggesting we do here. The end user shouldn't need to get another module to migrate from one action to another. If the end user is running VS2013 and are upgrading to VS2015, having these modules separated is going to cause work for them, if they're merged into a single module, they don't have to do anything as all the APIs are the same. Similarly, if the end user wants to migrate from Windows to OSX/Linux, the module should have support for tools on those systems (there's a new fork of Manu's module that is adding make support). In my opinion, users are more likely to use Manu's module as it will support a wider range of build tools and allows them to jump to another build tool without worrying about their premake files.

[starkos]

FYI, since I haven't mentioned it lately: rather than merging more modules into core, I'd really like to begin building out the new HTTP/zip support into a proper module system and start making it easier for people to share, find, and install modules. That doesn't mean that we *can't* add modules to core, but I don't want that to be the default approach, since it increases the maintenance workload. I think it would be better for the core developers to focus on building out the core (when we can get free again).