From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Colin Walters <walters@verbum.org>
Cc: poky@yoctoproject.org
Subject: Re: [patch] autotools: Remove .la files by default
Date: Tue, 29 Mar 2011 17:29:30 +0100 [thread overview]
Message-ID: <1301416170.24596.73.camel@rex> (raw)
In-Reply-To: <AANLkTim-tPhaRCWsCP=sDW30FUL1MfyxTOHabCSHyeQK@mail.gmail.com>
On Tue, 2011-03-29 at 12:15 -0400, Colin Walters wrote:
> On Tue, Mar 29, 2011 at 12:03 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>
> > So no, I'm not going to merge this patch at this time. If we were going
> > to do something like this I'd rather thrown out libtool entirely and
> > switch to something like dolt.
>
> Would you take an option, off by default then? I definitely do not
> want these files in my OS; I could remove them in a
> ROOTFS_POSTPROCESS_COMMAND, but it'd be even better to do in after
> each build.
I can do better than that, we have some limitations in the way .conf
files are parsed compared to .bbclass files. If you create a
"localchanges.bbclass" containing:
autotools_do_install_append () {
# Also kill off .la files; they are wholly unnecessary and actually can
# break things; see:
# https://live.gnome.org/GnomeShell/RemovingLaFiles
# http://wiki.debian.org/ReleaseGoals/LAFileRemoval
find ${D}${libdir} -name '*.la' -delete
}
and then do INHERIT += "localchanges" you should have this doing what
you want though. You can create a classes/ directory for the .bbclass
along side you conf files (or add a layer for your customisations).
> > Also note in your gnome shell link above that its listed as required
> > because of "the dirty hacks that jhbuild plays to get it to sandbox your
> > system" which is hardly a glowing recommendation. We don't have this
> > problem.
>
> The core problem arises in that often for developers it's convenient
> to do partial builds; say only rebuild glib and gtk+, but not rebuild
> pango (which lies between them). What the libtool pango.la file does
> is add -L/usr/lib which is 1) unnecessary and 2) forces the linker
> search first in /usr/lib instead of /opt/gnome like we want.
Right, but with our build environment, this really becomes a non-issue
(and I've been trying to get patches upstream which stop -L/usr/lib
being injected anyway as that is a libtool bug).
Cheers,
Richard
next prev parent reply other threads:[~2011-03-29 16:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-29 14:43 [patch] autotools: Remove .la files by default Colin Walters
2011-03-29 16:03 ` Richard Purdie
2011-03-29 16:15 ` Colin Walters
2011-03-29 16:29 ` Richard Purdie [this message]
2011-03-29 17:04 ` Colin Walters
2011-03-29 22:18 ` Richard Purdie
2011-03-29 16:35 ` Koen Kooi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1301416170.24596.73.camel@rex \
--to=richard.purdie@linuxfoundation.org \
--cc=poky@yoctoproject.org \
--cc=walters@verbum.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.