Re: Add "standalone_static_library" target type (issue 11031005)

[bor...@google.com]

Uploaded patch set 2. Since I didn't meet a lot of resistance to the idea of
adding a target type for a "non-thin," "final" static library, I changed
this CL
to add a "standalone_static_library" type. I have only tested this with
make.


https://codereview.chromium.org/11031005/diff/6001/pylib/gyp/generator/make.py
File pylib/gyp/generator/make.py (right):

https://codereview.chromium.org/11031005/diff/6001/pylib/gyp/generator/make.py#newcode1547
pylib/gyp/generator/make.py:1547: postbuilds=postbuilds)
What should be the behavior when a standalone_static_library depends on
a static_library or another standalone_static_library? I would think
that the symbols from the dependency should get included in the
standalone_static_library.

https://codereview.chromium.org/11031005/

[tha...@chromium.org]

This is to disable the thin archive optimization on a per-target level,
right? I
thoguht about doing this a few times, and I always thought I'd add a new
attribute, say 'force_standalone_static_library' or 'is_distributable',
which
people would add to the targets that should become fat static libraries.

That way, you only have to change the generators that have a thin static
library
optimization, and more importantly, no new target type appears (which
potentially has new dependency rules, etc).

Does that make sense?

https://codereview.chromium.org/11031005/

[ma...@chromium.org]

As written, I don’t think this will work properly. static_library has
special
meanings in input.py too, and I’d hate to have to maintain another static
library type.

https://codereview.chromium.org/11031005/

[Evan Martin]

Did you guys have any thoughts on some of the issues I brought up?

E.g. we currently don't guarantee a static_library target has a specific path or even a specific filename, it's all internal details.  The reason they want fat libraries is so they can package up the .a for distribution.

--

[Mark Mentovai]

I’d think that a “distributable” .a, in addition to being not thin, would also need to be placed into PRODUCT_DIR.

Up to you as to whether the “non-distributable” .a files move to PRODUCT_DIR. Xcode puts them there, but it seems sort of reasonable for them to not live there at a generator’s discretion.

[Ryan Sleevi]

This has come up in a related form with the Chrome for Android's team
use of Java, and their desire to take shared libraries and package
them up for distribution to testers. In short, wanting to know the
final filename(s) of the outputs of a given target, to be able to
create a 'copies' rule or use it in an action.

Right now, it's hacky-and-it-works , see
http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?view=annotate#l2242

'input_shlib_path':
'<(SHARED_LIB_DIR)/<(SHARED_LIB_PREFIX)net_unittests<(SHARED_LIB_SUFFIX)',

For packaging a fat library, I would imagine

'copies': [
{ 'destination': '<(PRODUCT_DIR)/dist',
'files': [ '<(LIB_DIR)/<(LIB_PREFIX)target_name<(LIB_SUFFIX)' ],
},
],

Yes, all of this (currently) relies on generator-specific magic, but
it's worked so far, and at least has the benefit of having an explicit
step to make it clear about what the expected final result is.

[Evan Martin]

I think ninja treats static libs like .o files, which means they end up with funny paths like out/Debug/path/to/gyp/file/lib<targentname>.a

https://code.google.com/p/gyp/source/browse/trunk/pylib/gyp/generator/ninja.py#1109

(see the "GypPathToUniqueOutput" at the end).

But I guess that's Linux-specific, and it could be changed to behave like Mac to write everything into LIB_DIR if it really mattered.

(I think I may have written it back when I thought you could have two targets with the same name.)

[Torne (Richard Coles)]

..didn't we recently confirm (and add a test for the case) that you
*can* have two targets with the same name? (in different directories,
as long as they are not installed, or have manually overridden install
paths)

--
Torne (Richard Coles)
to...@google.com

[bor...@google.com]

I agree that it doesn't make a lot of sense to have two almost-identical
target
types. I'm not sure I like the addition of another attribute to force
behavior
that intuitively should be the default. Would it make more sense (with the
obvious objection that it would require changes in Chromium) to instead
have a
"thin_archive_optimization" flag which defaults to zero but can be set to
one?


https://codereview.chromium.org/11031005/

[tha...@chromium.org]

At least in Chromium, we'd want to set this on every static library. On the
other hand, there's only one target (libskia.a) that wants a non-thin
library,
so I'd say the fast path is the usually desired path.

https://codereview.chromium.org/11031005/

[bor...@google.com]

Fair enough. I'll modify this to add a "standalone_static_library" flag.

https://codereview.chromium.org/11031005/

[bor...@google.com]

Uploaded patch set 3, which instead adds a "standalone_static_library" flag.

https://codereview.chromium.org/11031005/

[tha...@chromium.org]

Thanks, I like this much better.

. Can you update the CL description with the exact semantics of this
attribute?
I suppose it's a) non-thin standalone library b) library appears in
<(PRODUCT_DIR) c) library is called
<(STATIC_LIBRARY_PREFIX)targetname<(STATIC_LIBRARY_SUFFIX)?

. Can you add a test that checks the semantics described above? (see the
test/
directory; `python gyptest.py -a` will run all tests, `python -f ninja
test/mac`
will run only the tests below test/mac, and only for ninja)

Thanks for working on this!

https://codereview.chromium.org/11031005/