Discussion:
How to build iOS simulator and iOS device ?
j***@apache.org
2018-05-02 16:42:34 UTC
Permalink
Hi

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).

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) ?

We would get rid of qmake from iOS, and testing (with Xcode) would be a lot easier.

Looking forward to get comments.
rgds
Jan I.
Dirk Hohndel
2018-05-04 06:53:44 UTC
Permalink
Hi Jan,
Post by j***@apache.org
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...
Post by j***@apache.org
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.
Post by j***@apache.org
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".

/D
j***@apache.org
2018-05-04 07:02:59 UTC
Permalink
Post by Dirk Hohndel
Hi Jan,
Post by j***@apache.org
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...
Post by j***@apache.org
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.
Post by j***@apache.org
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.
Post by Dirk Hohndel
/D
Miika Turkia
2018-05-04 07:08:14 UTC
Permalink
Post by j***@apache.org
Post by Dirk Hohndel
Hi Jan,
Post by j***@apache.org
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.
Post by Dirk Hohndel
Post by j***@apache.org
When using an Xcode project, hiding the developer id is easy, it is
just to add
Post by Dirk Hohndel
Post by j***@apache.org
export IOS_CODEID="iPhone Developer: <name> (<id>)” to your
.bash_profile, and Xcode will automatically pick it up.
Post by Dirk Hohndel
Post by j***@apache.org
While developing I always generate the 3 platforms with debug, and only
the final testing is with release.
Post by Dirk Hohndel
Post by j***@apache.org
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).
Post by Dirk Hohndel
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...
Post by j***@apache.org
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).
Post by Dirk Hohndel
Post by j***@apache.org
How would a Xcode project be received (of course provided it can build
the external libraries, with their own configure/make) ?
Post by Dirk Hohndel
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
Post by Dirk Hohndel
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.
Post by j***@apache.org
We would get rid of qmake from iOS, and testing (with Xcode) would be a
lot easier.
Post by Dirk Hohndel
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
Post by Dirk Hohndel
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
Post by Dirk Hohndel
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
Post by Dirk Hohndel
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
Dirk Hohndel
2018-05-04 08:06:59 UTC
Permalink
Post by Dirk Hohndel
Post by Dirk Hohndel
Post by Dirk Hohndel
but I'm not sure I want to be stuck with maintaining this as part
of our
Post by Dirk Hohndel
Post by Dirk Hohndel
source repository". If you can make this work, make this EASY TO
MAINTAIN
Post by Dirk Hohndel
Post by Dirk Hohndel
AS WE ADD NEW SOURCE FILES, CHANGE DEPENDENCIES... I'm willing to
consider
Post by Dirk Hohndel
it - but please understand that I might also look at it and say
"yeah,
Post by Dirk Hohndel
Post by Dirk Hohndel
no”.
Fair arguments, but a bit unfair against the newer versions of Xcode.
I am using 9.3
I think every version I try is worse than the one before.
Post by Dirk Hohndel
Post by Dirk Hohndel
My aim is to have a simple IDE, where I can develop/generate and
test. How
Post by Dirk Hohndel
do the Linux developers, hope not like I do sometimes use vi :-)
I use QtCreator and am very happy with it for rapid edit/compile/debug integration.
Post by Dirk Hohndel
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.
Ah, yes. And then we have a few developers who are truly hard core. At least one is using ue as his IDE :-)

But let me repeat... I'm willing to consider it, and if this is a trade-off that gets us another active developer for iOS, I'll try to be flexible... but I will also need to value maintainability quite highly.

/D
Jan Iversen
2018-05-04 08:25:26 UTC
Permalink
Sent from my iPad
Post by Dirk Hohndel
Post by Dirk Hohndel
Post by Dirk Hohndel
Post by Dirk Hohndel
but I'm not sure I want to be stuck with maintaining this as part
of our
Post by Dirk Hohndel
Post by Dirk Hohndel
source repository". If you can make this work, make this EASY TO
MAINTAIN
Post by Dirk Hohndel
Post by Dirk Hohndel
AS WE ADD NEW SOURCE FILES, CHANGE DEPENDENCIES... I'm willing to
consider
Post by Dirk Hohndel
it - but please understand that I might also look at it and say
"yeah,
Post by Dirk Hohndel
Post by Dirk Hohndel
no”.
Fair arguments, but a bit unfair against the newer versions of Xcode.
I am using 9.3
I think every version I try is worse than the one before.
Post by Dirk Hohndel
Post by Dirk Hohndel
My aim is to have a simple IDE, where I can develop/generate and
test. How
Post by Dirk Hohndel
do the Linux developers, hope not like I do sometimes use vi :-)
I use QtCreator and am very happy with it for rapid edit/compile/debug integration.
Post by Dirk Hohndel
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.
Ah, yes. And then we have a few developers who are truly hard core. At least one is using ue as his IDE :-)
But let me repeat... I'm willing to consider it, and if this is a trade-off that gets us another active developer for iOS, I'll try to be flexible... but I will also need to value maintainability quite highly.
That is very clear to me, I am playing with a combination of vi, make and simulator. I want to help the project not be a burden :-)

Anybody knows how to get QtCreator to start the ios simulator ?

I called subsurface/scripts/build.sh -build-deps -both
then tried to drag subsurface/build-mobile/Subsurface.app into the simulator, but I get a very informative message “cannot be installed right now, try later” any hints ?

Ps. will forget Xcode for now, and see if I can debug effectively with QtCreator (or Xcode without generating a project).

rgds
jan i
Post by Dirk Hohndel
/D
Robert Helling
2018-05-04 08:30:05 UTC
Permalink
Post by Jan Iversen
Anybody knows how to get QtCreator to start the ios simulator ?
You have to set this as the development target. Enable it as a „kit“ and then select it as „device“

Loading Image... <Loading Image...

Robert

Robert Helling
2018-05-04 08:01:08 UTC
Permalink
Jan,
Post by j***@apache.org
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 :-)
to develop Qt applications, Qt Creator is really the IDE of choice (I am saying this as a traditional emacs user).

Robert
Loading...