Changes to flag-o-matic's _filter-var
 

Hello everyone,

Here are some minor changes I'd like to propose to flag-o-matic's
_filter-var() to work properly with LDFLAGS.
Without this, things like "-Wl,-O1,--as-needed" won't be affected by any
kind of filter since there are no spaces to separate each flag.

I don't know of any better way to do this, but here's a patch that works
just fine.

Regards,
Tomas
--- /usr/portage/eclass/flag-o-matic.eclass.old 2010-02-17 16:36:55.000000000 -0300
+++ /usr/portage/eclass/flag-o-matic.eclass 2010-02-24 17:16:30.000000000 -0300
@@ -96,14 +96,20 @@
VAR=$1
shift
eval VAL=${${VAR}}
- for f in ${VAL}; do
- for x in "$@"; do
+ for f in ${VAL//,/ }; do
+ for x in ${@//,/ }; do
# Note this should work with globs like -O*
[[ ${f} == ${x} ]] && continue 2
done
eval new[${#new[@]}]=${f}
done
+
eval export ${VAR}=${new[*]}
+
+ if [[ "${VAR}" == "LDFLAGS" ]]; then
+ eval VAL=${${VAR}}
+ eval export ${VAR}=${VAL// /,}
+ fi
}

# @FUNCTION: filter-flags

Changes to flag-o-matic's _filter-var
 

ChIIph posted on Wed, 24 Feb 2010 17:27:21 -0300 as excerpted:

> Here are some minor changes I'd like to propose to flag-o-matic's
> _filter-var() to work properly with LDFLAGS. Without this, things like
> "-Wl,-O1,--as-needed" won't be affected by any kind of filter since
> there are no spaces to separate each flag.

As one of the guys with such an LDFLAGS set, thanks. =:^)

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

Changes to flag-o-matic's _filter-var
 

On Wednesday 24 February 2010 15:27:21 ChIIph wrote:
> Here are some minor changes I'd like to propose to flag-o-matic's
> _filter-var() to work properly with LDFLAGS.
> Without this, things like "-Wl,-O1,--as-needed" won't be affected by any
> kind of filter since there are no spaces to separate each flag.
>
> I don't know of any better way to do this, but here's a patch that works
> just fine.

the func is used by other code where you dont want to screw with commas.
plus, there are a few other ways to trick the system.

my opinion is still:
- bypassing the system is sometimes useful
- use separate -Wl flags and things just work

so thanks, but no thanks
-mike

Changes to flag-o-matic's _filter-var
 

On Sunday 07 March 2010 12:54:34 ChIIph wrote:
> On 03/06/10 23:27, Mike Frysinger wrote:
> > On Wednesday 24 February 2010 15:27:21 ChIIph wrote:
> >> Here are some minor changes I'd like to propose to flag-o-matic's
> >> _filter-var() to work properly with LDFLAGS.
> >> Without this, things like "-Wl,-O1,--as-needed" won't be affected by any
> >> kind of filter since there are no spaces to separate each flag.
> >>
> >> I don't know of any better way to do this, but here's a patch that works
> >> just fine.
> >
> > the func is used by other code where you dont want to screw with commas.
>
> The commas are only added when there's LDFLAGS being changed.

you missed my point. read the whole eclass -- this function isnt only used on
LDFLAGS. your patch opens the door to incorrectly split/mangle other
variables.

> > plus, there are a few other ways to trick the system.
> >
> > my opinion is still:
> > - bypassing the system is sometimes useful
> > - use separate -Wl flags and things just work
>
> Ok, but in the default profiles LDFLAGS are separated with commas, so
> for that second opinion to be possible, I think that should be changed.

i really have no idea what you're talking about. no default profile uses the
multi-linker flag form.

> On the other hand, a lot of us use comma separated flags, so for all of
> us filter-ldflags doesn't work, and what I've modify doesn't mess with
> any of all the other function (or at least I haven't found the case in
> which it does).

then change your LDFLAGS

> Anyway, filter-ldflags doesn't work like it is right now, I'm not saying
> use _my_ code, but use whatever you think it's best to fix this.

i dont see any bug so you're going to have to be more specific
-mike

Changes to flag-o-matic's _filter-var
 

On 03/06/10 23:27, Mike Frysinger wrote:
> On Wednesday 24 February 2010 15:27:21 ChIIph wrote:
>
>> Here are some minor changes I'd like to propose to flag-o-matic's
>> _filter-var() to work properly with LDFLAGS.
>> Without this, things like "-Wl,-O1,--as-needed" won't be affected by any
>> kind of filter since there are no spaces to separate each flag.
>>
>> I don't know of any better way to do this, but here's a patch that works
>> just fine.
>>
> the func is used by other code where you dont want to screw with commas.
>
The commas are only added when there's LDFLAGS being changed.
> plus, there are a few other ways to trick the system.
>
> my opinion is still:
> - bypassing the system is sometimes useful
> - use separate -Wl flags and things just work
>
Ok, but in the default profiles LDFLAGS are separated with commas, so
for that second opinion to be possible, I think that should be changed.

On the other hand, a lot of us use comma separated flags, so for all of
us filter-ldflags doesn't work, and what I've modify doesn't mess with
any of all the other function (or at least I haven't found the case in
which it does).
> so thanks, but no thanks
> -mike
>
Anyway, filter-ldflags doesn't work like it is right now, I'm not saying
use _my_ code, but use whatever you think it's best to fix this.

(Please, don't CC me, I'm already in gentoo-dev list)

Cheers,
Tomas

Changes to flag-o-matic's _filter-var
 

On Sunday 07 March 2010 13:59:25 ChIIph wrote:
> On 03/07/10 14:50, Mike Frysinger wrote:
> > On Sunday 07 March 2010 12:54:34 ChIIph wrote:
> >> [snip]
> >> The commas are only added when there's LDFLAGS being changed.
> >
> > you missed my point. read the whole eclass -- this function isnt only
> > used on LDFLAGS. your patch opens the door to incorrectly split/mangle
> > other variables.
>
> I know, what I wanted to say is that I've tested those changes with more
> than filter-ldflags funtion, and I proposed it here because it works in
> every case.

no, it really doesnt. it took me two seconds to put together an example where
your change corrupted CFLAGS. an unlikely value, but a valid value
nonetheless, which means your proposal is unacceptable on that merit alone.

> >>> plus, there are a few other ways to trick the system.
> >>>
> >>> my opinion is still:
> >>> - bypassing the system is sometimes useful
> >>> - use separate -Wl flags and things just work
> >>
> >> Ok, but in the default profiles LDFLAGS are separated with commas, so
> >> for that second opinion to be possible, I think that should be changed.
> >
> > i really have no idea what you're talking about. no default profile uses
> > the multi-linker flag form.
>
> grep -nR LDFLAGS /usr/portage/profiles/*
> (...)
> /usr/portage/profiles/default/linux/make.defaults:53:LDFLAGS="-Wl,-O1"
> (...)

how is that relevant ? people use `filter-flags -Wl,-O1`, they dont use
`filter-flags -O1`. this is not multiple linker flags combined into one -Wl.
-mike

Changes to flag-o-matic's _filter-var
 

On 03/07/10 14:50, Mike Frysinger wrote:
> On Sunday 07 March 2010 12:54:34 ChIIph wrote:
>
>> [snip]
>> The commas are only added when there's LDFLAGS being changed.
>>
> you missed my point. read the whole eclass -- this function isnt only used on
> LDFLAGS. your patch opens the door to incorrectly split/mangle other
> variables.
>
I know, what I wanted to say is that I've tested those changes with more
than filter-ldflags funtion, and I proposed it here because it works in
every case.
>
>>> plus, there are a few other ways to trick the system.
>>>
>>> my opinion is still:
>>> - bypassing the system is sometimes useful
>>> - use separate -Wl flags and things just work
>>>
>> Ok, but in the default profiles LDFLAGS are separated with commas, so
>> for that second opinion to be possible, I think that should be changed.
>>
> i really have no idea what you're talking about. no default profile uses the
> multi-linker flag form.
>
grep -nR LDFLAGS /usr/portage/profiles/*
(...)
/usr/portage/profiles/default/linux/make.defaults:53:LDFLAGS="-Wl,-O1"
(...)
>
>> On the other hand, a lot of us use comma separated flags, so for all of
>> us filter-ldflags doesn't work, and what I've modify doesn't mess with
>> any of all the other function (or at least I haven't found the case in
>> which it does).
>>
> then change your LDFLAGS
>
Yes, of course, but the not-comma separated form of LDFLAGS isn't the
most commonly used one. So it's not that I'm a case of rebelty :)
>
>> Anyway, filter-ldflags doesn't work like it is right now, I'm not saying
>> use _my_ code, but use whatever you think it's best to fix this.
>>
> i dont see any bug so you're going to have to be more specific
> -mike
>