How to build iOS simulator and iOS device ?

[Miika Turkia]

On Fri, May 4, 2018 at 10:02 AM, <jani at apache.org> wrote:

>
>
> > 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 have to admit I have moved on from vi and use vim nowadays. Just a lot
more comfortable to use than any IDE I have tried.

miika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180504/c5fe576b/attachment-0001.html>