All of lore.kernel.org
 help / color / mirror / Atom feed
From: Colin Walters <walters@verbum.org>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: RFC: magic libtool .la removal
Date: Tue, 18 Jun 2013 12:05:38 -0400	[thread overview]
Message-ID: <1371571538.3466.27.camel@localhost> (raw)
In-Reply-To: <1371570476.20823.121.camel@ted>

On Tue, 2013-06-18 at 16:47 +0100, Richard Purdie wrote:

> The thing which really worries me about this is that we'll start to
> deviate quite massively with how upstream expect us to use autotools.

I just consider upstream wrong, and so do others:
http://wiki.debian.org/ReleaseGoals/LAFileRemoval
http://fedoraproject.org/wiki/Packaging:Guidelines (search for .la)
http://blog.flameeyes.eu/2008/04/what-about-those-la-files (the one mostly sane Gentoo guy)

> As things stand, we have a number of sysroot fixes for the sysroot
> support in libtool which is basically broken out the box. I have tried
> discussing them with upstream and was ignored, mainly as we patch
> libtool and we're supposed to use it unpatched. 

Yeah, I dunno...maybe someone needs to fork libtool.

> I worry that if we go this route, the builds will stop working without
> the .la file removal and that we'll lose any chance of being able to
> resolve our patchset with libtool upstream. We might as well throw away
> libtool at that point

Or that...

>  and save the overhead. It also means we will have
> bigger problems working on something like darwin (which I've had work in
> the past).

I don't have any experience with Darwin myself.

> So I don't see the pressing need to set us off down a path on our own.
> Yes the .la files are annoying but they're not that much of a problem,
> are they?

Depends; I don't have a lot of first-hand experience with problems they
cause in the OE context.  But .la files completely break jhbuild.
Certainly, one could call jhbuild a hack, and it is.  But it's a tool
with absolutely essential properties for people contributing to GNOME.  

Basically jhbuild allows one to e.g.:
$ jhbuild buildone gtk+
$ jhbuild run gedit

Now you have your system version of /usr/bin/gedit linked against the
latest gtk+ from git in /opt/gnome/lib/libgtk.so.  This "two layer"
model is essential for allowing developers to test new code without
risking their /.

The root "feature" of .la files where it can say "if you link against
me, also link against these other libraries" that causes this is much
better implemented by pkg-config.




  parent reply	other threads:[~2013-06-18 16:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-18 14:31 RFC: magic libtool .la removal Burton, Ross
2013-06-18 14:42 ` Phil Blundell
2013-06-18 14:56   ` Burton, Ross
2013-06-18 15:00     ` Colin Walters
2013-06-18 15:05       ` Burton, Ross
2013-06-18 15:47         ` Richard Purdie
2013-06-18 15:52           ` Burton, Ross
2013-06-18 15:54           ` Phil Blundell
2013-06-18 15:59             ` Burton, Ross
2013-06-18 16:05           ` Colin Walters [this message]
2013-06-18 16:39             ` Colin Walters

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=1371571538.3466.27.camel@localhost \
    --to=walters@verbum.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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.