On Thu, Mar 4, 2010 at 7:18 AM, Andrian Nord <nightn...@gmail.com> wrote:
> There is some style fixes (like 1 -> yes), minor bug fixes (WORKDIR can
> contain spaces, so should be in quotes), some var name changed and some
> useless vars removed.
>
> Also - whole autopoint stuff, but checking for autopoint needness,
> replaced with eautopoint call, as autotools eclass already do all work
> of logging and message emmiting. Checks now are done more carefully, to
> prevent grep emiting warnings about not-exising files.
>
> New flags:
>        E_OLD_PROJECT: for supporting old projects that still works. I'm
>        not sure if this is really needed, we have no packages using it
>        anymore, but, at least, it makes no harm. Still, we hand't
>        ported all packages yes, and we still have a few packages from
>        OLD with old eclass.

I'm okay with that, but maybe have E_PROJECT_ROOT or something similar
instead? So we can later use branches/ if required.


>  if [[ ! -z "${E_CYTHON}" ]]; then
> -       E_PYTHON="1"
> +       E_PYTHON="yes"
...
> -       E_NO_VISIBILITY="1"
> +       E_NO_VISIBILITY="yes"

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.

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.


>  efl_src_test() {
> -       if [[ -z "${E_PYTHON}" ]]; then
> -               if use test; then
> -                       emake -j1 check || die "Make check failed. see above 
> for details"
> -               fi
> -       fi
> +       emake -j1 check || die "Make check failed. see above for details"
>  }

this is bad. Python may have checks, but no make files :-(



>  # the stupid gettextize script prevents non-interactive mode, so we hax it
>  gettext_modify() {
>        [[ -z "${E_NO_NLS}" ]] || return 0
>        use nls || return 0
> +

useless new line :-)

>  efl_src_configure() {
> -       if [[ -z "${E_PYTHON}" ]]; then
> -               if [[ -x ${ECONF_SOURCE:-.}/configure ]]; then
> -                       [[ -z "${E_NO_NLS}" ]] && MY_ECONF="${MY_ECONF} 
> $(use_enable nls)"
> -                       [[ -z "${E_NO_DOC}" ]] && MY_ECONF="${MY_ECONF} 
> $(use_enable doc)"
> -                       [[ -z "${E_NO_DISABLE_STATIC}" ]] && 
> MY_ECONF="${MY_ECONF} --disable-static"
> +       if [[ -z "${E_PYTHON}" ]] && [[ -x ${ECONF_SOURCE:-.}/configure ]]; 
> then
> +               [[ -z "${E_NO_NLS}" ]] && MY_ECONF+=" $(use_enable nls)"
> +               [[ -z "${E_NO_DOC}" ]] && MY_ECONF+=" $(use_enable doc)"
> +               [[ -z "${E_NO_DISABLE_STATIC}" ]] && MY_ECONF+=" 
> --disable-static"

why do you rather use += instead of the old code? Is it acceptable in
other shells (ie: will it always work)?

> @@ -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?


BR,


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

------------------------------------------------------------------------------
Download Intel&#174; 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

Reply via email to