Alan W. Irwin writes: > When running into a component problem like this where you are not interested > in the component (and also for speed) just disable the componenent, e.g., > -DENABLE_f95=OFF
I did, and kept going. > Thanks for that fortran 95 error report. > > However, I don't think we should change anything in PLplot to deal with this > issue. Well, something needs to change, because the build failed, and I did nothing to select any "experimental features". A default build should just work on most common platforms. > The exit statements in examples/f95/x20f.f90 are causing the trouble for > your f95 compiler. Those are very different from "call exit". The bare > exit command is used to escape loops in Fortran 95. Modern gfortran > implements it as does the Intel compiler (and presumably all other > commercial Fortran compilers). Apparently, you have some old version of > gfortran that doesn't have bare exit implemented yet. Our Fortran 95 > examples build and work great here with gfortran (GNU Fortran (Debian > 4.3.2-1.1) 4.3.2). > > I am now going to rant just a little about one of my pet peeves, the > so-called enterprise editions of Linux distributions. Those distributions > are filled with out-dated software which I think you are the victim of in > this case since you have mentioned RHEL version 4 in other contexts. I said in the report of the fortran build failure that I was running on Fedora 8. > I think the source of the trouble is corporate IT departments which have > been conditioned to demand non-changing software by proprietary software > vendors. They have made similar demands of Linux distribution vendors, > and as a result the enterprise edition of Linux was born. But the whole > idea should have been aborted instead since it is fundamentally not > consistent with the pace of development for Linux. Linux is not and never > will be a toaster. > > I assume every 3 years or so these corporate IT departments are forced to > change their enterprise Linux version. There must be huge training costs > associated with such enormous change attempted all at once. There has got > to be a better way of having a steady diet of reliable, well-tested change > that keeps up with Linux development for just the key libraries and apps > that a particular corporation wants. The idea would be to give > corporation workers the chance to adjust to the steady change associated > with Linux without having huge training costs associated with large abrupt > changes. You also avoid the hidden costs of old Linux software that > sometimes (as above) just doesn't cut it. > > End rant. So, I share your frustration. When I brought up "enterprise Linux" the other day, I wasn't endorsing it, just observing that it is widespread and entrenched. But I don't like it either. Trying not to descend into a rant here myself, what I can say is that there is some economic sense behind the whole notion of stable enterprise platforms and deployments. In the industry that I and Maurice are in, for example, the costs of manufacture for integrated circuits, and the computer aided design tools that support such design and manufacturing, are very large. Typical software tooling is multi-hunderd thousand USD per engineer per year. The vendors of these tools certify on Linux, specific "enterprise" versions, and the customers run the platforms the tools are certified on, because they need to be able to get suppport. Too much money is riding on the line, for them to jeopardize their support options by not running the certified platform. And too much money is riding on the line for the tool vendors to not do the rigorous testing required to provide meaningful certification on at least some platforms. Now, there is a roadmap for driving tools onto newer platforms, and essentially every tool I personally us, is currently certified on RHEL5, which is years newer than RHEL4. But, there are still *some* tools in the design and manufacturing toolchain which are *not* certified on RHEL5, hence the need to keep RHEL4 deployed. Anyway, to my thinking, this is all both interesting (albeit annoying), and simultaneously somewhat irrelevant to the point, at least the point I'm trying to make. The point I'm trying to make is that PLplot should configure (cmake) and compile on reasonably common platforms. IMO, Fedora 8 should qualify. So, if the default/stock gfortran isn't good enough to compile the PLplot source code, then in my opinion, the PLplot configuration system (cmake) should check the gfortran version, and if it's not good enough, automatically disable the g95 option. I really don't have a point of view on the validity of the Fortran example 20 in question. If it was wrong, it should be fixed. But if it was right and the compiler on F8 is too weak, then the CBS should detect that the gfortran is not of the required minimum version, and turn of F95 support in the build. I think there should also be a way to override any auto-shut-off, so that a user who wants to experiment with either differnet tools, or changing the source code, is not prevented from doing so. If your compiler is too weak, CBS should disable it (whatever feature is affected) by default, but provide a manual overide for those determined to press on. My $.02. -- Geoff ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
