Thoughts on ldflags

59 views
Skip to first unread message

Brett Wilson

unread,
Oct 3, 2013, 7:44:53 PM10/3/13
to gn-...@chromium.org
Originally I had ldflags just apply to the current target. If you
wanted any dependent targets to get them, you had to put them in an
all/direct_dependent_configs.. This was annoying because if you had a
static library and you wanted to add a .lib to the final link line,
you had to stick in in a separate config just to get it there. This is
especially annoying for Linux pkgconfig stuff which returns both
cflags and ldflags, and you want the cflags to apply to direct
dependents only, and the linker flags to apply to "whoever finally
links you".

Then I decided to make ldflags inherit across static library
boundaries and removed duplicates. This solved the problem nicely, but
now I'm realizing that this is probably worse. I just wrote configs
for "symbols" and "no symbols", which uses both compiler and linker
flags. Applying this to all targets by default would mean that to
change it for one target, you would have to change it for all of its
dependencies also. To allow changing it, I would have to break it up
into one config to apply to static libraries that only specifies
cflags, and one for dynamic libraries and executables that specifies
both those and linker flags.

Options:
1. Go back to not inheriting and work around the issue with pkgconfig
somehow (this would probably mean two configs for each "package", one
for linking and one for compiling). I think most other cases are not
difficult if we do this since adding something to
all_dependent_configs isn't so bad.

2. Keep the current inherited one and split apart the problematic
configs (like my symbols example) into one that's applied for
compiling, and one for final linking.

3. Add a new ldflags variable "dependent_ldflags" that is inherited
and make "ldflags" not inherit across shared library boundaries.

4. Add a "libs" and "libpaths" variables which are inherited across
static library boundaries (this saves you from writing "-L" prefixes
also), and make ldflags not inherit. I believe these are the only
cases where we really need the inheritance.

I'm weakly preferring option 4. Option 2 is easiest. Any other opinions?

Brett

Brett Wilson

unread,
Oct 4, 2013, 8:09:27 PM10/4/13
to gn-...@chromium.org
I've implemented option 4 which was easier to do than I expected (just
an afternoon). This seems to work pretty well and the callsites are
clearer (you no longer have to add "-l" before libraries.

Brett
Reply all
Reply to author
Forward
0 new messages