> I'm okay with that, but maybe have E_PROJECT_ROOT or something similar
> instead? So we can later use branches/ if required.
Good idea.
> > if [[ ! -z "${E_CYTHON}" ]]; then
>
> it it work to have these? I did all the ebuilds using 1, thus for
> consistency I'd keep it as "1". If we go "yes" here we must then
> replace in the ebuilds.
Actually, that's not a problem, as we checking set/not set.
> And my problem with word "yes" is that people will likely diverge to
> "Yes", "YES", "true"... keeping it as a number allow us to later
> just use shell's numberic expressions such as -ne 0.
Right, but is there any sense? This is true/false flags and,
traditionally, in shell scripting, when it's set it is 'yes'.
Also, if you have to get real boolean, you should use
FLAG=true/false
And then check ${FLAG} && - that's why true/false exist.
Actually, that change makes not so much sense, just styling.
> this is bad. Python may have checks, but no make files :-(
Then ebuild should replace src_test with it's own version. Eclass
version than whould never be called. Maybe, if you think that whole
class of python packages don't need testing at all - maybe we should
make E_NO_TEST, than? It might be also usefull for packages with some
broken tests, util this tests are fixed.
> useless new line :-)
Oops, sorry =)
> why do you rather use += instead of the old code? Is it acceptable in
> other shells (ie: will it always work)?
>
Portage harddepend on bash. No bash - no portage. So use bash syntax
freely - it's features used too frequently in ebuild(1) itself and in
other part of portage. And this syntax much nicer =)
> > @@ -286,8 +278,6 @@ efl_src_install() {
> ...
> > -
> > - find "${D}/usr/share/doc/${PF}" -name .svn -type d
> > -exec rm -rf '{}' \; 2>/dev/null
> ...
> > - find "${D}/usr/share/doc/${PF}" -name .svn -type d -exec rm
> > -rf '{}' \; 2>/dev/null
> > fi
> > +
> > + find "${D}" -name .svn -type d -exec rm -rf '{}' \; 2>/dev/null
> > }
>
> I'd like to have explicit delete based on the things we know would be
> mis-copied. But this is fine. Do you think it is worth to move to this
> new way?
Em? Delete is done after installation process, so containes of "${D}"
would not be changed anymore. So why we need to remove .svn in
particular directories using some complex flag checks, while we can just
remove .svn in whole "${D}" tree. I suppose there whould be no 'valid'
.svn dirs ocasionly. If there whould be no .svn's - nothing would be
deleted.
Also, it would be nice to check if something is really copied. Actually
dodoc * will never catch anything starting from dot ('.'). If this could
be introduced by recursive do* functions or by e build-system - than it
could be introduced in any place, not just in docs. Imo.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
