linux: allow builds to override libdir path

linux: allow builds to override libdir path

Not all multilibs install into /usr/lib/, so when building for one which
doesn't, we hit errors where the detected python arch does not match the
detected target arch.  Like x86_64/powerpc64/sparc64/etc... which use
/usr/lib64/.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=103422

[bradn, 2011-09-23 19:13:52]

http://codereview.chromium.org/8018002/diff/1/build/common.gypi
File build/common.gypi (right):

http://codereview.chromium.org/8018002/diff/1/build/common.gypi#newcode148
build/common.gypi:148: 'libdir%': 'lib',
Strictly the double layered variable thing isn't needed for this one (as its not
used in this scope), but that's true of most of these. There has been much cargo
culting.

Although actually do you want this to just be based on target_arch, as opposed
to having to be set externally?

http://codereview.chromium.org/8018002/diff/1/build/common.gypi#newcode325
build/common.gypi:325: 'libdir%': '<(libdir)',
Can we pick something more discriptive than libdir. There's already
<(STATIC_LIB_DIR) etc built into gyp. How about sysroot_libdir ?

[vapier-goog, 2011-09-23 20:14:17]

http://codereview.chromium.org/8018002/diff/1/build/common.gypi
File build/common.gypi (right):

http://codereview.chromium.org/8018002/diff/1/build/common.gypi#newcode148
build/common.gypi:148: 'libdir%': 'lib',
i was informed that i should add this part, so i did :)

i don't think we want to go the route of assuming an arch<->libname binding
because diff distros have adopted diff standards, and when building on multilib
setups, the name might be different than non-multilib.

adding a default arch<->libname would probably be fine, but ultimately we'd have
to have a knob available to the end builder.

http://codereview.chromium.org/8018002/diff/1/build/common.gypi#newcode325
build/common.gypi:325: 'libdir%': '<(libdir)',
i don't think "sysroot_libdir" makes much sense though as it isn't generally
considered specific to the sysroot.  but i'm certainly not stuck on "libdir",
and if you really prefer "sysroot_libdir", then i'm fine with it.  i just want a
knob somewhere to twiddle.

[bradn, 2011-09-23 20:57:12]

On Fri, Sep 23, 2011 at 1:14 PM, <vapier@google.com> wrote:

>
>
http://codereview.chromium.**org/8018002/diff/1/build/**common.gypi<http://co...
> File build/common.gypi (right):
>
> http://codereview.chromium.**org/8018002/diff/1/build/**
>
common.gypi#newcode148<http://codereview.chromium.org/8018002/diff/1/build/common.gypi#newcode148>
> build/common.gypi:148: 'libdir%': 'lib',
> i was informed that i should add this part, so i did :)
>
> i don't think we want to go the route of assuming an arch<->libname
> binding because diff distros have adopted diff standards, and when
> building on multilib setups, the name might be different than
> non-multilib.
>
> adding a default arch<->libname would probably be fine, but ultimately
> we'd have to have a knob available to the end builder.
>
> ok, this arrangement is fine.


>
> http://codereview.chromium.**org/8018002/diff/1/build/**
>
common.gypi#newcode325<http://codereview.chromium.org/8018002/diff/1/build/common.gypi#newcode325>
> build/common.gypi:325: 'libdir%': '<(libdir)',
> i don't think "sysroot_libdir" makes much sense though as it isn't
> generally considered specific to the sysroot.  but i'm certainly not
> stuck on "libdir", and if you really prefer "sysroot_libdir", then i'm
> fine with it.  i just want a knob somewhere to twiddle.
>
>
I'm just warry of libdir in specific as it has an existing gyp meaning (the
place in product_dir where built libs get put).
How about system_libdir ?



>
>
http://codereview.chromium.**org/8018002/<http://codereview.chromium.org/8018...
>

[vapier-goog, 2011-09-23 22:02:31]

system_libdir is fine by me.  new patchset posted!

[bradn, 2011-09-23 22:25:32]

lgtm

[vapier-goog, 2011-09-26 22:03:02]

i don't think i have commit access to the tree :).  so who is to merge this for
me ?

[bradn, 2011-09-28 02:48:33]

What project are you on?
chromiumos?
-BradN



On Mon, Sep 26, 2011 at 3:03 PM, <vapier@google.com> wrote:

> i don't think i have commit access to the tree :).  so who is to merge this
> for
> me ?
>
>
>
http://codereview.chromium.**org/8018002/<http://codereview.chromium.org/8018...
>

[vapier-goog, 2011-09-28 03:26:33]

yes, cros

[commit-bot: I haz the power, 2011-09-30 03:17:08]

CQ is trying tha patch. Follow status at
https://chromium-status.appspot.com/cq/vapier@google.com/8018002/5001

[bradn, 2011-09-30 03:17:32]

Commit queue should work for you.
I've checked the checkbox for you, so it should just go in.

-BradN


On Tue, Sep 27, 2011 at 8:26 PM, <vapier@google.com> wrote:

> yes, cros
>
>
>
http://codereview.chromium.**org/8018002/<http://codereview.chromium.org/8018...
>

[commit-bot: I haz the power, 2011-09-30 04:38:45]

Change committed as 103422