Thanks again Mike for an extended review. Some replies on your comments everything else is directly excepted.
On 17/06/11 05:03, Mike Frysinger wrote:
>> # @ECLASS: fortran-2.eclass
>
> i dont see fortran.eclass. what's with the "-2" ?
There was a fortran eclass, which did completely different things. In
order to not break an ancient package (outside the tree) I decided to
go to the new name, which also underlines the new functionality.
>> DEPEND="virtual/fortran"
>> RDEPEND="${DEPEND}"
>
> i'm not sure that RDEPEND is correct. do all fortran compilers additionally
> require the fortran compiler to be available at runtime ?
I will evaluate this and fix it accordingly. But I see difficulties, if
it is mixed. Best would be to fix that in virtual/fortran
>
>> # internal function
>
> use the @INTERNAL tag and proper eclass documentation
I wasn't aware of that. We are lacking any documentation about the
proper documentation for manpages in all eclass writing guides.
>> (( ${ret} )) || break
>
> a little odd syntax, but i guess it works ...
>
I don't know any other way how I can jump out of the loop. The complete
things simulates the autoconf behavior.
>
> although i wonder why you're not using tc-getF77 ...
Because tc-getF77 is only different to tc-getFC if F77 is set. And this
is tested for before.
>
>> ewarn "The support for EAPI=${EAPI} by the fortran-2.eclass"
>
> why ? it's causing you no real trouble to do so
>
The suggestion was to only support EAPI=4. I don't like this completely
as all fortran packages should directly use the eclass in order to make
it smooth for users. The delay should give some time to come up with
stable versions for all fortran packages at EAPI=4, but allow the use in
every ebuild right away.
> -mike
Thank you very much,
justin
signature.asc
Description: OpenPGP digital signature
