Bugzilla Bug 20048

Just a request to update FFTW to the new and improved version 3.0 that was
recently released at http://www.fftw.org

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Hi BS.

Just a qiuck note, that I noticed this and looking at the upgdare right now.
Its not quite straightforward though - 3.0 is not API compatible with earlier versions. I need to check if it can peacefully coexist with 2.x ones or some stuff will have to be moved around. Any remarks/experience in dealing with new version are appreciated.
Also, 3.0 does not yet support mpi, which is required (optionally) by some packages in portage. Well, it yet remains to be seen if these packages can be cmpiled against new version at all actually..
So, it's gonna take some time..

George

Ya, its not API compatiable.  All the reasons are discussed in the FAQ at the
FFTW site - I guess you saw those.  There's also an upgrade guide which is
straight forward.  I doubt that many programs written for 2 will work with 3. 
However, it seems that 3 is far superior in many respects.  I'm not sure what
the best way to deal with the upgrade - probably in seperate slots.

Thanks George.  I'll post if anything interesting comes up.

BS

debian uses fftw3 as a new package name.
swh-plugins now supprts building against fftw3 .

i would vote for a new package name because fixing all packages which depend
on fftw2 would be too much work ithink.

Created an attachment (id=12657) [details]
ebuild using fftw3 as package name

just in case you want to use fftw3 for package name.
There are some configure options which should be set.

and a different tar file for powerpc.
but this one here already compiles...

Hi Torben, BS.

Sorry I am a bit behind on this one - fftw-3 is not yet really ready to replace fftw-2 in every situation, particularly mpi is not supported yet, so this one was lagging a bit :(. Anyway with the ebuild submitted now I should get to it shortly - within a few days.

The biggest issue is to make sure that fftw-3 and fftw-2 can be installed side-by-side and not overwrite any important files of another one.. Missing that is really a bad thing, as some people might want to use advansed features of fftw-3 but will still need to keep fftw-2 around. 
On the other hand, having done this separation it really doesn't make sense to create another package dir and rename a package because of the change, just stamp new SLOT on it - this is why we introduced SLOTs after all!

>debian uses fftw3 as a new package name.
Well,they are binry distro, so they have different issues with naming and I think they cannot do what we can with SLOTs.
As for amount of work - I don't think there are more than 10 ebuilds in the tree that would need >=fftw-2 replaced by =fftw-2*, this is not such a big deal and can even be scripted pretty easily should there be a need. I'll help you out in that.

Ok, I'll take a look at this ebuild shortly, so more comments will be coming, but I wanted to comment on the naming issue, as it is independent of what I will see in ebuild.

George

Created an attachment (id=13483) [details]
fftw ebuild for 3.0, using slot '3.0' and no MPI

very simple forward port of the 2.1.5 ebuild.  none of the new configure
options
have been investigated.  MPI is disabled as this is not supported in 3.0, yet.

oh, read the history after submitting the patch.  anyway, it looks to me as if
FFTW 2 and 3 can coexist peacefully.  Headers and libraries have, for the most
part, different names.  I'm not sure about 'dfftw.h' but it looks fine.

Created an attachment (id=15050) [details]
Another ebuild for fftw-3.0.1

Was looking at installing fftw-3.0.1 and found this enhancement request ...

I've attached an ebuild which seems to work and doesn't clobber fftw-2.x;
it applies --enable-sse, --enable-sse2 and --enable-3dnow as according to
use variables.

With gcc 3.2.3 and -march=pentium3, -O3 and sse (or sse2) will produce
bad code. The current ebuild has been confirmed to work with gcc 3.2.3,
-march=pentium3 and -march=pentium4 with --enable-sse and --enable-sse2
with the -O2 optimization flag forced. (At least it was fine according to
make check.)

Given the sensitivity on CFLAGS, perhaps a strip-flags is in order?
I'm guessing it really needs to be tested on other architectures/cpus too.

Hi guys.

Thanks for the ebuilds! And sorry for the delay. Looks like bugzila again tried to save on notification emails :(, just got here on a regular sweep.

Anyway, I processed ebuilds, did few cleanups (most notably: function filter-mfpmath has been added to flag-o-matic.eclass and it now should be used for filtering of this one) and committed. Please test.

George

reclosing the bug