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. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
