On Jun 9, 7:47 pm, Zakk Hoyt <
zakkh...@google.com> wrote:
> Right, GYP doesn't support iOS as it is. I was hoping it would be a simple
> as changing the SDK and SDKROOT, etc.... Unfortuantely, the SDKs for OSX and
> iOS are kept in different root folders, among other problems:
> iOS is in:
> /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/
>
> OSX is in:
> /Developer/SDKs/
>
> So simply changing the name of the SDK will not work. I ended up overwriting
> the variable where the SDK is appended to include the entire path. The
> problem with this approach is that overwriting these variables would destroy
> the ability to generate Mac projects.
Curious, how are you changing it? Looking at the Chromium gyp files,
there is a common.gypi that is force-included in every iteration (via -
I),
http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?revision=HEAD&view=markup
Apologies if I've misunderstood, but I think this may do what you
want.
This file sets the 'xcode_settings': { 'SDKROOT' and 'SYMROOT' }.
'SDKROOT' corresponds to the -isysroot flag. Does setting this
variable not work as expected? Could you explain how you're setting
it? It should be fairly easy to map from XCode settings to the
generator, if it's not sufficient, but I'm surprised that it wouldn't
already work.
>
> Unfortunately, there are other complications on top of that such as:
> * architecture. GYP will generate xcodeproj files that build for i386 or
> x64.
> * frameworks. Some frameworks share the same name between iOS and OSX but
> are not the same internally.
What do you mean? Again, looking at the Chromium gyp files,
http://src.chromium.org/viewvc/chrome/trunk/src/base/base.gypi?revision=HEAD&view=markup
, you'll see an entry
'link_settings': {
'libraries': [
'$(SDKROOT)/System/Library/Frameworks/AppKit.framework',
'$(SDKROOT)/System/Library/Frameworks/Carbon.framework',
# etc
],
},
Again, apologies for not understanding, but what are you needing to do
differently? The GYP generator doesn't add any special flags, AFAICT,
but if you had an example XCode stanza that you need it should be
fairly easy to compare.
> To put a solution in place for what we needed, I ended up making a script
> that is run after 'gclient runhooks'. This script crawls through the source
> tree and modifies the project.pbxproj files under every xcodeproj, replacing
> and adding strings. I wouldn't call it rock solid by any means, but it does
> spit out xcodeproj files that build for iOS. The one major obstacle that
> remains is the frameworks. Some frameworks share names between OSX and iOS,
> but are not the same internally. There is some sort of UID attached to the
> framework if you look in a pbxproj. I'm not sure how to handle those at the
> moment.
>
> I've proposed the idea (internal to my group) of branching off of the gyp
> system and adding the proper behaviour. Currently, iOS is way down the list
> of priorities. Is this something that anyone would be used by anyone? What
> about Android? I haven't needed to make a build for that platform yet, but I
> don't recall seeing the string "android" in any of the gyp/gypi files (at
> least that I can remember). If this would actually be used, perhaps it is
> worth looking at .
I am tangentially interested in a solution for a similar problem to
MSVS, relating to how platforms are configured (x86, x64, win mobile,
etc). The current 'msvs_configuration_platform' stanza leaves a lot to
be desired in generating a single project file that can compile
multiple target, not to mention execute build rules or exclude files
based on the platform or configuration, within the UI itself. This
would seem to overlap with your desire for the xcode generator to do
the same.
Is there a reason you wouldn't be interested in developing this in the
open?