Attached patch includes the following modifications.
* Updates to LAPACKE 3.4.0 are added.
* Two interfaces to LAPACK's libtmg (liblapacke_tmg) and GotoBLAS's LAPACK (liblapacke_goto )are added.
* "check" target is added.
- This port was tested with porttools 0.99 and tinderbox 3.4.1 (9.0R and 8.2R-p5) on FreeBSD 9.0R on amd64.
- Currently the port requires older distfile for testing.
- Please notice that the version number jumps from LAPACKE 1.0.0.009 to 3.4.0.
Because LAPACKE is now inside LAPACK, LAPACKE has the same version number than LAPACK.
So 3.4.0 for the latest release .
Fix: Patch attached with submission follows:
I'll take it.
Hi! Mr. b.f.,
CC: Dr. Nakata,
Would you please commit the attached patch?
I think that update of math/lapacke should not be delayed any longer.
Although simple update of lapacke is not long term solution for
minimizing maintenance cost, but interim alternative,
I think that "update of lapacke" and "integration to math/lapack"
should not be regarded as single problem.
The latter appears difficult at this time.
Because lapacke consists of interfaces to lapack, tmglib and xlapack.
If we use lapack's default makefile the resulting library contains all
of these interfaces, and it will have large number of dependencies.
However, if I write a makefile for splitting the library the maintenance
cost remains high even if lapacke is integrated to lapack port.
Moreover integration of lapacke to math/lapack is not preferable at
feature freeze phase.
As I asked you previously, if you have any plan,
please send me (and maho@) a patch after this PR is committed.
On 3/17/12, Eijiro Shibusawa <firstname.lastname@example.org> wrote:
> Hi! Mr. b.f.,
> CC: Dr. Nakata,
> Would you please commit the attached patch?
> I think that update of math/lapacke should not be delayed any longer.
> Although simple update of lapacke is not long term solution for
> minimizing maintenance cost, but interim alternative,
> I think that "update of lapacke" and "integration to math/lapack"
> should not be regarded as single problem.
> The latter appears difficult at this time.
> Because lapacke consists of interfaces to lapack, tmglib and xlapack.
> If we use lapack's default makefile the resulting library contains all
> of these interfaces, and it will have large number of dependencies.
> However, if I write a makefile for splitting the library the maintenance
> cost remains high even if lapacke is integrated to lapack port.
> Moreover integration of lapacke to math/lapack is not preferable at
> feature freeze phase.
It is actually not as hard as you suggest (in fact, it is probably
easier than making separate Makefiles, as you have had to do) if you
simply add an OPTION and patches including changes like r1210 that are
in the lapack repository. But you are right that it is not possible
to do this during the feature freeze. I was finishing a patch to
integrate the two ports, and was hoping to avoid having to do a
interim update, but I was sidetracked by all the people asking for
immediate updates of fftw, R, etc. I apologize for the delay. I
don't expect the feature freeze to last very long, but if you prefer
to do this now, then I will check (and most likely commit) your patch
bf 2012-03-20 02:00:32 UTC
FreeBSD ports repository
math/lapacke Makefile distinfo
math/lapacke/files Makefile Makefile.lib patch-make.inc
math/lapacke/files patch-src+Makefile patch-utils+Makefile
update to 3.4.0
Submitted by: E. Shibusawa (maintainer)
Feature safe: yes
Revision Changes Path
1.5 +66 -19 ports/math/lapacke/Makefile
1.2 +4 -2 ports/math/lapacke/distinfo
1.2 +2 -1 ports/math/lapacke/files/Makefile
1.2 +237 -42 ports/math/lapacke/files/Makefile.lib
1.1 +25 -0 ports/math/lapacke/files/Makefile.libtmg (new)
1.3 +13 -13 ports/math/lapacke/files/patch-make.inc
1.2 +0 -293 ports/math/lapacke/files/patch-src+Makefile (dead)
1.2 +0 -11 ports/math/lapacke/files/patch-utils+Makefile (dead)
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"