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, 10:37 PM
Ciaran McCreesh
 
Default prune_libtool_files() and pkg-config dependency

On Wed, 29 Aug 2012 18:18:20 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> does it actually ? are DEPEND variables not allowed to be expanded in
> pkg_* src_* funcs ?

Nope. We don't guarantee that the metadata variable gets exported back
to the ebuild environment.

--
Ciaran McCreesh
 
Old 08-29-2012, 10:38 PM
Ciaran McCreesh
 
Default prune_libtool_files() and pkg-config dependency

On Wed, 29 Aug 2012 18:24:45 -0400
Alexandre Rostovtsev <tetromino@gentoo.org> wrote:
> 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.

Naah, I shout at people for thinking that the fancy eclass-mangled
variables will have their mangled values visible within the environment.

--
Ciaran McCreesh
 
Old 08-29-2012, 11:12 PM
Mike Frysinger
 
Default prune_libtool_files() and pkg-config dependency

On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>> does it actually ? are DEPEND variables not allowed to be expanded in
>> pkg_* src_* funcs ?
>
> Nope. We don't guarantee that the metadata variable gets exported back
> to the ebuild environment.

it's not a requirement, so if the PM doesn't export it, that's not a problem.

if [[ ${DEPEND+set} == "set" ]] && ! has virtual/pkgconifg ${DEPEND} ; then
eqawarn "..."
fi
-mike
 
Old 08-30-2012, 07:18 AM
Alec Warner
 
Default prune_libtool_files() and pkg-config dependency

On Thu, Aug 30, 2012 at 1:12 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
>> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>>> does it actually ? are DEPEND variables not allowed to be expanded in
>>> pkg_* src_* funcs ?
>>
>> Nope. We don't guarantee that the metadata variable gets exported back
>> to the ebuild environment.
>
> it's not a requirement, so if the PM doesn't export it, that's not a problem.
>
> if [[ ${DEPEND+set} == "set" ]] && ! has virtual/pkgconifg ${DEPEND} ; then
> eqawarn "..."
> fi
> -mike
>

Shut up and take my money?

-A
 
Old 08-30-2012, 07:41 AM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

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

> On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
> > On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
> >> does it actually ? are DEPEND variables not allowed to be
> >> expanded in pkg_* src_* funcs ?
> >
> > Nope. We don't guarantee that the metadata variable gets exported
> > back to the ebuild environment.
>
> it's not a requirement, so if the PM doesn't export it, that's not a
> problem.
>
> if [[ ${DEPEND+set} == "set" ]] && ! has virtual/pkgconifg
> ${DEPEND} ; then eqawarn "..."
> fi

It may have a semi-random value, I think. Then you could warn for
perfectly valid ebuilds.

--
Best regards,
Michał Górny
 
Old 08-30-2012, 07:43 AM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

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

> 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?

So you haven't seen GNU Makefiles, do you?

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

On Thu, Aug 30, 2012 at 3:41 AM, Michał Górny wrote:
> On Wed, 29 Aug 2012 19:12:01 -0400 Mike Frysinger wrote:
>> On Wed, Aug 29, 2012 at 6:37 PM, Ciaran McCreesh wrote:
>> > On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>> >> does it actually ? are DEPEND variables not allowed to be
>> >> expanded in pkg_* src_* funcs ?
>> >
>> > Nope. We don't guarantee that the metadata variable gets exported
>> > back to the ebuild environment.
>>
>> it's not a requirement, so if the PM doesn't export it, that's not a
>> problem.
>>
>> if [[ ${DEPEND+set} == "set" ]] && ! has virtual/pkgconifg
>> ${DEPEND} ; then eqawarn "..."
>> fi
>
> It may have a semi-random value, I think. Then you could warn for
> perfectly valid ebuilds.

in my quick test it seemed to have a fine value. let's deploy it and
see what kind of reports we get back.

you could also make it do:
libs=$("${pkgconf}" --libs "${tf}") || die
-mike
 
Old 08-30-2012, 10:39 PM
Michał Górny
 
Default prune_libtool_files() and pkg-config dependency

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

> 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

Will it be a better view point if I opened a separate discussion about
putting pkg-config in @system? It could get more attention probably.

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

On Thu, Aug 30, 2012 at 6:39 PM, Michał Górny wrote:
> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>> 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:
>> >> >> > 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
>
> Will it be a better view point if I opened a separate discussion about
> putting pkg-config in @system? It could get more attention probably.

my answer would still be a very strong no
-mike
 
Old 08-31-2012, 12:12 AM
Duncan
 
Default prune_libtool_files() and pkg-config dependency

Mike Frysinger posted on Thu, 30 Aug 2012 19:46:21 -0400 as excerpted:

> On Thu, Aug 30, 2012 at 6:39 PM, Michał Górny wrote:
>> On Wed, 29 Aug 2012 18:18:20 -0400 Mike Frysinger wrote:
>>> 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:
>>> >>
>>> >> 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
>>
>> Will it be a better view point if I opened a separate discussion about
>> putting pkg-config in @system? It could get more attention probably.
>
> my answer would still be a very strong no

Agreed.

Various people have in fact expressed a desire to REDUCE the number of
packages in @system, for various reasons including both the parallel
merge penalty and the bloat on reduced systems. In practice, there's not
a lot of positive movement on actually reducing @system, but at minimum,
unless there's *NO* other choice and in this case there clearly is, we
shouldn't be ADDING packages to @system.

For that reason, while I do see the reason why some would like pkg-config
added to @system, the whole idea's pretty much a non-starter, as it WILL
get a lot of push-back. In theory it /might/ be forceable, but I just
don't see how the cost, political, in time to push thru, and technical
(given the technical reasons listed above), makes it worth pursuing in
the slightest. It's just not worth going there.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 

Thread Tools




All times are GMT. The time now is 01:20 PM.

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