How to build iOS simulator and iOS device ?

Dirk Hohndel dirk at hohndel.org
Thu May 3 23:53:44 PDT 2018


Hi Jan,

On Wed, May 02, 2018 at 06:42:34PM +0200, jani at apache.org wrote:
> 
> I am building in total 6 variants of subsurface (iOS-Simulator, iOS-Device, MacOS all in debug/release mode),  and right now there are no “nice” work.
> 
> When using an Xcode project, hiding the developer id is easy, it is just to add
> export IOS_CODEID="iPhone Developer: <name> (<id>)” to your .bash_profile, and Xcode will automatically pick it up.
> 
> While developing I always generate the 3 platforms with debug, and only the final testing is with release.
> 
> I have been playing with “upgrading”  ./subsurface/scripts/build.sh to understand the 2 iOS variants (replace -mobile) so I could  change the option “-both” to “-all3” (or something).

Changes to build.sh affect several use scenarios of that script. Please
realize that the vast majority of developers is using this on various
versions of Linux...

> However I am thinking of instead making a Xcode project with all paths relative, so it can be used by anyone. Having a Xcode project would also allow me not to build the libraries constantly (calling build.sh without options for some reason builds google maps every time).
> 
> How would a Xcode project be received (of course provided it can build the external libraries, with their own configure/make) ?

Ugh. Maintaining the configuration for a proprietary build system as part
of our project and requiring people who make changes to the cmake build
system to be able to somehow edit the XCode project... not a fan.
I will admit that I'm not thrilled with the secondary build system through
qmake that we maintain, but at least that's well documented, well
understood, and relatively easy to keep in sync with what we are doing in
cmake. When I look at the files inside an Xcode project... Yuck. That's
quite ugly. And the problem is that we would move from something that
several of us understand well to something that potentially only one of
the developers is really comfortable with... that worries me.

> We would get rid of qmake from iOS, and testing (with Xcode) would be a lot easier.

Except that I really dislike using Xcode - I find it incredibly hard to
use, painfully slow, it has a terrible editor, and it's behavior is
generally random. The number of user complaints when things don't work
where the successful answer is "I don't know, quit Xcode, try again,
sometimes you have to do that multiple times"... that's not trust
inspiring. Right now we have the issue that archiving our project fails on
the first attempt. If you then in Xcode manually toggle the "iCloud"
capability a couple of times (mind you, we don't use iCloud, at all), then
randomly the archive will succeed. Great.

So what you are hearing me say is "I understand why you would want this,
but I'm not sure I want to be stuck with maintaining this as part of our
source repository". If you can make this work, make this EASY TO MAINTAIN
AS WE ADD NEW SOURCE FILES, CHANGE DEPENDENCIES... I'm willing to consider
it - but please understand that I might also look at it and say "yeah,
no".

/D


More information about the subsurface mailing list