Any plans for Windows Store app support?
I am looking to mess around with Windows 8 Store apps a bit, but before I dive into trying to get JamPlus to support them, I wanted to see if it was on the roadmap anywhere. There seem to be quite a few pieces to the puzzle, and I have a feeling it will require way more Jam knowledge than I have, so if there's any plans to add it in the near future I might just wait a bit.
I only recently got a machine with Windows 8 support, but I have no projects right now that would have me work on a platform and configurations for that.
Of course, I am very interested in merging in any contributions others might have for this.
Be sure to lead further discussion here, or contact me directly. I can give you an IM address for more real-time chat.
I only recently installed Windows 8 myself, and felt like seeing if I couldn't get a couple things running on it. Nothing of any importance, which is why I quickly gave up on it after beginning down that road. I can't find any documentation from Microsoft that mentions how to go about creating and deploying a Windows Store app without using Visual Studio to create the magical project of the right type. Since it's relatively new, I'm not finding a whole lot of unofficial documentation either. I'm still trying to figure this stuff out myself, so my apologies if any of this ends up wrong, but here's generally what I've found so far in case it saves anyone some headaches in the future (I speak only of C++ here):
1) Compiling with C++/CX requires the /ZW (or /ZW:nostdlib) switch, and that also requires /EHsc. If you try to compile anything from Platform.winmd (using /ZW, /FU, #using, etc.), you will get an internal compiler error. The problem is the paths need to be set properly for finding the WINMD assemblies. To fix that, you either need to use the /AI switch to add the directories or set LIBPATH before you compile. I've had some luck setting LIBPATH to this:
When checking Visual Studio's defaults, there was also a 3rd one listed as some ExtensionLibs path, but it doesn't exist on my machine currently. However, I believe C++/CX is completely optional. From my understanding you can use the WRL components to do everything with a COM interface. So perhaps enabling all this stuff is better suited as an option instead of forcing the /ZW switch upon everyone.
2) All Windows Store apps have this defined: WINAPI_FAMILY=WINAPI_FAMILY_APP, which restricts the Win32 API to what is supported.
3) All Windows Store projects seem to have these lines added to the globals (even static libs). From what I've found online, you can't deploy in a debugger without the AppContainerApplication lines.
<PropertyGroup Label="Globals"> <MinimumVisualStudioVersion>11.0</MinimumVisualStudioVersion> <AppContainerApplication>true</AppContainerApplication> </PropertyGroup>
Initially, I tried to add Windows Store support as just another platform to Visual Studio, so I could target either the desktop or store from the same solution. Because these lines are included in the project (and you can't change it through the Visual Studio UI), I'm not sure that's even supported. Currently for my experiments, I'm generating a different solution when I am working on Windows Store versus Windows Desktop.
4) ARM linker flags use /MACHINE:ARM as you would expect
5) Application projects seem to be linking with a couple new flags, /WINMD /APPCONTAINER and /WINMDFILE:<path>. Couldn't tell you what any of them do right now.
6) Since you can no longer compile shaders at runtime, you are now forced to compile with fxc and package the output files (which they are calling .cso) in the project. Does JamPlus have fxc support? I thought I've seen it, but I might've been looking at rules other people have written.
7) I still haven't figured out the whole process for deployment and packaging. There are 4 required images, a .pfx (key), and .appxmanifest included in the project. Somewhere during the build process a .appxrecipe file is generated. There is some information in this thread:
I can get the C++/CX stuff compiling with the funky entry point "int main(Platform::Array<Platform::String^>^ args)" but it still deploys as a regular desktop app and the option to run in a simulator doesn't appear in Visual Studio (presumably related). I've tried hacking up the project file to include the extra lines, but it didn't change anything. Neither did the extra linker switch for /APPCONTAINER. I've yet to find a "Hello World" for Windows Store I can work with. Everything either has XAML UI stuff everywhere or is using Direct3D, both of which are way more than I'm looking for at the moment. The MSDN "Create your fist Windows Store app using C++" page creates a blog reader.
So that's where I'm at right now. The lack of any documentation made me angry, so I stopped working on it at the moment. When I get the ambition to give it another go, I'll let you know what I come across. Currently, I'm not sure what all the steps to build are, much less how to integrate them into JamPlus properly.
Had a few minutes to look at this again. I have the vcxproj changes and /WINMD and /APPCONTAINER set for linker switches. Some combination of those (not terribly important) is now giving me this warning when trying to debug my app:
"The project 'Foo' cannot be started directly.
In order to debug this project, you must consume it from an application project that creates a package and is marked as a startup project."
That has me a bit worried. Given the vcxproj has a <ConfigurationType> that is set to Makefile/Application/etc., it sounds like the error is saying this can only be debugged using an application project which is setup to do all the packaging and deployment steps.
I looked at two projects I know handle custom building through various makefile systems and are running on Windows 8. One is publicly available (Orge3D), and they seem to have added a regular Visual C++ application project called SampleBrowserWinRT. Although CMake supposedly added support for Windows 8, if you follow the readme they are manually adding the project to the solution.
The other project uses a similar method, there is an app which basically has the entry class (IFrameworkView) and nothing more. It's built entirely separably from the normal project, and the normal project is created as a DLL which handles the callbacks. From my brief glance at Ogre3D, it looks to be taking a similar approach.
Regardless, in order to debug the launcher app project needs to be part of the solution. Does JamPlus support including external/foreign/non-generated projects when generating the solution?
I wanted to see if I could pull this off with JamPlus, even if I needed to do a few manual steps of adding the project to the solution. My plan was to change my current project into a DLL (or static lib, haven't decided yet) and then have the regular Visual C++ project link to it. However, I'm getting some errors when generating the VS2012 workspace:
"attempt to index global 'AutoWriteMetaTable' (a nil value)"
I can repro with 01-helloworld simply by changing the C.Application to C.Library. Not sure if there's a problem generating a solution with no application projects contained within. I figured I could use Jam to generate a library without an executable, I don't see any reason why it wouldn't be supported. Is this allowed?
I don't think I am properly receiving emails for posts here. I'll look into it. With that, I apologize for the late response.
In the current code, workspaces (solutions) are generated automatically based on the executables in the Jamfiles and their dependencies.
For anything that isn't an executable with a dependency, you have to use the
Workspace MyWorkspace : MyLibrary ; C.Library MyLibrary : abc.cpp ;