GN: Give static_libs with common names unique output_name

GN: Give static_libs with common names unique output_name

On mac static libs all go into the same output and so they need unique
names in order to avoid having multiple rules attempting to produce the
same output.

[jamesr, 2014-07-08 05:26:25]

This is on top of https://codereview.chromium.org/353113002/

[brettw, 2014-07-08 21:33:09]

Do you know why we use a different directory this? I just copied it from GYP but
looking at this it seems bad for it to be different on Mac.

[jamesr, 2014-07-09 01:13:50]

On 2014/07/08 21:33:09, brettw wrote:
> Do you know why we use a different directory this? I just copied it from GYP
but
> looking at this it seems bad for it to be different on Mac.

I don't know why the output dir for static libs on mac is different.  Nico added
it here: https://codereview.chromium.org/9139003 for dylibs indicating that it
matches make/xcode, but I'm not sure if it's really important where the static
libs go in the gyp mac build. Nico?

[jamesr, 2014-07-09 01:24:03]

That just moves it around, looks like this originally dates from
https://codereview.chromium.org/9014002/diff/6001/pylib/gyp/generator/ninja.p...
 / https://code.google.com/p/gyp/source/detail?r=1112.

If I disable this for static libs on mac (and put them in the same place they go
on other platforms, i.e. next to the .o's) then I can build and run at least
some targets.  I'd see how that fares on the trybots but I'm not sure how to
send tryjobs for a tools/gyp/ patch.

[Nico, 2014-07-09 01:24:33]

On Tue, Jul 8, 2014 at 6:13 PM, <jamesr@chromium.org> wrote:

> On 2014/07/08 21:33:09, brettw wrote:
>
>> Do you know why we use a different directory this? I just copied it from
>> GYP
>>
> but
>
>> looking at this it seems bad for it to be different on Mac.
>>
>
> I don't know why the output dir for static libs on mac is different.  Nico
> added
> it here: https://codereview.chromium.org/9139003 for dylibs indicating
> that it
> matches make/xcode, but I'm not sure if it's really important where the
> static
> libs go in the gyp mac build. Nico?
>

They are in the product directory because that's where Xcode puts them. I
think a few build scripts try to find static libraries and / or do manual
linker flag tweaks, so it was important that it matches between xcode and
ninja in gyp.

In hindsight, we thought that the product directory was a more natural
place for (target) libraries and were thinking about changing linux to
match mac. (Though that might've been more about shared libraries? I think
there were some places that bundled .so files.
https://code.google.com/p/chromium/codesearch#search/&q=product_dir%5C)%5C/li...
has a few references to the lib dir – but none of these look like what I'm
thinking of.)


>
> https://codereview.chromium.org/376773002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jamesr, 2014-07-09 01:27:48]

On 2014/07/09 01:24:33, Nico (away) wrote:
> On Tue, Jul 8, 2014 at 6:13 PM, <mailto:jamesr@chromium.org> wrote:
> 
> > On 2014/07/08 21:33:09, brettw wrote:
> >
> >> Do you know why we use a different directory this? I just copied it from
> >> GYP
> >>
> > but
> >
> >> looking at this it seems bad for it to be different on Mac.
> >>
> >
> > I don't know why the output dir for static libs on mac is different.  Nico
> > added
> > it here: https://codereview.chromium.org/9139003 for dylibs indicating
> > that it
> > matches make/xcode, but I'm not sure if it's really important where the
> > static
> > libs go in the gyp mac build. Nico?
> >
> 
> They are in the product directory because that's where Xcode puts them. I
> think a few build scripts try to find static libraries and / or do manual
> linker flag tweaks, so it was important that it matches between xcode and
> ninja in gyp.

It was important, but is it still?


> 
> In hindsight, we thought that the product directory was a more natural
> place for (target) libraries and were thinking about changing linux to
> match mac. (Though that might've been more about shared libraries? I think
> there were some places that bundled .so files.
>
https://code.google.com/p/chromium/codesearch#search/&q=product_dir%5C)%5C/li...
> has a few references to the lib dir – but none of these look like what I'm
> thinking of.)

Shared libraries do go into the output dir on linux and mac.

[Nico, 2014-07-09 01:35:32]

On Tue, Jul 8, 2014 at 6:27 PM, <jamesr@chromium.org> wrote:

> On 2014/07/09 01:24:33, Nico (away) wrote:
>
>  On Tue, Jul 8, 2014 at 6:13 PM, <mailto:jamesr@chromium.org> wrote:
>>
>
>  > On 2014/07/08 21:33:09, brettw wrote:
>> >
>> >> Do you know why we use a different directory this? I just copied it
>> from
>> >> GYP
>> >>
>> > but
>> >
>> >> looking at this it seems bad for it to be different on Mac.
>> >>
>> >
>> > I don't know why the output dir for static libs on mac is different.
>>  Nico
>> > added
>> > it here: https://codereview.chromium.org/9139003 for dylibs indicating
>> > that it
>> > matches make/xcode, but I'm not sure if it's really important where the
>> > static
>> > libs go in the gyp mac build. Nico?
>> >
>>
>
>  They are in the product directory because that's where Xcode puts them. I
>> think a few build scripts try to find static libraries and / or do manual
>> linker flag tweaks, so it was important that it matches between xcode and
>> ninja in gyp.
>>
>
> It was important, but is it still?


For gyp, yes (as that promises that switching generators mostly keeps your
build files working). If you want to change it in gyp, you could add some
generator setting and set that in chromium though.


>
>
>
>
>  In hindsight, we thought that the product directory was a more natural
>> place for (target) libraries and were thinking about changing linux to
>> match mac. (Though that might've been more about shared libraries? I think
>> there were some places that bundled .so files.
>>
>
> https://code.google.com/p/chromium/codesearch#search/&q=
> product_dir%5C)%5C/lib%5Cb&p=1&sq=package:chromium&type=cs
>
>> has a few references to the lib dir - but none of these look like what I'm
>> thinking of.)
>>
>
> Shared libraries do go into the output dir on linux and mac.
>
> https://codereview.chromium.org/376773002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jamesr, 2014-07-09 01:42:58]

I'm asking if it matters in chromium, not in gyp.  The GN on mac behavior is
copied from gyp but if it's not relevant to chromium then there's no need to
copy that behavior to GN on mac and we can just put static libs elsewhere in GN
and not bother with all of these output_names.

[Nico, 2014-07-09 01:46:33]

I'd expect it to matter in minor ways in chromium's gyp files (due to copy
rules copying .so files around, and these need to know where the source
files are), but I don't think it matters in deep ways. Since GN will
probably have separate copy rules that can use gn's directory layout, it
should be possible to use the same directory structure everywhere. (In
general, I thought one theme of GN was "unify stuff" – like using cflags
everywhere etc)


On Tue, Jul 8, 2014 at 6:42 PM, <jamesr@chromium.org> wrote:

> I'm asking if it matters in chromium, not in gyp.  The GN on mac behavior
> is
> copied from gyp but if it's not relevant to chromium then there's no need
> to
> copy that behavior to GN on mac and we can just put static libs elsewhere
> in GN
> and not bother with all of these output_names.
>
> https://codereview.chromium.org/376773002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jamesr, 2014-07-09 01:58:41]

OK - closing this in favor of https://codereview.chromium.org/378123002/.