Copy public headers to the output dir after building static lib for iOS

Copy public headers to the output dir after building static lib for iOS

In the embedded help printout for the script (shell-based, then Python),
for long time we suggested its users that the public headers would be
available under the "include" subdirectory (inside the output dir) –
in the case of using build option "static_only".

But it was not implemented, actually. And I believe it would be helpful,
especially for the new users. Thus, proposing to add that logic now.

NOTRY=True
BUG=None

[VladimirTechMan, 2017-02-26 00:56:38]

Description was changed from

==========
Copy public headers to the output dir after building static lib for iOS

In the embedded help printout from the script, for long time we promised
its users that the public headers will be available under the "include"
subdirectory, inside the output dir – when running the "static_only build.
First in the shell-based version of the script. Then it was copied to
Python. But it was not implemented actually. Adding that logic now.

NOTRY=True
BUG=None
==========

to

==========
Copy public headers to the output dir after building static lib for iOS

In the embedded help printout for the script (shell-based, then Python),
for long time we suggested its users that the public headers would be
available under the "include" subdirectory (inside the output dir) –
in the case of using build option "static_only".

But it was not implemented, actually. And I believe it would be helpful,
especially for the new users. Thus, proposing to add that logic now.

NOTRY=True
BUG=None
==========

[VladimirTechMan, 2017-02-26 00:57:43]

Description was changed from

==========
Copy public headers to the output dir after building static lib for iOS

In the embedded help printout for the script (shell-based, then Python),
for long time we suggested its users that the public headers would be
available under the "include" subdirectory (inside the output dir) –
in the case of using build option "static_only".

But it was not implemented, actually. And I believe it would be helpful,
especially for the new users. Thus, proposing to add that logic now.

NOTRY=True
BUG=None
==========

to

==========
Copy public headers to the output dir after building static lib for iOS

In the embedded help printout for the script (shell-based, then Python),
for long time we suggested its users that the public headers would be
available under the "include" subdirectory (inside the output dir) –
in the case of using build option "static_only".

But it was not implemented, actually. And I believe it would be helpful,
especially for the new users. Thus, proposing to add that logic now.

NOTRY=True
BUG=None
==========

[VladimirTechMan, 2017-02-26 00:57:43]

vladimirtechman@gmail.com changed reviewers:
+ kjellander@webrtc.org, kthelgason@webrtc.org

[kjellander_webrtc, 2017-02-27 07:16:52]

lgtm but wait for kthelgason

[kthelgason, 2017-02-27 08:00:50]

We won't use this internally so it will remain untested. I'm leaning against
adding this as it's very easy (compared with building webrtc) to just copy these
manually, or add as a step in an external buildscript.

[VladimirTechMan, 2017-02-28 02:16:31]

On 2017/02/27 08:00:50, kthelgason wrote:
> We won't use this internally so it will remain untested. I'm leaning against
> adding this as it's very easy (compared with building webrtc) to just copy
these
> manually, or add as a step in an external buildscript.

Thanks for feedback on that, Kári. Understood. My hope was that we could give a
little bit more support for the newbies just starting with this implementation
of WebRTC – as they may not know yet where those headers are inside the
repository tree. No doubt that it can be done by another external script, on top
of this one, or even manually. It is largely about how much of "out of the box"
readiness we generally want (or do not want) to give to the external devs who
look for a quick start. But I understand your view and reasons, here. Esp. in
terms of assuring that the related code works and is not broken by future
changes (renaming, etc.) to the other parts of the repository tree.

Well, in that case, I believe that we need, at least, to remove the suggestion
in the script's help printout, about copying the header files to the "include"
subdirectory. I can do that patch then.

In general, I accept that build_ios_libs.py was done with the main focus on the
internal builds and testing of the framework. Having said that, I strongly
believe that it is also very useful for external developers, to make it easier
for them to get a ready iOS framework from the source code. Thus, some of my
fixes; cleaning things up a little bit.

[kthelgason, 2017-02-28 09:40:35]

On 2017/02/28 02:16:31, VladimirTechMan wrote:
> On 2017/02/27 08:00:50, kthelgason wrote:
> > We won't use this internally so it will remain untested. I'm leaning against
> > adding this as it's very easy (compared with building webrtc) to just copy
> these
> > manually, or add as a step in an external buildscript.
> 
> Thanks for feedback on that, Kári. Understood. My hope was that we could give
a
> little bit more support for the newbies just starting with this implementation
> of WebRTC – as they may not know yet where those headers are inside the
> repository tree. No doubt that it can be done by another external script, on
top
> of this one, or even manually. It is largely about how much of "out of the
box"
> readiness we generally want (or do not want) to give to the external devs who
> look for a quick start. But I understand your view and reasons, here. Esp. in
> terms of assuring that the related code works and is not broken by future
> changes (renaming, etc.) to the other parts of the repository tree.

I 100% agree with you, and I really believe out-of-the-box experience is
important. However, the experience of getting these static libraries is already
very complicated, and involves getting multiple GB of code on to your machine
and compiling it with an unfamiliar build system (not to mention that it takes
ages!). What we really want to do to support people getting started with WebRTC
is to provide a precompiled .framework that can be dragged in to an XCode
project. That should provide a much better experience for devs new to WebRTC.

I really appreciate you making an effort here however, and have been glad to
receive many of your patches. I think however that we should close this one, as
I believe we can solve this problem in an even better way.

[VladimirTechMan, 2017-02-28 17:26:53]

On 2017/02/28 09:40:35, kthelgason wrote:
> On 2017/02/28 02:16:31, VladimirTechMan wrote:
> > On 2017/02/27 08:00:50, kthelgason wrote:
> 
...
> I really appreciate you making an effort here however, and have been glad to
> receive many of your patches. I think however that we should close this one,
as
> I believe we can solve this problem in an even better way.

Alright. Thanks! We're on the same page, in general. And as long as you have a
better plan in mind, I've no issue. Closing now.