[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Donnie Berkholz]

On 14:58 Wed 03 Oct     , Caleb Tennis (caleb) wrote:
> 1.1                  x11-libs/qt/qt-4.3.2.ebuild
> 
> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-libs/qt/qt-4.3.2.ebuild?rev=1.1&view=markup
> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/x11-libs/qt/qt-4.3.2.ebuild?rev=1.1&content-type=text/plain

> 	case ${CHOST} in
> 		*-freebsd*|*-dragonfly*)
> 			spec="freebsd" ;;
> 		*-openbsd*)
> 			spec="openbsd" ;;
> 		*-netbsd*)
> 			spec="netbsd" ;;
> 		*-darwin*)
> 			spec="darwin" ;;
> 		*-linux-*|*-linux)
> 			spec="linux" ;;
> 		*)
> 			die "Unknown CHOST, no platform choosed."
> 	esac
> 
> 	CXX=$(tc-getCXX)
> 	if [[ ${CXX/g++/} != ${CXX} ]]; then
> 		spec="${spec}-g++"
> 	elif [[ ${CXX/icpc/} != ${CXX} ]]; then
> 		spec="${spec}-icc"
> 	else
> 		die "Unknown compiler ${CXX}."
> 	fi

Try being a little smarter with both CHOST and CXX -- only add an 
exception if the spec name isn't equal to the variable value.

spec=$(echo ${CHOST} | cut -d- -f3)
spec=${spec%%[0-9]*}
spec=${spec}-$(tc-getCXX)

For icc, you should just be able to use 'icc'; it's installed that for 
quite a while. That way you don't require any special cases here.

> 	cd ${S}
> 	epatch ${FILESDIR}/qt-4.2.3-hppa-ldcw-fix.patch
> 	cd ${S}/mkspecs/$(qt_mkspecs_dir)
> 	cd ${S}/mkspecs/common
> 	cd ${S}/qmake
> 	cd ${S}
> 	make INSTALL_ROOT=${D} install_subtargets || die
> 	make INSTALL_ROOT=${D} install_qmake || die
> 	make INSTALL_ROOT=${D} install_mkspecs || die
> 		make INSTALL_ROOT=${D} install_htmldocs || die
> 	make INSTALL_ROOT=${D} install_translations || die
> 	sed -i -e "s:${S}/lib:${QTLIBDIR}:g" ${D}/${QTLIBDIR}/*.la
> 	sed -i -e "s:${S}/lib:${QTLIBDIR}:g" ${D}/${QTLIBDIR}/*.prl
> 	sed -i -e "s:${S}/lib:${QTLIBDIR}:g" ${D}/${QTLIBDIR}/pkgconfig/*.pc
> 	sed -i -e "s:${S}/bin:${QTBINDIR}:g" ${D}/${QTLIBDIR}/pkgconfig/*.pc
> 	mv ${D}/${QTLIBDIR}/pkgconfig/*.pc ${D}/${QTPCDIR}
> 	doins ${FILESDIR}/qt4/*.desktop

Quote variables that can have spaces in them: D, S, T, WORKDIR,
FILESDIR, DESTDIR, ROOT.

If emake doesn't work, please add a comment to that effect.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Caleb Tennis]

> Try being a little smarter with both CHOST and CXX -- only add an
> exception if the spec name isn't equal to the variable value.
>
> spec=$(echo ${CHOST} | cut -d- -f3)
> spec=${spec%%[0-9]*}
> spec=${spec}-$(tc-getCXX)

The bsd folks are the ones who added these conditionals.  I'd like for them to make
the necessary changes, because I don't want to risk screwing up their
builds/installs.

> For icc, you should just be able to use 'icc'; it's installed that for
> quite a while. That way you don't require any special cases here.

This change was made based on a bug a user filed (albiet, some time ago).  Again,
I'd prefer if someone who can test it with icc can make the appropriate change.

> Quote variables that can have spaces in them: D, S, T, WORKDIR,
> FILESDIR, DESTDIR, ROOT.

Should be fixed thanks.

> If emake doesn't work, please add a comment to that effect.

Will test and fix or comment as needed, thanks.


Caleb

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Steve Long]

Donnie Berkholz wrote:

> spec=$(echo ${CHOST} | cut -d- -f3)
> 
You can do this without resort to an external process:
IFS=-
read _ _ spec _ <<< "$CHOST"
unset IFS
- or you can do:
IFS=-
arr=($CHOST)
unset IFS
spec=${arr[2]}
- which is useful if you don't know how many elements there are.
(IFS wouldn't affect the second assignment, but it's safest to unset it as
soon as you've got whatever you needed with the non-default, ime.)

Note that quoting is needed in the first one and will break the second one.
In first instance the words are split before being read, and then the
separator is not used at all, so first _ takes the whole line til the new
line delimiter. In the second, it's the usual quote situation, so with
quotes it's one parameter, without it's split according to IFS.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Roy Marples]

On Thu, 2007-10-04 at 05:03 +0100, Steve Long wrote:
> Donnie Berkholz wrote:
> 
> > spec=$(echo ${CHOST} | cut -d- -f3)
> > 
> You can do this without resort to an external process:
> IFS=-
> read _ _ spec _ <<< "$CHOST"
> unset IFS
> - or you can do:
> IFS=-
> arr=($CHOST)
> unset IFS
> spec=${arr[2]}

See, another use of bash arrays just because you can?
IFS=-
set -- ${CHOST}
spec=$2

Works fine in bash - and other shells.

You need to preserve IFS when changing it, however. Unless of course,
you're doing this in a function so you can just local IFS=-

Here's a snippet from b2's localmount init script.

IFS=${IFS} SIFS=${IFS-y}
FS=$IFS:
for x in ${NO_UMOUNTS} ${RC_NO_UMOUNTS} ; do
   no_umounts="${no_umounts}|${x}"
one
if [ "${SIFS}" = "y" ] ; then
   IFS=$OIFS
else
   unset IFS
fi

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Donnie Berkholz]

On 07:49 Thu 04 Oct     , Roy Marples wrote:
> On Thu, 2007-10-04 at 05:03 +0100, Steve Long wrote:
> > Donnie Berkholz wrote:
> > 
> > > spec=$(echo ${CHOST} | cut -d- -f3)
> > > 
> > You can do this without resort to an external process:
> > IFS=-
> > read _ _ spec _ <<< "$CHOST"
> > unset IFS
> > - or you can do:
> > IFS=-
> > arr=($CHOST)
> > unset IFS
> > spec=${arr[2]}
> 
> See, another use of bash arrays just because you can?

Sure. If there's no requirement to stick to portable sh, why shouldn't 
we use whatever features of bash we like?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Roy Marples]

On Thu, 2007-10-04 at 00:32 -0700, Donnie Berkholz wrote:
> Sure. If there's no requirement to stick to portable sh, why shouldn't 
> we use whatever features of bash we like?

You can use whatever bash specific features you like.
Just don't expect them to behave entirely the same way across versions.

What do you gain from using a bashism there anyway? Is it that it looks
nice? Or is it something else?

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roy Marples wrote:
> On Thu, 2007-10-04 at 05:03 +0100, Steve Long wrote:
>> Donnie Berkholz wrote:
>>
>>> spec=$(echo ${CHOST} | cut -d- -f3)
>>>
>> You can do this without resort to an external process:
>> IFS=-
>> read _ _ spec _ <<< "$CHOST"
>> unset IFS
>> - or you can do:
>> IFS=-
>> arr=($CHOST)
>> unset IFS
>> spec=${arr[2]}
> 
> See, another use of bash arrays just because you can?
> IFS=-
> set -- ${CHOST}
> spec=$2
> 
> Works fine in bash - and other shells.

Do I understand correctly that this resets any arguments that might have been
passed to the function this happens to be in?

Marijn

- --
Marijn Schouten (hkBst), Gentoo Lisp project
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHBLgZp/VmCx0OL2wRAi3wAKCAe/AWWNdTgLDrXxyTBdr4MxW4awCcCsQ7
To3EzKgOPonDwvAmypVdIrA=
=tZYe
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Roy Marples]

On Thu, 2007-10-04 at 11:53 +0200, Marijn Schouten (hkBst) wrote:
> > See, another use of bash arrays just because you can?
> > IFS=-
> > set -- ${CHOST}
> > spec=$2
> > 
> > Works fine in bash - and other shells.
> 
> Do I understand correctly that this resets any arguments that might have been
> passed to the function this happens to be in?

Yes it does.

Most people write their functions like so

foo() {
    local this=$1 that=$2

And then use $this and $that for greater clarity. So if they do that
then resetting the positional parameters is a non issue as they've
already been saved.

Thanks

Roy

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Steve Long]

Roy Marples wrote:

> On Thu, 2007-10-04 at 05:03 +0100, Steve Long wrote:
>> Donnie Berkholz wrote:
>> 
>> > spec=$(echo ${CHOST} | cut -d- -f3)
>> > 
>> You can do this without resort to an external process:
>> IFS=-
>> read _ _ spec _ <<< "$CHOST"
>> unset IFS
>> - or you can do:
>> IFS=-
>> arr=($CHOST)
>> unset IFS
>> spec=${arr[2]}
> 
> See, another use of bash arrays just because you can?
No, because it's expressive and it works cleanly. If it's an important array
I can refer to it throughout a script without having to reallocate storage
or forcing the shell to expand it for a function call. More a case of: hey,
you know you can do this with arrays and IFS? Ain't it neat? :D

> IFS=-
> set -- ${CHOST}
> spec=$2
> 
> Works fine in bash - and other shells.
>
Yeah fine, there are kludgy workarounds; so what? Doesn't mean I want to use
them. ;)
In actual fact, I'd be more likely to use parameter expansion than set, eg:
spec=${CHOST#*-*-} # chop first two fields off so spec is fields 3 on
spec=${spec%%-*} # chop all but first off so left with just field 3
..which I believe works in sh[1] as well. The point for me, however, is not
whether sh can be kludged to do something, it's what the most efficient
ways to do something in scripts are. Whether you use pe, read or an array,
avoiding externals leads to quicker scripts.[2]

The exceptions are where the external provides functionality you can't
easily reproduce in bash (like ed or find) or where it can perform the job
more efficiently (like awk on large files.) It really depends on the task,
but learning to do break the problem down for builtins a) is fun ;P and b)
teaches generic programming, transferable to other languages.

> You need to preserve IFS when changing it, however. Unless of course,
> you're doing this in a function so you can just local IFS=-
>
Perhaps, although at the level of an ebuild or a script I am writing, the
default IFS is what I start with. If it were a function for a sourced
library, then yeah there's a valid argument for preserving the caller's
IFS. (I prefer to work with an assumption of default, ie spaces tabs and
newlines.)

> Here's a snippet from b2's localmount init script.
(I'm guessing the first line lost it's first character?) 
> IFS=${IFS} SIFS=${IFS-y}
> FS=$IFS:
> for x in ${NO_UMOUNTS} ${RC_NO_UMOUNTS} ; do
>    no_umounts="${no_umounts}|${x}"
> one
> if [ "${SIFS}" = "y" ] ; then
>    IFS=$OIFS
> else
>    unset IFS
> fi
> 
I wouldn't bother with the SIFS stuff, I'd just do:
OIFS=$IFS
..blah blah..
IFS=$OIFS

FS=$IFS: looks dangerous as well; how can you know what IFS contains (this
seems to hope it's whitespace) on function entry? (Which is the whole point
of saving it.) IFS=$' \t\n:' or summat would be better.

[1] http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
[2] http://forum.bash-hackers.org/index.php?topic=51.0 -- teh power of
extglob ;P


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Donnie Berkholz]

On 13:34 Fri 05 Oct     , Steve Long wrote:
> Roy Marples wrote:
> > IFS=-
> > set -- ${CHOST}
> > spec=$2
> > 
> > Works fine in bash - and other shells.
> >
> Yeah fine, there are kludgy workarounds; so what? Doesn't mean I want to use
> them. ;)
> In actual fact, I'd be more likely to use parameter expansion than set, eg:
> spec=${CHOST#*-*-} # chop first two fields off so spec is fields 3 on
> spec=${spec%%-*} # chop all but first off so left with just field 3
> ..which I believe works in sh[1] as well. The point for me, however, is not
> whether sh can be kludged to do something, it's what the most efficient
> ways to do something in scripts are. Whether you use pe, read or an array,
> avoiding externals leads to quicker scripts.[2]

That parameter workaround wouldn't work, because CHOST may also contain 
just 3 fields, as it does on Gentoo/BSD. Unpack a portage tarball and 
look at the make.conf's if you're curious.

Avoiding externals at the cost of added complexity on something that 
only gets called one time certainly qualifies as premature optimization.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Steve Long]

Donnie Berkholz wrote:
> On 13:34 Fri 05 Oct     , Steve Long wrote:
>> In actual fact, I'd be more likely to use parameter expansion than set,
>> eg: spec=${CHOST#*-*-} # chop first two fields off so spec is fields 3 on
>> spec=${spec%%-*} # chop all but first off so left with just field 3
>> ..which I believe works in sh[1] as well. The point for me, however, is
>> not whether sh can be kludged to do something, it's what the most
>> efficient ways to do something in scripts are. Whether you use pe, read
>> or an array, avoiding externals leads to quicker scripts.[2]
> 
> That parameter workaround wouldn't work, because CHOST may also contain
> just 3 fields, as it does on Gentoo/BSD. Unpack a portage tarball and
> look at the make.conf's if you're curious.
>
Then the second expansion would have no effect.

> Avoiding externals at the cost of added complexity on something that
> only gets called one time certainly qualifies as premature optimization.
> 
True enough. It might be more relevant for eclasses, or maybe only for
actual bash scripts.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in x11-libs/qt: ChangeLog qt-4.3.2.ebuild

[Donnie Berkholz]

On 00:41 Sat 06 Oct     , Steve Long wrote:
> Donnie Berkholz wrote:
> > On 13:34 Fri 05 Oct     , Steve Long wrote:
> >> In actual fact, I'd be more likely to use parameter expansion than set,
> >> eg: spec=${CHOST#*-*-} # chop first two fields off so spec is fields 3 on
> >> spec=${spec%%-*} # chop all but first off so left with just field 3
> >> ..which I believe works in sh[1] as well. The point for me, however, is
> >> not whether sh can be kludged to do something, it's what the most
> >> efficient ways to do something in scripts are. Whether you use pe, read
> >> or an array, avoiding externals leads to quicker scripts.[2]
> > 
> > That parameter workaround wouldn't work, because CHOST may also contain
> > just 3 fields, as it does on Gentoo/BSD. Unpack a portage tarball and
> > look at the make.conf's if you're curious.
> >
> Then the second expansion would have no effect.

Good point.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list