Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
Dnia 2013-08-20, o godz. 13:01:34 Michał Górny mgo...@gentoo.org napisał(a): Due to the widespread breakage in the tree noted in bug #480892 [1], and mis-design of multilib-minimal.eclass, we'd like to put some more work into getting einstalldocs() ready for EAPI 6. When it's mostly defined, we'd like to backport it to eutils.eclass so that we could use it to fix the existing breakages. But for that, we'd really prefer if we had a final spec for it so that the EAPI switch could be as simple as disabling the function in eutils. [snip] Since the Council has approved the final implementation written in this thread, I have committed it into eutils.eclass now. Please test it, and feel free to convert your eclasses to use it as soon as you confirm that it works well for you. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
Dnia 2013-08-21, o godz. 12:33:14
Ulrich Mueller u...@gentoo.org napisał(a):
On Wed, 21 Aug 2013, Michał Górny wrote:
Proposed implementation follows:
einstalldocs() {
if ! declare -p DOCS /dev/null ; then
local d
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
The first pair of quotes is not needed.
done
elif [[ $(declare -p DOCS) == declare -a * ]] ; then
[[ ${DOCS[@]} ]] dodoc -r ${DOCS[@]}
I'd test for [[ ${#DOCS[@]} -gt 0 ]] here, but presumably that's a
matter of taste.
else
[[ ${DOCS} ]] dodoc -r ${DOCS}
fi
if [[ $(declare -p HTML_DOCS) == declare -a * ]] ; then
This will emit an error message if HTML_DOCS is unset. So:
if [[ $(declare -p HTML_DOCS 2/dev/null) == declare -a * ]] ; then
dohtml -r ${HTML_DOCS[@]}
No test for empty array here?
I don't think it's anywhere near necessary. Since HTML_DOCS has no
default, why would people set it to empty array? Well, unless someone
plays with appending...
Then I'll better add it.
elif [[ ${HTML_DOCS} ]]; then
dohtml -r ${HTML_DOCS}
Make this the same as the DOCS logic, i.e.:
else
[[ ${HTML_DOCS} ]] dohtml -r ${HTML_DOCS}
fi
Maybe add a return 0 here?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
Dnia 2013-08-21, o godz. 14:49:45
Pacho Ramos pa...@gentoo.org napisał(a):
El mié, 21-08-2013 a las 14:35 +0200, Ulrich Mueller escribió:
On Wed, 21 Aug 2013, Pacho Ramos wrote:
Could appending to DOCS be allowed? I have seen a lot of time of me
needing to install all docs manually only to add a doc file over
default DOCS. Would be interesting to simply do: DOCS+=( otherfile )
instead of needing to specify all files handled by the install
function
We discussed this in bug 449806 already. Problems that need to be
solved:
- If we want to keep support for both array and whitespace-separated
list then we can't preset a global variable.
- How do we distinguish between DOCS being unset (i.e. install default
docs) and DOCS being empty (i.e. don't install anything)?
- We could introduce some special syntax like a __default__ marker,
but do we want such in-band signalling?
Well, the last comment by mgorny in bug report after some suggestions
rised there made me think I should wait for the einstalldocs thing :/
Yes, for something like:
src_install() {
...
einstalldocs
dodoc FOO
}
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
Second version:
einstalldocs() {
if ! declare -p DOCS /dev/null ; then
local d
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
done
elif [[ $(declare -p DOCS) == 'declare -a'* ]] ; then
[[ ${DOCS[@]} ]] dodoc -r ${DOCS[@]}
else
[[ ${DOCS} ]] dodoc -r ${DOCS}
fi
if [[ $(declare -p HTML_DOCS 2/dev/null) == 'declare -a'* ]] ; then
[[ ${HTML_DOCS[@]} ]] dohtml -r ${HTML_DOCS[@]}
else
[[ ${HTML_DOCS} ]] dohtml -r ${HTML_DOCS}
fi
return 0
}
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Thu, 22 Aug 2013, Michał Górny wrote: Second version: Looks good to me. One minor non-technical point: Could you use double quotes instead of single quotes around declare -a, for better readability? Last time we had single quotes they ended up as backquotes in the devmanual and from there in some eclasses (see bug 444832). Ulrich
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
Dnia 2013-08-20, o godz. 13:01:34
Michał Górny mgo...@gentoo.org napisał(a):
Hello,
Due to the widespread breakage in the tree noted in bug #480892 [1],
and mis-design of multilib-minimal.eclass, we'd like to put some more
work into getting einstalldocs() ready for EAPI 6.
When it's mostly defined, we'd like to backport it to eutils.eclass so
that we could use it to fix the existing breakages. But for that, we'd
really prefer if we had a final spec for it so that the EAPI switch
could be as simple as disabling the function in eutils.
Therefore, I'd like to open a final discussion for the features set
that is intended to be included in it, and it's name.
[1]:https://bugs.gentoo.org/show_bug.cgi?id=480892
Proposed implementation follows:
einstalldocs() {
if ! declare -p DOCS /dev/null ; then
local d
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
done
elif [[ $(declare -p DOCS) == declare -a * ]] ; then
[[ ${DOCS[@]} ]] dodoc -r ${DOCS[@]}
else
[[ ${DOCS} ]] dodoc -r ${DOCS}
fi
if [[ $(declare -p HTML_DOCS) == declare -a * ]] ; then
dohtml -r ${HTML_DOCS[@]}
elif [[ ${HTML_DOCS} ]]; then
dohtml -r ${HTML_DOCS}
fi
}
It's based on EAPI 4 src_install(). I've added support for DOCS=()
and DOCS='', HTML_DOCS, and made dodoc recursive per Pinkbyte's
request. In this form, it's suitable replacement for what's
in autotools-utils distutils-r1.
It should be noted that if we're to backport it to all old EAPIs,
'dodoc -r' needs te be conditional to EAPI 4+.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Wed, 21 Aug 2013, Michał Górny wrote:
Proposed implementation follows:
einstalldocs() {
if ! declare -p DOCS /dev/null ; then
local d
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
The first pair of quotes is not needed.
done
elif [[ $(declare -p DOCS) == declare -a * ]] ; then
[[ ${DOCS[@]} ]] dodoc -r ${DOCS[@]}
I'd test for [[ ${#DOCS[@]} -gt 0 ]] here, but presumably that's a
matter of taste.
else
[[ ${DOCS} ]] dodoc -r ${DOCS}
fi
if [[ $(declare -p HTML_DOCS) == declare -a * ]] ; then
This will emit an error message if HTML_DOCS is unset. So:
if [[ $(declare -p HTML_DOCS 2/dev/null) == declare -a * ]] ; then
dohtml -r ${HTML_DOCS[@]}
No test for empty array here?
elif [[ ${HTML_DOCS} ]]; then
dohtml -r ${HTML_DOCS}
Make this the same as the DOCS logic, i.e.:
else
[[ ${HTML_DOCS} ]] dohtml -r ${HTML_DOCS}
fi
Maybe add a return 0 here?
}
Ulrich
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On 08/20/2013 01:01 PM, Michał Górny wrote: Hello, Due to the widespread breakage in the tree noted in bug #480892 [1], and mis-design of multilib-minimal.eclass, we'd like to put some more work into getting einstalldocs() ready for EAPI 6. What mis-design?
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Wed, 21 Aug 2013, Ulrich Mueller wrote: On Wed, 21 Aug 2013, Michał Górny wrote: Proposed implementation follows: elif [[ $(declare -p DOCS) == declare -a * ]] ; then I forgot about another issue pointed out by Arfrever some time ago. We may want to change the above to declare -a* (note the removed space) because of https://bugs.gentoo.org/show_bug.cgi?id=444740#c4. Ulrich
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
El mié, 21-08-2013 a las 11:52 +0200, Michał Górny escribió:
Dnia 2013-08-20, o godz. 13:01:34
Michał Górny mgo...@gentoo.org napisał(a):
Hello,
Due to the widespread breakage in the tree noted in bug #480892 [1],
and mis-design of multilib-minimal.eclass, we'd like to put some more
work into getting einstalldocs() ready for EAPI 6.
When it's mostly defined, we'd like to backport it to eutils.eclass so
that we could use it to fix the existing breakages. But for that, we'd
really prefer if we had a final spec for it so that the EAPI switch
could be as simple as disabling the function in eutils.
Therefore, I'd like to open a final discussion for the features set
that is intended to be included in it, and it's name.
[1]:https://bugs.gentoo.org/show_bug.cgi?id=480892
Proposed implementation follows:
einstalldocs() {
if ! declare -p DOCS /dev/null ; then
local d
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
done
elif [[ $(declare -p DOCS) == declare -a * ]] ; then
[[ ${DOCS[@]} ]] dodoc -r ${DOCS[@]}
else
[[ ${DOCS} ]] dodoc -r ${DOCS}
fi
if [[ $(declare -p HTML_DOCS) == declare -a * ]] ; then
dohtml -r ${HTML_DOCS[@]}
elif [[ ${HTML_DOCS} ]]; then
dohtml -r ${HTML_DOCS}
fi
}
It's based on EAPI 4 src_install(). I've added support for DOCS=()
and DOCS='', HTML_DOCS, and made dodoc recursive per Pinkbyte's
request. In this form, it's suitable replacement for what's
in autotools-utils distutils-r1.
It should be noted that if we're to backport it to all old EAPIs,
'dodoc -r' needs te be conditional to EAPI 4+.
Could appending to DOCS be allowed? I have seen a lot of time of me
needing to install all docs manually only to add a doc file over
default DOCS. Would be interesting to simply do:
DOCS+=( otherfile )
instead of needing to specify all files handled by the install function
Thanks a lot
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2013 01:01 PM, Michał Górny wrote: Hello, Due to the widespread breakage in the tree noted in bug #480892 [1], and mis-design of multilib-minimal.eclass, we'd like to put some more work into getting einstalldocs() ready for EAPI 6. Ok, I'm too lazy to wait for a reply, so here you go Let's check what misdesign is: * creating eclasses with too many phases and those wrapped a thousand times, so no one really knows how it works anymore and ebuild writers are confused and often miss things; other devs have already complained about that obscurity * creating python eclasses that rely so heavily on useflags that it causes a lot of pain for users because of blockers (just read #gentoo) and adding/removing python version and then adding another bunch of python_single_foo* which cause even more useless rebuilds for users * creating a distutils eclass that fails for some packages, because it doesn't let you control how setup.py is called properly * updating vcs-snapshot eclass to drop support for an archive type, because the author is unable to make his code improvement work with it * creating multilib eclasses that are widely untested and dumping all the slow migration pain including multilib-specific bugs, countless blockers users have to deal with and all the emul-linux-x86-* updating stuff on everyone not really misdesign, but rather misbehavior: * refusing to slow down when told that your solutions may cause problems for other developers * refusing to work with other devs who demand an alternative implementation * trying to force other people to use a solution that they feel is not fit, because they want minimum reliance on eclasses which autotools-utils is NOT (and for the record, you do not follow PMS standard there) * requesting features for other peoples eclasses and then blaming them for misdesign, although YOU have even REVIEWED the changes If you keep on with this behavior, then I hope you know where that leads. I don't mind strong discussions and most points in the first chapter will not make me say it was the wrong choice (everyone knows that I am all pro migrating), but you are becoming someone people do not want to work with. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSFKhuAAoJEFpvPKfnPDWzNX4H/AlQ+neoEUfnE4MCuyQKVifZ 1iMva9NjoO3xCQcSjyYmq0tOBeKbRbErdy0G2vca4JkX1fZnDiEQe+NCzMRIJBKl rTHYiDAaVg/ZTP+f1E0FXoPgS1t6NCjF/hKelniUGoYcxSKMJ5nA+z0/JuKQfzGF bsEkT44XXpliZAFOjuxSFMBl7NdCkt9XMBrX5tIdQj38XaVtnelvJII6TJ+hUsnj 8MVyui3d030X96Ezxe2k2kiqZRbqYCYQkU44zPeh/3Ns0O7mJ0/c0EidW1PcCvcZ ZS31GsPJV7zsl3HVlHuNmJDf3+WcNc8p06fRfG7iCS3nLGmsAEZBOc1y0oWvIVo= =PfTn -END PGP SIGNATURE-
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
El mié, 21-08-2013 a las 13:45 +0200, hasufell escribió: On 08/20/2013 01:01 PM, Michał Górny wrote: Hello, Due to the widespread breakage in the tree noted in bug #480892 [1], and mis-design of multilib-minimal.eclass, we'd like to put some more work into getting einstalldocs() ready for EAPI 6. Ok, I'm too lazy to wait for a reply, so here you go Let's check what misdesign is: [...] I would really encourage people to keep talking about concrete technical issue. There is no need to blame on anybody and continuing this discussion in that terms won't help at all and won't resolve that conflict. To resolve that conflict (if possible), I would simply try to let things calm down again before replying too soon while involved parties are furious, as it will only cause more and more damage Thanks a lot :)
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Wed, 21 Aug 2013, Pacho Ramos wrote: Could appending to DOCS be allowed? I have seen a lot of time of me needing to install all docs manually only to add a doc file over default DOCS. Would be interesting to simply do: DOCS+=( otherfile ) instead of needing to specify all files handled by the install function We discussed this in bug 449806 already. Problems that need to be solved: - If we want to keep support for both array and whitespace-separated list then we can't preset a global variable. - How do we distinguish between DOCS being unset (i.e. install default docs) and DOCS being empty (i.e. don't install anything)? - We could introduce some special syntax like a __default__ marker, but do we want such in-band signalling? Ulrich
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
El mié, 21-08-2013 a las 14:35 +0200, Ulrich Mueller escribió: On Wed, 21 Aug 2013, Pacho Ramos wrote: Could appending to DOCS be allowed? I have seen a lot of time of me needing to install all docs manually only to add a doc file over default DOCS. Would be interesting to simply do: DOCS+=( otherfile ) instead of needing to specify all files handled by the install function We discussed this in bug 449806 already. Problems that need to be solved: - If we want to keep support for both array and whitespace-separated list then we can't preset a global variable. - How do we distinguish between DOCS being unset (i.e. install default docs) and DOCS being empty (i.e. don't install anything)? - We could introduce some special syntax like a __default__ marker, but do we want such in-band signalling? Ulrich Well, the last comment by mgorny in bug report after some suggestions rised there made me think I should wait for the einstalldocs thing :/
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Wed, 21 Aug 2013, Michał Górny wrote: elif [[ $(declare -p DOCS) == declare -a * ]] ; then Thinking about it again, the pattern matching (already present in default_src_install of EAPI 4) is brittle and relies on the output of declare -p whose exact format is undocumented. Maybe we could change the test for an array to the following? elif ! declare +a DOCS /dev/null; then This seems to work fine in bash versions 3.2 and 4.2. And behaviour is well documented in the bash reference manual [1]: | Using `+' instead of `-' turns off the attribute instead, with the | exceptions that `+a' may not be used to destroy an array variable | [...] | | The return status is zero unless [...] an attempt is made to turn | off array status for an array variable, [...] Ulrich [1] http://www.gnu.org/software/bash/manual/bashref.html#Bash-Builtins
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/08/13 07:45 AM, hasufell wrote: On 08/20/2013 01:01 PM, Michał Górny wrote: Hello, Due to the widespread breakage in the tree noted in bug #480892 [1], and mis-design of multilib-minimal.eclass, we'd like to put some more work into getting einstalldocs() ready for EAPI 6. what misdesign? The mis-design is that for some reason the default_src_install (and therefore the default EAPI4+ DOCS= handler) is being triggered regardless of whether multilib_src_install, or multilib_src_install_all are being overridden/customized. Possibly this is true for an override of src_install() too (or at least, the src_install that would still call the appropriate phase funcs from multilib-minimal), but I don't think I checked that so this would need to be confirmed. Probably what needs to be done is that the original default_src_install behaviour only occurs in multilib_src_install_all() and also only occurs when that phase func is not re-defined in an ebuild. But this is just a guess. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIUyAEACgkQ2ugaI38ACPD/owD/ea8xL8zZKLtsWCZbjnym5TWf yZr3EXEtK6r0JdCvdUwBAIn2zXqAOp9jsoaVtD7IvKsXxHVs+24BTfFLet/HcRfk =hEKl -END PGP SIGNATURE-
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
20.08.2013 17:22, Sergey Popov пишет: 20.08.2013 17:02, Michał Górny пишет: Is there a future-eapi bug open for it? If not, please open one. I will, thanks Here it is: https://bugs.gentoo.org/show_bug.cgi?id=481980 -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Wed, 21 Aug 2013, I wrote: Maybe we could change the test for an array to the following? elif ! declare +a DOCS /dev/null; then I retract this suggestion. It doesn't work because of issues with local and global scope. Sorry for the noise. Ulrich
[gentoo-dev] Staging 'einstalldocs' for EAPI 6
Hello,
Due to the widespread breakage in the tree noted in bug #480892 [1],
and mis-design of multilib-minimal.eclass, we'd like to put some more
work into getting einstalldocs() ready for EAPI 6.
When it's mostly defined, we'd like to backport it to eutils.eclass so
that we could use it to fix the existing breakages. But for that, we'd
really prefer if we had a final spec for it so that the EAPI switch
could be as simple as disabling the function in eutils.
Therefore, I'd like to open a final discussion for the features set
that is intended to be included in it, and it's name.
[1]:https://bugs.gentoo.org/show_bug.cgi?id=480892
Future EAPI bug: https://bugs.gentoo.org/show_bug.cgi?id=459692
1. Name
- einstalldocs
-- probably the least confusing one, consistent with emake
- edocs
-- but what does it do to the docs?
- dodocs
-- do* prefix suggests it accepts list of files like doins,
-- single-letter difference from 'dodoc' is confusing
- dodoc (without arguments)
-- two different behaviors of a single function -- confusing
-- wouldn't be feasible for backporting
2. Support for HTML_DOCS
https://bugs.gentoo.org/show_bug.cgi?id=468310
It's used consistently in a few eclasses. if we put it into
the default, we can replace the eclass implementations with this one.
3. Support DOCS=() / DOCS='' to disable dodoc
https://bugs.gentoo.org/show_bug.cgi?id=463736
Well, this one is mostly what the bug is about. I think we should just
do it. Implementation could be discussed a bit though.
For example, hasufell has suggested checking ${DOCS// /} to support
DOCS=' ' as well. IMO we shouldn't be supporting such a weird
mistakes.
4. Globbing support in DOCS array
https://bugs.gentoo.org/show_bug.cgi?id=394211
radhermit suggested this to have equivalent set of features in DOCS
as scalar and DOCS as array. IMO it's PITA to implement and not worth
the effort.
5. Appending to DOCS
https://bugs.gentoo.org/show_bug.cgi?id=449806
That is, ability to install default docs + listed files. I doubt that
it's worth the effort, especially for einstalldocs.
What are your thoughts?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Tue, 20 Aug 2013, Michał Górny wrote:
1. Name
- einstalldocs
-- probably the least confusing one, consistent with emake
Go for it.
2. Support for HTML_DOCS
I've no strong opinion about this one.
But if you are going to add it, then please support both array and
whitespace separated list, so that it's consistent with DOCS.
3. Support DOCS=() / DOCS='' to disable dodoc
Yes, please. The EAPI 4 default_src_install is broken that it doesn't
handle this case.
For example, hasufell has suggested checking ${DOCS// /} to support
DOCS=' ' as well.
Looks like over-engineering to me. Are there any use cases for it?
4. Globbing support in DOCS array
5. Appending to DOCS
Creeping featurism. Define an explicit src_install if you need any of
these, and I'm sure it will improve readability of your ebuild.
Ulrich
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On 08/20/2013 01:54 PM, Ulrich Mueller wrote:
For example, hasufell has suggested checking ${DOCS// /} to support
DOCS=' ' as well.
Looks like over-engineering to me. Are there any use cases for it?
No, just caution, so we don't have to realize that our default
src_install is broken again.
4. Globbing support in DOCS array
5. Appending to DOCS
Creeping featurism. Define an explicit src_install if you need any of
these, and I'm sure it will improve readability of your ebuild.
I don't see how defining phases explicitly improves readability which
even increases chances of overwriting phases by accident and having
further complications especially in multilib eclasses.
DOCS=( foo* )
looks pretty readable to me
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
20.08.2013 16:08, hasufell пишет: I don't see how defining phases explicitly improves readability which even increases chances of overwriting phases by accident and having further complications especially in multilib eclasses. DOCS=( foo* ) looks pretty readable to me I am not for nor against this feature, but it would be nice to add support for directories in DOCS variable. Cause, overwriting install phase just to install directory with docs(instead of files) seems a bit odd for me. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
Dnia 2013-08-20, o godz. 16:26:10 Sergey Popov pinkb...@gentoo.org napisał(a): 20.08.2013 16:08, hasufell пишет: I don't see how defining phases explicitly improves readability which even increases chances of overwriting phases by accident and having further complications especially in multilib eclasses. DOCS=( foo* ) looks pretty readable to me I am not for nor against this feature, but it would be nice to add support for directories in DOCS variable. Cause, overwriting install phase just to install directory with docs(instead of files) seems a bit odd for me. Is there a future-eapi bug open for it? If not, please open one. I myself don't have anything against plain 'dodoc -r'. But I wonder if this isn't going to end up with people considering 'what if my directory has .svn/CVS in it?' -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
Dnia 2013-08-20, o godz. 14:08:51 hasufell hasuf...@gentoo.org napisał(a): On 08/20/2013 01:54 PM, Ulrich Mueller wrote: 4. Globbing support in DOCS array 5. Appending to DOCS Creeping featurism. Define an explicit src_install if you need any of these, and I'm sure it will improve readability of your ebuild. I don't see how defining phases explicitly improves readability which even increases chances of overwriting phases by accident and having further complications especially in multilib eclasses. DOCS=( foo* ) looks pretty readable to me It doesn't work as expected. 'foo*' gets expanded in global scope, that is in pwd. So it would have to be: DOCS=( 'foo*' ) And then we'd have to do some ugly hackery to whitespace-safe expand that in einstalldocs. Scary. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
20.08.2013 17:02, Michał Górny пишет:
Is there a future-eapi bug open for it? If not, please open one.
I will, thanks
I myself don't have anything against plain 'dodoc -r'. But I wonder if
this isn't going to end up with people considering 'what if my
directory has .svn/CVS in it?'
{ecvs,esvn}_clean FTGJ :-)
--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/08/13 08:08 AM, hasufell wrote: On 08/20/2013 01:54 PM, Ulrich Mueller wrote: 4. Globbing support in DOCS array 5. Appending to DOCS Creeping featurism. Define an explicit src_install if you need any of these, and I'm sure it will improve readability of your ebuild. I don't see how defining phases explicitly improves readability which even increases chances of overwriting phases by accident and having further complications especially in multilib eclasses. DOCS=( foo* ) looks pretty readable to me It'd also help if we were to ever want to add things to DOCS by eclass, via DOCS+=. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlITc4YACgkQ2ugaI38ACPCYFAD/bNg+vbuieyX2shFNzv5bDIUn NgTVcZCbIHoHKV1bis0A/0Q87yBZg2XQISbvhX8yEr0LUeSn6CM9mT/brFZNxTXP =IFau -END PGP SIGNATURE-
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Tue, 20 Aug 2013 13:01:34 +0200
Michał Górny mgo...@gentoo.org wrote:
3. Support DOCS=() / DOCS='' to disable dodoc
https://bugs.gentoo.org/show_bug.cgi?id=463736
Well, this one is mostly what the bug is about. I think we should just
do it. Implementation could be discussed a bit though.
For example, hasufell has suggested checking ${DOCS// /} to support
DOCS=' ' as well. IMO we shouldn't be supporting such a weird
mistakes.
See https://bugs.gentoo.org/show_bug.cgi?id=481664
This is already allowed if one reads PMS the way that makes it work.
