On 02/01/16 04:15, Michał Górny wrote:
> On Sat, 2 Jan 2016 03:57:59 +1100
> Michael Palimaka <[email protected]> wrote:
>
>> On 02/01/16 03:41, Michał Górny wrote:
>>> ---
>>> eclass/scons-utils.eclass | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/eclass/scons-utils.eclass b/eclass/scons-utils.eclass
>>> index a2a6884..e1b3a1b6 100644
>>> --- a/eclass/scons-utils.eclass
>>> +++ b/eclass/scons-utils.eclass
>>> @@ -1,4 +1,4 @@
>>> -# Copyright 1999-2012 Gentoo Foundation
>>> +# Copyright 1999-2015 Gentoo Foundation
>>> # Distributed under the terms of the GNU General Public License v2
>>> # $Id$
>>>
>>> @@ -17,19 +17,19 @@
>>> # EAPI=4
>>> #
>>> # src_configure() {
>>> -# myesconsargs=(
>>> +# MYSCONS=(
>>> # CC="$(tc-getCC)"
>>> # $(use_scons nls ENABLE_NLS)
>>> # )
>>> # }
>>> #
>>> # src_compile() {
>>> -# escons
>>> +# escons "${MYSCONS[@]}"
>>> # }
>>> #
>>> # src_install() {
>>> # # note: this can be DESTDIR, INSTALL_ROOT, ... depending on package
>>> -# escons DESTDIR="${D}" install
>>> +# escons "${MYSCONS[@]}" DESTDIR="${D}" install
>>> # }
>>> # @CODE
>>>
>>>
>>
>> What is the benefit of MYSCONS vs myesconsargs? The latter seems to be
>> more consistent with other eclasses (mycmakeargs, myqmakeargs, ...)
>
> It's shorter and follows the convention of keeping global variables
> uppercase.
The five-character saving is lost by then requiring "${myconf[@]}" to be
written twice.
> Consistency with bad example set by one eclass is not a good argument.
> In fact, cmake-utils sets a very bad example of enforcing declarative
> model over function-oriented ebuilds which results in really absurd
> src_configure() implementations.
>
> src_configure() {
> local mycmakeargs=(
> ...
> )
> cmake-utils_src_configure
> }
>
> vs
>
> src_configure() {
> local myconf=(
> ...
> )
> ecmake "${myconf[@]}"
> }
>
I don't see the absurdity.
