<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, May 4, 2018 at 10:02 AM,  <span dir="ltr"><<a href="mailto:jani@apache.org" target="_blank">jani@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
> On 4 May 2018, at 08:53, Dirk Hohndel <<a href="mailto:dirk@hohndel.org">dirk@hohndel.org</a>> wrote:<br>
> <br>
> Hi Jan,<br>
> <br>
> On Wed, May 02, 2018 at 06:42:34PM +0200, <a href="mailto:jani@apache.org">jani@apache.org</a> wrote:<br>
>> <br>
>> 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.<br>
>> <br>
>> When using an Xcode project, hiding the developer id is easy, it is just to add<br>
>> export IOS_CODEID="iPhone Developer: <name> (<id>)” to your .bash_profile, and Xcode will automatically pick it up.<br>
>> <br>
>> While developing I always generate the 3 platforms with debug, and only the final testing is with release.<br>
>> <br>
>> 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).<br>
> <br>
> Changes to build.sh affect several use scenarios of that script. Please<br>
> realize that the vast majority of developers is using this on various<br>
> versions of Linux...<br>
> <br>
>> 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).<br>
>> <br>
>> How would a Xcode project be received (of course provided it can build the external libraries, with their own configure/make) ?<br>
> <br>
> Ugh. Maintaining the configuration for a proprietary build system as part<br>
> of our project and requiring people who make changes to the cmake build<br>
> system to be able to somehow edit the XCode project... not a fan.<br>
> I will admit that I'm not thrilled with the secondary build system through<br>
> qmake that we maintain, but at least that's well documented, well<br>
> understood, and relatively easy to keep in sync with what we are doing in<br>
> cmake. When I look at the files inside an Xcode project... Yuck. That's<br>
> quite ugly. And the problem is that we would move from something that<br>
> several of us understand well to something that potentially only one of<br>
> the developers is really comfortable with... that worries me.<br>
> <br>
>> We would get rid of qmake from iOS, and testing (with Xcode) would be a lot easier.<br>
> <br>
> Except that I really dislike using Xcode - I find it incredibly hard to<br>
> use, painfully slow, it has a terrible editor, and it's behavior is<br>
> generally random. The number of user complaints when things don't work<br>
> where the successful answer is "I don't know, quit Xcode, try again,<br>
> sometimes you have to do that multiple times"... that's not trust<br>
> inspiring. Right now we have the issue that archiving our project fails on<br>
> the first attempt. If you then in Xcode manually toggle the "iCloud"<br>
> capability a couple of times (mind you, we don't use iCloud, at all), then<br>
> randomly the archive will succeed. Great.<br>
> <br>
> So what you are hearing me say is "I understand why you would want this,<br>
> but I'm not sure I want to be stuck with maintaining this as part of our<br>
> source repository". If you can make this work, make this EASY TO MAINTAIN<br>
> AS WE ADD NEW SOURCE FILES, CHANGE DEPENDENCIES... I'm willing to consider<br>
> it - but please understand that I might also look at it and say "yeah,<br>
> no”.<br>
</div></div>Fair arguments, but a bit unfair against the newer versions of Xcode. <br>
<br>
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 :-)<br></blockquote><div><br></div><div>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.<br><br></div><div>miika<br></div></div></div></div>