| 1 |
Hello, |
| 2 |
|
| 3 |
El dom, 09-11-2008 a las 15:39 +0300, Peter Volkov escribió: |
| 4 |
> |
| 5 |
> 1. Functions we have now are much more flexible then proposed arrays. Do |
| 6 |
> I need to think of some example of code that is impossible to do with |
| 7 |
> arrays but still possible with functions? |
| 8 |
> |
| 9 |
|
| 10 |
The same concern was raised in the default src_install proposal. Making |
| 11 |
default functions a bit more flexible doesn't mean we need default |
| 12 |
functions which cover every possible case, that's just impossible. |
| 13 |
|
| 14 |
> |
| 15 |
> At the same time this new syntax make some things worse: |
| 16 |
|
| 17 |
> |
| 18 |
> 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad |
| 19 |
> practice of using patches instead of sed. |
| 20 |
|
| 21 |
As shown in the proposal, this variable is already used in many eclasses |
| 22 |
and it has been proven useful. |
| 23 |
|
| 24 |
I'm not sure the existence of PATCHES is promoting any kind of "patch |
| 25 |
abuse". As far as I know, it's more common the concern about abusing sed |
| 26 |
for things that should be patched rather than the other way. |
| 27 |
|
| 28 |
But, in any case, both methods would still be available: |
| 29 |
|
| 30 |
src_prepare { |
| 31 |
epatch "${FILESDIR}"/some-stuff.patch |
| 32 |
sed -i -e "s:FOO:BAR:g" Makefile |
| 33 |
} |
| 34 |
|
| 35 |
would still be correct. |
| 36 |
|
| 37 |
If someone is using the PATCHES variable like this: |
| 38 |
|
| 39 |
PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... ) |
| 40 |
|
| 41 |
a sed call would be easy to add if needed as follows: |
| 42 |
|
| 43 |
PATCHES=( 'stome-stuff.patch' 'more-patches.patch' ... ... ... ) |
| 44 |
|
| 45 |
src_prepare() { |
| 46 |
default |
| 47 |
sed -i -e "s:FOO:BAR:g" Makefile |
| 48 |
} |
| 49 |
|
| 50 |
|
| 51 |
It's quite straight-forward. |
| 52 |
|
| 53 |
> 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus |
| 54 |
> easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES, |
| 55 |
> btw). (highlighting helps here but does not makes that variables easier |
| 56 |
> to read or type in?) |
| 57 |
|
| 58 |
This is the easier part to address. If these names are a problem, other |
| 59 |
names can be used. For example, what it's called |
| 60 |
DEFAULT_SRC_INSTALL_DOCS in this proposal, it's called just DOCS in |
| 61 |
others. |
| 62 |
|
| 63 |
If people likes this approach better, then similar names can be chosen |
| 64 |
for the rest of proposed variables. For example: |
| 65 |
|
| 66 |
DEFAULT_SRC_PREPARE_PATCHES -> PATCHES, EPATCHES... |
| 67 |
DEFAULT_SRC_CONFIGURE_ENABLES -> ECONF_ENABLES |
| 68 |
DEFAULT_SRC_COMPILE_PARAMS -> EMAKE_PARAMS, EMAKE_EXTRA_PARAMS... |
| 69 |
|
| 70 |
Anyway, it'd be better if people focus on discussing the actual |
| 71 |
functionality rather than the chosen names. |
| 72 |
|
| 73 |
> |
| 74 |
> 4. "it also conflates multiple concepts into a single variable name (the |
| 75 |
> function name, whether it's USE-dependent, and how the configure flag is |
| 76 |
> passed)." (-- Donnie Berkholz [6]) |
| 77 |
|
| 78 |
ECONF_USE_ENABLES might solve that problem. |
| 79 |
|
| 80 |
> |
| 81 |
> 5. "One of the great things about ebuilds is that they're very natural |
| 82 |
> to write in most cases, if you can manage to build the program by hand. |
| 83 |
> Raising this barrier of entry for questionable benefit seems like a bad |
| 84 |
> idea." (-- Donnie Berkholz [7]) |
| 85 |
|
| 86 |
Functions would still be overridable. And, in fact, they will need to be |
| 87 |
overriden in many cases. There's no change there. With respect this |
| 88 |
"barrier", it already exists with the many eclasses we have. |
| 89 |
|
| 90 |
Regards, |
| 91 |
-- |
| 92 |
Santiago Moisés Mola |
| 93 |
Jabber: cooldwind@×××××.com | GPG: AAD203B5 |
Archives