[DESCRIBE CHANGES] fftw3 needs USE_FORTRAN in order to generate fortran shim. with USE_FORTRAN # nm -na work/fftw-3.1.3/.libs/libfftw3f.a |grep sfftw_destroy_plan 00000e9c T sfftw_destroy_plan_ without USE_FORTRAN # nm -na work/fftw-3.1.3/.libs/libfftw3f.a |grep sfftw_destroy_plan # Note that math/fftw has USE_FORTRAN defined for fortran shim reasons. Version compiled without USE_FORTRAN -rw-r--r-- 1 root wheel 261650 Apr 30 13:29 work/fftw-2.1.5/fftw/.libs/libfftw.a # ls -lta /usr/local/lib/libfftw.a -rw-r--r-- 1 root wheel 263402 Jan 9 18:37 /usr/local/lib/libfftw.a Port maintainer (ahze@FreeBSD.org) is cc'd. Generated with FreeBSD Port Tools 0.77
Responsible Changed From-To: freebsd-ports-bugs->ahze Over to maintainer (via the GNATS Auto Assign Tool)
db 2009-05-15 11:58:18 UTC FreeBSD ports repository Modified files: math/fftw3 Makefile math/fftw3-float Makefile math/fftw3-long Makefile Log: - fftw3 needs USE_FORTRAN in order to generate fortran shim. [1] - Two week maintainer timeout. PR: ports/134115 [1] Revision Changes Path 1.6 +1 -1 ports/math/fftw3-float/Makefile 1.9 +1 -1 ports/math/fftw3-long/Makefile 1.53 +2 -1 ports/math/fftw3/Makefile _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed Committed due to maintainer timeout.
Are there any ports in the tree that require math/fftw3 to be built with the Fortran shims? If there are no such ports, can we please change the default setting for the FORTRAN option to "Off"? Setting it to "On" has unexpectedly introduced a large, cumbersome dependency on lang/gcc43 that doesn't seem to be needed by a majority of users, and is causing a lot of confusion and delay. If there are ports in the tree that require the shim, could we still set it to "Off" by default and create a slave port that has the setting "On" for use by those ports? Thanks, b.
Hi, I have cc itetcu. On Sat, Jun 13, 2009 at 10:18:07PM -0700, b. f. wrote: > Are there any ports in the tree that require math/fftw3 to be built > with the Fortran shims? Yes. > If there are no such ports, can we please change the default setting > for the FORTRAN > option to "Off"? Setting it to "On" has unexpectedly introduced a > large, cumbersome > dependency on lang/gcc43 that doesn't seem to be needed by a majority > of users, and is > causing a lot of confusion and delay. If there are ports in the tree > that require the shim, > could we still set it to "Off" by default and create a slave port that > has the setting "On" for > use by those ports? I have already discussed this with itetcu (now a portmgr) and am still waiting for a response. It turns out, that math/fftw (without the 3) has USE_FORTRAN defaulted to ON. Note that math/fftw is also listed having ahze as MAINTAINER. No one has complained about massive confusion and delay from math/fftw compiling in the fortran shims, so it appeared reasonable to turn on the fortran shim compilation for fftw3 as well. This is being investigated now. 1) why fftw has not caused massive confusion 2) why fftw is not using OPTIONS the same way as fftw3, they both should be. I'm still waiting for portmgr for guidance. > > Thanks, > b. > Note that ahze has been MIA for a very long time (6 months?) which has complicated working on this problem. It might be time for portmgr to reset Maintainer. - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db
On Sun, 14 Jun 2009 09:27:02 -0400 Diane Bruce <db@db.net> wrote: > Hi, > > I have cc itetcu. > > On Sat, Jun 13, 2009 at 10:18:07PM -0700, b. f. wrote: > > Are there any ports in the tree that require math/fftw3 to be built > > with the Fortran shims? > > Yes. > > > If there are no such ports, can we please change the default setting > > for the FORTRAN option to "Off"? Setting it to "On" has > > unexpectedly introduced a large, cumbersome dependency on > > lang/gcc43 that doesn't seem to be needed by a majority of users, > > and is causing a lot of confusion and delay. If there are ports in > > the tree that require the shim, could we still set it to "Off" by > > default and create a slave port that has the setting "On" for > > use by those ports? > > I have already discussed this with itetcu (now a portmgr) > and am still waiting for a response. > > It turns out, that math/fftw (without the 3) has USE_FORTRAN > defaulted to ON. Note that math/fftw is also listed having ahze as > MAINTAINER. No one has complained about massive confusion and delay > from math/fftw compiling in the fortran shims, so it appeared > reasonable to turn on the fortran shim compilation for fftw3 as well. > This is being investigated now. 1) why fftw has not caused massive > confusion 2) why fftw is not using OPTIONS the same way as fftw3, > they both should be. > > I'm still waiting for portmgr for guidance. IMO, for fftw3: - do a slave port for USE_FORTRAN case - default FORTRAN to off in master port The problem is that a lot of ports (including more that half of KDE and Gnome) depend on fftw3 and have no use for fortran so I think it's better not to force fortran on them :-) (The fact that people are actually complaining because they need to set some sysctl to build gcc, which is required because of fortran is true, but Then either do the same for fftw or try to see if the ports that uses it wouldn't work with fftw3 and if yes expire fftw. (Ping those maintainers). > Note that ahze has been MIA for a very long time (6 months?) which has > complicated working on this problem. It might be time for portmgr to > reset Maintainer. He seems to be available for various types of work on and off, so we can't reset him, but show me some patches ;-) -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B
On 6/14/09, Ion-Mihai Tetcu <itetcu@freebsd.org> wrote: > On Sun, 14 Jun 2009 09:27:02 -0400 > Diane Bruce <db@db.net> wrote: > >> Hi, >> >> I have cc itetcu. >> >> On Sat, Jun 13, 2009 at 10:18:07PM -0700, b. f. wrote: >> > Are there any ports in the tree that require math/fftw3 to be built >> > with the Fortran shims? >> >> Yes. >> >> > If there are no such ports, can we please change the default setting >> > for the FORTRAN option to "Off"? Setting it to "On" has >> > unexpectedly introduced a large, cumbersome dependency on >> > lang/gcc43 that doesn't seem to be needed by a majority of users, >> > and is causing a lot of confusion and delay. If there are ports in >> > the tree that require the shim, could we still set it to "Off" by >> > default and create a slave port that has the setting "On" for >> > use by those ports? >> >> I have already discussed this with itetcu (now a portmgr) >> and am still waiting for a response. >> >> It turns out, that math/fftw (without the 3) has USE_FORTRAN >> defaulted to ON. Note that math/fftw is also listed having ahze as >> MAINTAINER. No one has complained about massive confusion and delay >> from math/fftw compiling in the fortran shims, so it appeared >> reasonable to turn on the fortran shim compilation for fftw3 as well. >> This is being investigated now. 1) why fftw has not caused massive >> confusion 2) why fftw is not using OPTIONS the same way as fftw3, >> they both should be. >> 1) fftw is only used in a few (42 by my count), mostly peripheral or specialized ports in math, science, and comms. Probably the people using it already have other Fortran related ports, and didn't notice the difference. In contrast, as Ion-Mihai has already mentioned, full installations of the two most popular desktops require fftw3, and many other ports as well: 715, by my count. Most of these are general-use ports that drag it in through a dependency on libsamplerate or pulseaudio, and they're used by a wide variety of people that _don't_ normally install Fortran-related ports, and _did_ notice the difference. That includes people who use packages, because USE_FORTRAN now adds run-time dependencies, as it normally should (but didn't until recent changes). As mentioned, this hit people who use ii386 hard, because the default sizes for some kernel resources were in some cases too low to compile gcc43 WITH_JAVA, which is the default on that platform, requiring people to modify these settings at boot time, or to choose non-default build options. For other people, it resulted in a sudden large increase in the build-time, network traffic, and disk space used for seemingly unrelated ports. Regardless of the current state of fftw, I I think that the person who committed this change to fftw3 should have thought about the fairly clear consequences of doing this, and made some changes. I have heard a lot of complaints and questions, on and off the mailing lists. 2) Maintenance on this port is slack, because there is no designated maintainer. Originally it was used by people who probably had a Fortran compiler installed, or maybe even when it was in the base system, and nobody has bothered to change it since then. It would be nice to have the option there too, but I was specifically referring to fftw3, which is a different case, with wider consequences. >> I'm still waiting for portmgr for guidance. > > IMO, for fftw3: > - do a slave port for USE_FORTRAN case > - default FORTRAN to off in master port Yes, please. > > The problem is that a lot of ports (including more that half of KDE and > Gnome) depend on fftw3 and have no use for fortran so I think it's > better not to force fortran on them :-) > (The fact that people are actually complaining because they need to set > some sysctl to build gcc, which is required because of fortran is true, but > > Then either do the same for fftw or try to see if the ports that uses > it wouldn't work with fftw3 and if yes expire fftw. (Ping those > maintainers). > >> Note that ahze has been MIA for a very long time (6 months?) which has >> complicated working on this problem. It might be time for portmgr to >> reset Maintainer. > > He seems to be available for various types of work on and off, so we > can't reset him, but show me some patches ;-) > I don't mind making a slave port for fftw3, or even changing fftw. But before I do so, back to one of my original questions: will any port break if the Fortran shims aren't built and installed? Diane, did you make this change because another port needed it? Any of these, perhaps?: cad/gmsh graphics/cimg math/freefem++ math/freemat math/octave math/octave-devel math/gretl Regards, b. > > -- > IOnut - Un^d^dregistered ;) FreeBSD "user" > "Intellectual Property" is nowhere near as valuable as "Intellect" > FreeBSD committer -> itetcu@FreeBSD.org, PGP Key ID 057E9F8B493A297B >
On Sun, Jun 14, 2009 at 03:51:18PM -0700, b. f. wrote: > On 6/14/09, Ion-Mihai Tetcu <itetcu@freebsd.org> wrote: > > On Sun, 14 Jun 2009 09:27:02 -0400 > > Diane Bruce <db@db.net> wrote: > > > >> Hi, > >> ... > > 1) fftw is only used in a few (42 by my count), mostly peripheral or > specialized ports in > math, science, and comms. Probably the people using it already have Not quite. gkrellmss-0.5_4|/usr/ports/audio/gkrellmss|/usr/local|A plugin for GKrellM with a VU meter showing left/right channel audio|/usr/ports/audio/gkrellmss/pkg-desc |ports@FreeBSD.org|audio|esound-0.2.41 fftw-2.1.5_5 gcc-4.3.4_20090312 gettext-0 gramofile-1.6P_8|/usr/ports/audio/gramofile|/usr/local|Audio recording and tick/scratch reduction for e.g. vinyl records|/usr/ports/audio/gramofile/pkg-descr|nox@FreeBSD.org|audio|fftw-2.1.5_5 gcc-4.3.4_20090312 gettext-0.17_1 gmake-3.81_3 squash-1.0_4|/usr/ports/audio/squash|/usr/local|Learning console-based MP3/OGG player|/usr/ports/audio/squash/pkg-descr|matthias.andree@gmx.de|audio|fftw-2.1.5_5 flac-1.2.1 gcc-4.3.4_20090312 gettext-0.17_1 gmake-3.81_3 id3lib-3.8.3_5 libao gmfsk-0.6_7|/usr/ports/comms/gmfsk|/usr/local|The Gnome MFSK terminal program|/usr/ports/comms/gmfsk/pkg-descr|carl@stagecraft.cx|comms audio hamradio|ORBit2-2.14.17 atk-1.24.0 avahi-app-0.6.24_1 bash-4.0.10_2 bitstream-vera-1.10_4 cairo-1. flowdesigner-0.9.1_1|/usr/ports/devel/flowdesigner|/usr/local|A free (GPL) "data flow oriented" development environment|/usr/ports/devel/flowdesigner/pkg-descr| p5-Chart-Graph-3.2_1|/usr/ports/graphics/p5-Chart-Graph|/usr/local|Perl extensio The point is, yes there are quite a few scientific ports but not all of them are. gramofile looks useful to me in fact. I've been wanting to transcribe some old vinyl records. > 2) Maintenance on this port is slack, because there is no designated maintainer. fftw3 and fftw are both maintained by ahze. > Originally it was used by people who probably had a Fortran compiler I'm not so sure. I suspect a lot of these users simply installed gcc43 which compiles the fortran compiler by default. I bet a lot of these ports do _not_ require fortran at all. This is opening another can of worms. It's quite possible a lot of ports are requiring gcc4 already, Itetcu and I will be investigating. > referring to fftw3, > which is a different case, with wider consequences. Sure. But from my point of view, it was quite reasonable to copy exactly what was in fftw, when you take a casual look at the non scientific ports that already require fftw-2 and when you notice that there are a number of ports that already require gcc4 (which compiles fortran by default). > >> I'm still waiting for portmgr for guidance. portmgr and I are in discussion now. > > > > IMO, for fftw3: > > - do a slave port for USE_FORTRAN case > > - default FORTRAN to off in master port > > Yes, please. Of these 42 some odd ports how many could simply use fftw3 instead, how many need fortran at all? > > Gnome) depend on fftw3 and have no use for fortran so I think it's > > better not to force fortran on them :-) > > He seems to be available for various types of work on and off, so we > > can't reset him, but show me some patches ;-) > > Fair enough, I will work up patches for fftw3, fftw and we will see what breaks. If we need to override ahze for now, that will happen, soonish. > But before I do so, back to one of my original questions: will any > port break if the Fortran shims aren't built That's the other fascinating contents of this can of worms portmgr and I are now worried about, since there are a number of ports that use fftw- which defines USE_FORTRAN, will turning off USE_FORTRAN in this port break any dependancies on fftw-? > and installed? Diane, did you make this change because another port needed it? > > Any of these, perhaps?: No, wsjt in fact. wspr (new port) is waiting for this fix as well. In any case, hold your horses, it is being looked at. - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db
On 6/14/09, Diane Bruce <db@db.net> wrote: > On Sun, Jun 14, 2009 at 03:51:18PM -0700, b. f. wrote: >> On 6/14/09, Ion-Mihai Tetcu <itetcu@freebsd.org> wrote: >> > On Sun, 14 Jun 2009 09:27:02 -0400 >> > Diane Bruce <db@db.net> wrote: >> > >> >> Hi, >> >> > ... >> >> 1) fftw is only used in a few (42 by my count), mostly peripheral or >> specialized ports in >> math, science, and comms. Probably the people using it already have > > Not quite. > > gkrellmss-0.5_4|/usr/ports/audio/gkrellmss|/usr/local|A plugin for GKrellM > with a VU meter showing left/right channel > audio|/usr/ports/audio/gkrellmss/pkg-desc > |ports@FreeBSD.org|audio|esound-0.2.41 fftw-2.1.5_5 gcc-4.3.4_20090312 > gettext-0 > > gramofile-1.6P_8|/usr/ports/audio/gramofile|/usr/local|Audio recording and > tick/scratch reduction for e.g. vinyl > records|/usr/ports/audio/gramofile/pkg-descr|nox@FreeBSD.org|audio|fftw-2.1.5_5 > gcc-4.3.4_20090312 gettext-0.17_1 gmake-3.81_3 > > squash-1.0_4|/usr/ports/audio/squash|/usr/local|Learning console-based > MP3/OGG > player|/usr/ports/audio/squash/pkg-descr|matthias.andree@gmx.de|audio|fftw-2.1.5_5 > flac-1.2.1 gcc-4.3.4_20090312 gettext-0.17_1 gmake-3.81_3 id3lib-3.8.3_5 > libao > > gmfsk-0.6_7|/usr/ports/comms/gmfsk|/usr/local|The Gnome MFSK terminal > program|/usr/ports/comms/gmfsk/pkg-descr|carl@stagecraft.cx|comms audio > hamradio|ORBit2-2.14.17 atk-1.24.0 avahi-app-0.6.24_1 bash-4.0.10_2 > bitstream-vera-1.10_4 cairo-1. > > flowdesigner-0.9.1_1|/usr/ports/devel/flowdesigner|/usr/local|A free (GPL) > "data flow oriented" development > environment|/usr/ports/devel/flowdesigner/pkg-descr| > > p5-Chart-Graph-3.2_1|/usr/ports/graphics/p5-Chart-Graph|/usr/local|Perl > extensio > > The point is, yes there are quite a few scientific ports but not all of > them are. gramofile looks useful to me in fact. I've been wanting to > transcribe some old vinyl records. When I said "mostly", I meant "mostly". The point is, there was no brouhaha over fftw's hardwired dependence on Fortran because far fewer people use this port, directly or as a dependency. > >> 2) Maintenance on this port is slack, because there is no designated >> maintainer. > > fftw3 and fftw are both maintained by ahze. > fftw may be maintained by ahze,@, but the port Makefile names ports@FreeBSD.org as the maintainer. >> Originally it was used by people who probably had a Fortran compiler > > I'm not so sure. I suspect a lot of these users simply installed > gcc43 which compiles the fortran compiler by default. In other words, what I said. The point is, they're probably not as inclined to complain about the introduction of an unnecessary dependency when they already have that dependency installed for other reasons. > > >> referring to fftw3, >> which is a different case, with wider consequences. > > Sure. But from my point of view, it was quite reasonable to copy exactly > what was in fftw, when you take a casual look at the non scientific ports > that already require fftw-2 and when you notice that there are a number of > ports that already require gcc4 (which compiles fortran by default). > At first glance, maybe, it may have seemed reasonable: horribly inefficient, perhaps, but expedient. But you're going beyond first glance, to actually considering the consequences of your actions before you commit, right? fftw and fftw3 are apples and oranges because fftw3 is used by far, far, many more people. And you're going to argue, with a straight face, that the fact that the handful of ports that you mentioned above, and maybe a few more, have an unnecessary dependency, is an adequate reason for introducing a new, large, unnecessary dependency for many more ports that are more widely-used? Or that the fact that "a number of ports" in the tree use lang/gcc43 means that it's okay to saddle many other ports with a dependency on it? If so, I think you need to re-examine your the basis of your arguments. I should mention in passing that I'm glad that you noticed that the Fortran shims were not being properly built and installed, and that you took the time to do something about it, even if I don't think the way you went about it was a good idea. >> Any of these, perhaps?: > > No, wsjt in fact. wspr (new port) is waiting for this fix as well. Okay. But in reapportioning dependencies between fftw and your new slave port with the shims, it would be worthwhile to check if the ports I mentioned should depend on the slave port, because they all USE_FORTRAN, and have fftw3 as a direct dependency. > > In any case, hold your horses, it is being looked at. Horses held. b.