How to build iOS simulator and iOS device ?
jani at apache.org
jani at apache.org
Fri May 4 00:02:59 PDT 2018
> On 4 May 2018, at 08:53, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> 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”.
Fair arguments, but a bit unfair against the newer versions of Xcode.
My aim is to have a simple IDE, where I can develop/generate and test. How do the Linux developers, hope not like I do sometimes use vi :-)
I had problems debugging both iOS (simulator) and Mac. Using an IDE allows me to have a nice workflow, debug, make a change, generate and debug again.
Being new to this project I am of course very open to adapting, so please see my suggestion on Xcode project as my way of having an effective workflow.
rgds
Jan I.
>
> /D
More information about the subsurface
mailing list