[WIP] convert build to use Bazel

[nornagon]

Hi again! Not sure if this is of any interest to you, but I thought I'd show you what I've been working on. This PR converts the build system to use Bazel instead of Xcode, which makes it a lot easier to pull in the CDDA source—no need to mess around with updating file lists in Xcode, for instance.

I think I haven't quite managed to get everything 100% dialed in, but this does produce a binary that runs & works!

[apollovy]

Hey, @nornagon . Does Bazel somehow make it possible to do a build under non-mac OS? If not, then which profits would we get compared to current setup (cocoapods + fastlane)?

[nornagon]

The main advantage here is that Bazel lets us use globs (e.g. *.cpp), which means there's nothing to update in Xcode when CDDA adds or removes files.

[nornagon]

I've made a separate repo over at https://github.com/nornagon/Cataclysm-DDA-experimental-iOS with some further changes, including some bug fixes (holding down a direction key on the d-pad now does a key repeat properly) and some changes that were expedient for the bazel build (mostly changing #include paths). I'm also exploring some changes to make context-sensitive input work (showing key shortcuts relevant to the current state of the game), based on how the Android version works.

[apollovy]

I've made a separate repo over at https://github.com/nornagon/Cataclysm-DDA-experimental-iOS with some further changes.

Hey. This is, frankly, unexpected. And it looks like doing it this way you even violate the license the software is distributed under, because from the repository perspective it now looks like you pretend to be the author of all the code in it. Frankly I'm not sure about this, but it looks a bit rude that there are no links to my original work.

Can you proceed with the fork? Or are there any difficulties with that approach? I'm also interested in why have you made a separate repo, what bonuses that gave you and what difficulties have you had with the fork approach?

including some bug fixes (holding down a direction key on the d-pad now does a key repeat properly)

Also I'm interested in merging the bugfixes to 0.E, 0.F and BN. But I assume they'll be in separate branches, without Bazel. In the meantime I can incorporate Bazel, too, but frankly atm I don't see any profits doing it, because fastlane + xcode work pretty well.

I'm also exploring some changes to make context-sensitive input work (showing key shortcuts relevant to the current state of the game), based on how the Android version works.

Hey, that sounds awesome, I was thinking about this myself many times, but never got there, because stopped playing at all. Sadly 0.E users won't receive that update, because, AFAIK, 0.E doesn't have contexts everywhere needed.

[nornagon]

@apollovy hey, sorry about that, that wasn't the intention. The LICENSE file still mentions your name, as is required by the license! I haven't added any documentation or anything to the repo, but I'd be happy to throw a link to your repo in a README when I add one. I broke the GitHub fork relationship because it seemed like you weren't particularly interested in merging the changes I was making, so I thought it was better to go my own way.

[apollovy]

Well, I'm not really interested in Bazel, because I don't see profits, but I can still merge it if it doesn't break stuff.

As for other changes it would be way easier to track changes if you'd stick to the fork. This way all the versions could receive all the updates you'll potentially deliver. And I'd be happy making existing players' lives better.

[nornagon]

Ah, I forgot, the other reason I broke the fork is that I wanted to pull in changes to Common, and didn’t want to open a second fork. So in my repo Common has been merged into the main repo, instead of a submodule. I’ll see if I can rearrange some stuff to merge back to the main repo but it will be some work, as I wasn’t cleanly able to get a version that worked in both Xcode and Bazel.

[apollovy]

The reason why Common was separated is to ease the maintenance of code shared by all 3 versions: 0.E, 0.F and BN. At the same time I now have a feeling that this might be achieved by creating a common branch and forking other branches from it, then, when the time comes to update the commons, one would be required to checkout the common branch, make changes and then merge it to all other branches. And it feels again that it would make more mess then fix :)

I think that the changes to commons should be easy to incorporate, taking into account that it's a separate repo in my case.

Btw you could've removed the Common submodule and add a Common directory right inside the fork ;)