> On 4 May 2018, at 08:53, Dirk Hohndel <[email protected]> wrote: > > Hi Jan, > > On Wed, May 02, 2018 at 06:42:34PM +0200, [email protected] 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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
