Unified Build Setup

[Zer0xFF]

TODO

• commit travis & appvoyer fix

• move cmakelists.txt out of build_unix to cmake

• further breakdown Framework removing windows UI into FrameworkWinUI?

• Update README with new build instruction (TODO: Win32 Android Studio and UNIX/OSX/Win32 Gradle)

• add -DUNICODE

• update Info.plist to use properties value from cmake script

• remove -DUSE_ANDROID from gradle.build (was a work around to boost-cmake, but thats fixed now)

• remove armeabi android build

• fix zlib build (broken after CMAKE_CURRENT_BINARY_DIR changes)

• Merged Fix android gradle build, fix build & Fix cmake script back. Windows winres.h include fix should now be persistent even after UI edit.

• CMakeLists.txt for tools/PsfPlayer (Branch including a basic linux qt interface, but will keep for a separate PR)

• iOS? Jean is looking into this.

• CleanUp (delete project solutions, won't be possible until all platform, iOS included, move to CMake builds.)

Note:VTUNE was not tested.
suggestions?

AppVeyor & Travis

Edit:
as of 10/02/2017 this PR has been rebased.
AppVeyor & Travis as of this edit, travis OSX is backlogged and hasn't built, but I've built it myself successfully.

[jpd002]

Don't worry about PsfPlayer, this can be dealt with at another time.

I've been trying to build for iOS using this setup. It's very similar to your attempt, but there's a few things to take in consideration:

• Using a toolchain file seems to be necessary. I've been using this one, but I think it might be interesting to move that file to Dependencies at some point.
• CocoaPods doesn't seem to be working properly with an XCode project generated by CMake. That means, SDWebImage will need to be moved back to Dependencies (unless there's a magic way to make CocoaPods work).

Otherwise, the CMake setup looks usable for iOS. I don't know if you can build on iOS, but we can work without that platform for this PR and come back to it later. Also, I still need to confirm that, it looks like assert isn't working properly on macOS and iOS on Debug config.

On Win32, there seem to be an issue with the application manifest not being used somehow? The application doesn't have high dpi enabled and it uses the "old" common control styles. I will investigate this further.

[jpd002]

About the manifests on Win32, looks like the manifest files need to have a .manifest extension for them to be taken in consideration properly. I'll do that change in master.

[Zer0xFF]

Using a toolchain file seems to be necessary.

I've used this one myself for previous attempts and i did get it to build, but i couldn't tell if i had a valid package since Im not familiar with it.
since I don't have iOS, i don't know whats the issue with CocoaPods to even attempt at find a solution for it :/

(edit: while not ideal, try re-saving xcode project and see if that fixes it?)

the assert issue could be related to to cmake/xcode mash up, the -DCMAKE_BUILD_TYPE only sets preprocessors, while --Config sets build type, trying setting both to debug and see if that helps.

[Zer0xFF]

I've pushed a commit to reflect manifest name change, but im not sure I see a difference (I'm not sure what I'm looking for).

[jpd002]

That should be Play-x86.manifest

[jpd002]

Without the manifest, the status bar (and other controls) don't have the proper style. It also falls back to a blurry look on an high dpi display (because of the missing dpi awareness info).

[jpd002]

Also, opening and saving the Xcode project won't work for CI. I'll post my iOS "compatible" CMakeLists.txt once I get everything working and running on a device.

[Zer0xFF]

I've been reading about the Pod issue and I found this. this is one of few issues few that narrowed a quick fix to removing the "buildSettings" attributes, and this particular one supplied a python script to do it, this will leave the build CL compatible (but adds a 'hack' for a fix).

[jpd002]

Ok, I got a "proof of concept" iOS build using that CMake setup running correctly on a device (minus the SDWebImage stuff). Commit: 3a642e2. This still needs some work, so I will leave this out of this PR's scope.

Even though there's some minor details to iron out, I think the CMake PRs are in a good state to be merged in master. I'll do that later today.

[Margen67]

When this is finished will there be artifacts?
Referring to this: https://ci.appveyor.com/project/Thunder07/play/build/job/oqlgl735h53ca1ym/artifacts

[jpd002]

Yeah, I guess we could add artifact packaging in our AppVeyor and Travis configurations after that.

[Zer0xFF]

@jpd002 if you give me 5 secs, just a small typo in READ me and replace boost::thread dependency with std commit

[jpd002]

@Thunder07 Alright, just tell me when the PR will be ready.

[Zer0xFF]

alright, just updated this branch the README update was just to the android debug build line gradle -> gradew , and the other change was an include fix, so it should be good to merge now.

[jpd002]

Thanks, I'll merge once Travis and AppVeyor builds complete.

[iOS4all]

@jpd002 please can you tell us briefly what is this for? Is this will help to enhance this emu?
And is this stuff gonna to support iOS as well? Because you said it works but need something? What's missing?

[Zer0xFF]

@iOS4all this allow developers to build this project for all platforms using the same command, instead of different commands for different platform, aka made it easier for developers.

so even when this works with iOS it won't change anything.

[iOS4all]

@Thunder07 thanks for clarification. It's clear to me now.

[D1SMBD1D]

Since the whole building part is now finished, could you also add artifacts?

[Zer0xFF]

that part should be done by Jean, since uploading artifacts (on travis) requires an external account such as bintray etc, and its more appropriate for him to have that under his control.