[email protected]
As thomasvl pointed out, you don't have any types specified for these
targets.
That said, now that there's a stand-alone gyp testing infrastructure, we're
trying to eliminate these behavioral differences between the different
generators. It'd be good to capture a concrete stripped-down test case that
demonstrates the behavior. Then we can make sure all the generators behave
consistently.
If you want some help/guidance on doing that, let's shift this thread to
gyp-developer. Or feel free to send me an example (or questions) directly.
Thanks,
--SK
On Thu, Oct 1, 2009 at 11:45 AM, brymcq <[email protected]> wrote:
>
> I'm working on some code that uses the gyp build system. I find that
> there are cases where I want to aggregate several libraries into a
> single library target so other clients can depend on one "public"
> library target instead of having to reference a bunch of individual
> library targets. For instance I might have:
>
> 'targets': [
> {
> 'target_name': 'foo',
> 'dependencies': [
> some deps here
> ],
> 'sources': [
> some sources here
> ]
> },
> {
> 'target_name': 'bar',
> 'dependencies': [
> some deps here
> ],
> 'sources': [
> some sources here
> ]
> },
> {
> 'target_name': 'public',
> 'dependencies': [
> 'foo',
> 'bar',
> ],
> },
> ]
>
> I then have consumers of my library depend on the 'public' target
> rather than depending on 'foo' and 'bar'
>
> This actually works fine on Linux and Windows builds, but on OS X
> using xcodebuild, my builds fail with:
>
> libpublic.a: No such file or directory
>
> Is there some way to get the xcodebuilds to properly build these stub
> libraries that don't have any source files? Does the gyp->xcode
> generation code need to change to support this?
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
