FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 08-29-2012, 09:42 PM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

Hello, fellow developers.

I'd like to note that the prune_libtool_files() in eutils.eclass has
a pretty specific dependency on pkg-config. Whenever it is used
in an ebuild, it should depend on virtual/pkgconfig if all
of the following conditions are met:

1. The ebuild installs at least a single static library with
a corresponding .la file,

2. the .la files has no 'shouldnotlink=yes' (i.e. is not a plugin),

3. the .la file has non-empty 'dependency_libs' and/or
'inherited_linker_flags',

4. the '--all' option is not being used.

In other words, pkg-config is only used when no other criteria allows
it to classify the particular .la file as suitable for removal or not.
Sadly, it's rather, ehm, unfriendly to ebuild developers who obviously
don't even read the relevant part.

Do you have any ideas how we can improve that?

One thing that comes into my mind is finally making pkgconfig
a required, implicit part of toolchain (or @system). Since we have
pkgconf now, this is more feasible than before.

--
Best regards,
Michał Górny
 
Old 08-29-2012, 09:50 PM
Mike Frysinger
 
Default prune_libtool_files() and pkg-config dependency

On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
> In other words, pkg-config is only used when no other criteria allows
> it to classify the particular .la file as suitable for removal or not.
> Sadly, it's rather, ehm, unfriendly to ebuild developers who obviously
> don't even read the relevant part.
>
> Do you have any ideas how we can improve that?

before the func executes pkg-config, run `has virtual/pkgconfig
${DEPEND}` and spit an eqawarn if it's not found

> One thing that comes into my mind is finally making pkgconfig
> a required, implicit part of toolchain (or @system). Since we have
> pkgconf now, this is more feasible than before.

i don't think making it part of the toolchain makes sense. i'd rather
not add it to @system simply to keep a few packages from sometimes
failing.
-mike
 
Old 08-29-2012, 10:02 PM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

On Wed, 29 Aug 2012 17:50:16 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
> > In other words, pkg-config is only used when no other criteria
> > allows it to classify the particular .la file as suitable for
> > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
> > developers who obviously don't even read the relevant part.
> >
> > Do you have any ideas how we can improve that?
>
> before the func executes pkg-config, run `has virtual/pkgconfig
> ${DEPEND}` and spit an eqawarn if it's not found

Ciaran will shot at me for doing that.

> > One thing that comes into my mind is finally making pkgconfig
> > a required, implicit part of toolchain (or @system). Since we have
> > pkgconf now, this is more feasible than before.
>
> i don't think making it part of the toolchain makes sense. i'd rather
> not add it to @system simply to keep a few packages from sometimes
> failing.

I'd add it to @system because a lot of packages actually need to DEPEND
on pkgconfig because they use libraries using .pc files. And the number
is going to increase, hopefully.

Also, some people are probably going to try to get some pkgconf support
directly into gcc, in form of '-something libfoo' to make it grab
everything magically, I think.

--
Best regards,
Michał Górny
 
Old 08-29-2012, 10:05 PM
Mike Frysinger
 
Default prune_libtool_files() and pkg-config dependency

On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
> On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
>> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
>> > In other words, pkg-config is only used when no other criteria
>> > allows it to classify the particular .la file as suitable for
>> > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
>> > developers who obviously don't even read the relevant part.
>> >
>> > Do you have any ideas how we can improve that?
>>
>> before the func executes pkg-config, run `has virtual/pkgconfig
>> ${DEPEND}` and spit an eqawarn if it's not found
>
> Ciaran will shot at me for doing that.

it isn't violating anything and can find real bugs. i don't see a problem here.

>> > One thing that comes into my mind is finally making pkgconfig
>> > a required, implicit part of toolchain (or @system). Since we have
>> > pkgconf now, this is more feasible than before.
>>
>> i don't think making it part of the toolchain makes sense. i'd rather
>> not add it to @system simply to keep a few packages from sometimes
>> failing.
>
> I'd add it to @system because a lot of packages actually need to DEPEND
> on pkgconfig because they use libraries using .pc files. And the number
> is going to increase, hopefully.

sure, but keeping things in @system doesn't make much sense:
- there's a penalty (as noted in old threads)
- it isn't actually required at runtime, so it's bloat on reduced systems

> Also, some people are probably going to try to get some pkgconf support
> directly into gcc, in form of '-something libfoo' to make it grab
> everything magically, I think.

if gcc itself runs `pkg-config` to look up libraries from other
packages, then we can add it to DEPEND, but if that's not currently
the case, the dependency doesn't make sense.
-mike
 
Old 08-29-2012, 10:06 PM
Diego Elio Pettenò
 
Default prune_libtool_files() and pkg-config dependency

On 29/08/2012 15:02, Michał Górny wrote:
> I'd add it to @system because a lot of packages actually need to DEPEND
> on pkgconfig because they use libraries using .pc files. And the number
> is going to increase, hopefully.

And yet it shouldn't be part of system because it's not necessary to run
a system, let alone a POSIX system.

> Also, some people are probably going to try to get some pkgconf support
> directly into gcc, in form of '-something libfoo' to make it grab
> everything magically, I think.

You have a future as a comedian.

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 08-29-2012, 10:14 PM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

On Wed, 29 Aug 2012 18:05:19 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
> > On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
> >> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
> >> > In other words, pkg-config is only used when no other criteria
> >> > allows it to classify the particular .la file as suitable for
> >> > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
> >> > developers who obviously don't even read the relevant part.
> >> >
> >> > Do you have any ideas how we can improve that?
> >>
> >> before the func executes pkg-config, run `has virtual/pkgconfig
> >> ${DEPEND}` and spit an eqawarn if it's not found
> >
> > Ciaran will shot at me for doing that.
>
> it isn't violating anything and can find real bugs. i don't see a
> problem here.

It is violating the Holy PMS.

> >> > One thing that comes into my mind is finally making pkgconfig
> >> > a required, implicit part of toolchain (or @system). Since we
> >> > have pkgconf now, this is more feasible than before.
> >>
> >> i don't think making it part of the toolchain makes sense. i'd
> >> rather not add it to @system simply to keep a few packages from
> >> sometimes failing.
> >
> > I'd add it to @system because a lot of packages actually need to
> > DEPEND on pkgconfig because they use libraries using .pc files. And
> > the number is going to increase, hopefully.
>
> sure, but keeping things in @system doesn't make much sense:
> - there's a penalty (as noted in old threads)
> - it isn't actually required at runtime, so it's bloat on reduced
> systems

I think it's practically the same as compiler.

Also, a quick look at !ddep shows over 7000 reverse dependencies. That
looks like a bigger penalty to me.

--
Best regards,
Michał Górny
 
Old 08-29-2012, 10:16 PM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

On Wed, 29 Aug 2012 15:06:16 -0700
Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:

> On 29/08/2012 15:02, Michał Górny wrote:
> > Also, some people are probably going to try to get some pkgconf
> > support directly into gcc, in form of '-something libfoo' to make
> > it grab everything magically, I think.
>
> You have a future as a comedian.

Sir, you are going too far.

--
Best regards,
Michał Górny
 
Old 08-29-2012, 10:17 PM
Diego Elio Pettenò
 
Default prune_libtool_files() and pkg-config dependency

On 29/08/2012 15:16, Michał Górny wrote:
>>> > > Also, some people are probably going to try to get some pkgconf
>>> > > support directly into gcc, in form of '-something libfoo' to make
>>> > > it grab everything magically, I think.
>> >
>> > You have a future as a comedian.
> Sir, you are going too far.

I'm just saying that relying on something like that is a ludicrous notion.

Okay so somebody might actually try to do that, not going to debate that
— people have been out of their mind before.

But developers actually relying on it? I find it very hard, as that
basically means you're introducing build systems that only ever work on
a theoretical GCC 4.8 _and nothing else_.

So can you see what makes me laugh in your statement?

--
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 08-29-2012, 10:18 PM
Mike Frysinger
 
Default prune_libtool_files() and pkg-config dependency

On Wed, Aug 29, 2012 at 6:14 PM, Michał Górny wrote:
> On Wed, 29 Aug 2012 18:05:19 -0400 Mike Frysinger wrote:
>> On Wed, Aug 29, 2012 at 6:02 PM, Michał Górny wrote:
>> > On Wed, 29 Aug 2012 17:50:16 -0400 Mike Frysinger wrote:
>> >> On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
>> >> > In other words, pkg-config is only used when no other criteria
>> >> > allows it to classify the particular .la file as suitable for
>> >> > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
>> >> > developers who obviously don't even read the relevant part.
>> >> >
>> >> > Do you have any ideas how we can improve that?
>> >>
>> >> before the func executes pkg-config, run `has virtual/pkgconfig
>> >> ${DEPEND}` and spit an eqawarn if it's not found
>> >
>> > Ciaran will shot at me for doing that.
>>
>> it isn't violating anything and can find real bugs. i don't see a
>> problem here.
>
> It is violating the Holy PMS.

does it actually ? are DEPEND variables not allowed to be expanded in
pkg_* src_* funcs ?

we could probably add a similar check to autotools.eclass: grep for
PKG_PROG_PKG_CONFIG and check ${DEPEND}

>> >> > One thing that comes into my mind is finally making pkgconfig
>> >> > a required, implicit part of toolchain (or @system). Since we
>> >> > have pkgconf now, this is more feasible than before.
>> >>
>> >> i don't think making it part of the toolchain makes sense. i'd
>> >> rather not add it to @system simply to keep a few packages from
>> >> sometimes failing.
>> >
>> > I'd add it to @system because a lot of packages actually need to
>> > DEPEND on pkgconfig because they use libraries using .pc files. And
>> > the number is going to increase, hopefully.
>>
>> sure, but keeping things in @system doesn't make much sense:
>> - there's a penalty (as noted in old threads)
>> - it isn't actually required at runtime, so it's bloat on reduced
>> systems
>
> I think it's practically the same as compiler.

that isn't a bad view point, but for the purposes of this discussion,
i don't think it's relevant

> Also, a quick look at !ddep shows over 7000 reverse dependencies. That
> looks like a bigger penalty to me.

if we had a @build-system, you might be able to convince me. but we
don't. so the number of packages here doesn't matter as it's an
invalid implicit RDEPEND.
-mike
 
Old 08-29-2012, 10:24 PM
Alexandre Rostovtsev
 
Default prune_libtool_files() and pkg-config dependency

On Thu, 2012-08-30 at 00:02 +0200, Michał Górny wrote:
> On Wed, 29 Aug 2012 17:50:16 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
>
> > On Wed, Aug 29, 2012 at 5:42 PM, Michał Górny wrote:
> > > In other words, pkg-config is only used when no other criteria
> > > allows it to classify the particular .la file as suitable for
> > > removal or not. Sadly, it's rather, ehm, unfriendly to ebuild
> > > developers who obviously don't even read the relevant part.
> > >
> > > Do you have any ideas how we can improve that?
> >
> > before the func executes pkg-config, run `has virtual/pkgconfig
> > ${DEPEND}` and spit an eqawarn if it's not found
>
> Ciaran will shot at me for doing that.

Ciaran only shoots at people for checking $DEPEND at inherit time. I
think that checking $DEPEND in prune_libtool_files, which is called from
src_install, shouldn't be a problem.
 

Thread Tools




All times are GMT. The time now is 04:45 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org