On Fri, May 4, 2018 at 10:02 AM, <j...@apache.org> wrote: > > > > On 4 May 2018, at 08:53, Dirk Hohndel <d...@hohndel.org> wrote: > > > > Hi Jan, > > > > On Wed, May 02, 2018 at 06:42:34PM +0200, j...@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
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface