I've started a new thread to discuss my gfortran4.7 patch on the pfunit-dev list.
Just a couple of follow up comments:
* Asking users to install compilers is a major hassle, especially on institutional clusters running an older OS. Requiring the latest dev version of a compiler not only requires user to install the compiler but also rebuild all their third party libraries. For a low level library like pFUnit, supporting the widest reasonable range of compilers may be the best approach to building a user community.
I understand, but it is also the case that the design of pFUnit (2.x) is predicated upon use of F2003 OO capabilities. Earlier compilers were incomplete/buggy. When I encounter issues, I generally try to find a workaround that will still allow older compilers to work, but in the case of gfortran it was a very serious bug that for which none of the experts I consulted could suggest a robust workaround. (Small changes could make the problem go away, but it would come back with a change as simple as commenting out a PRIVATE statement in a derived type.
My compromise was to create a branch that still at least worked (with the latent bug possibly to be exposed by any further changes on that branch). I believe that getting 4.7 to work on that branch will be relatively easy, and will even do it for you if need be. Unfortunately I've got a packed schedule of visitors this week and just won't have time until the weekend.
Even more critical, but not likely to happen soon would be a PGI port. There are so many compiler issues that are encountered that do not have obvious workarounds that I've made relatively little progress. But multiple users would really like that port. sigh.
* We've found continuous integration systems like buildbot <http://buildbot.net/> to be critical to supporting multiple builds/compliers/platforms with minimal pain. It takes a bit of an initial investment, but is worth it. Just like testing :-).
Er, we use continuous integration. For the most part, we are using something built in house. Been trying to move to Hudson/Jenkins but NASA IT security has defeated some aspects (e.g. making the results more visible). I certainly am in discussions with users that have access to a wider variety of compilers (e.g. Cray and IBM) so that we can include those as well.
One of the nice things about GIT is that we can actually do multi-phase continuous integration. E.g. I have hudson running on my laptop checking 3 vendors with each commit. Then when I push, our cluster pulls an update and runs against multiple _versions_ of those same compilers. (Separate set for the 2.1 branch than for the master.)
Then, this weekend I switched to having an integration branch for the main integration. This should decrease the frequency at which the master branch itself is temporarily broken from a push. (Had not been an issue for most of pFUnit history, but the introduction of CMake caused some instability for a bit.)
I'll look again at buildbot in the hopes that it would make it easier to incorporate tests by external users on IBM/Cray etc.
* "Semantic Versioning <http://semver.org/>" might be helpful in keeping track of your releases.
Yes - I've been sloppy here, and would like to improve going forward. Physicist playing SE.
Questions/comments on semantic versioning: I'm not certain I understand the value of the "patch" attribute in the context of continuous integration and agressive use of TDD. Users should be able to get the head of development and experience no issues. All bugs that have appeared on the master branch have had a lifetime usually measured in minutes or hours. (A couple made it over a weekend, but the integration branch mentioned above should eliminate even that situation.)
Technically I could argue I have followed semantic versioning for the major/minor attributes. 2.1.0 was backward compatible. Mostly it was drawing a line in the sand pointing out that new work would break that backward compatibility. My read of the document you cited would imply that virtually every push I make would force an increment to the minor attribute. Seems at odds with the lightweight process that has been working until now though. I've been using numbers only when they will matter to the user.
So, if I understand the desire correctly, the master branch should now be considered to be 3.0 beta. I'm a bit reluctant to call the push I'll be making sometime this week "3.0" because (a) the changes are actually not all that substantial although certainly not backward compatible (at the request of the users!) and (b) they are preliminary which means that I expect further minor changes to the interface in short order. I.e. I can be convinced to call it 3.0, but do I really then need to have 4.0 the following week just to tweak those interfaces after the users play with them? Should I expect users to checkout a branch instead even though I'm using continuous integration? I'm certainly interested in being educated in best practices here.
On Jan 24, 2014, at 5:48 AM, Tom Clune <Thomas.L.Clune@nasa.gov> wrote:
It should certainly be feasible to patch this for you - esp. if you are willing to do the leg work. Note that the development branch does not even support 4.8.x any more due to a terrible (as in hard to pin down) bug uncovered over the holidays. Eventually 4.8.3 should be supported by the development when it comes out, and in the mean time we are forced to use the unreleased 4.9.0.
If you do want to do this, I suggest you start with the pfunit_2.1.0 branch, or else you will find yourself encountering the bug I described above. We'll put the patch as tag pfunit_2.1.1. (I should not have but the final ".0" in the branch name. Not a real SE …)
You should note though, that the downside is that I'm about to introduce a major change in the pFUnitParser that significantly simplifies tests that involve user-defined subclasses of TestCase. By using the 2.1.0 branch you will miss out on that and may need to modify your tests when you eventually upgrade. Generally this will involve deleting unnecessary things, but with a large number of tests it can be a bit tedious.
Also, not sure it is relevant here or not, but we have found that the tar release of GCC 4.8.1 had the same exact problem you are reporting, but that the build from SVN for 4.8.1 did not. So it is possible that you could rebuild 4.7.x from SVN and have a similar fix. Not sure it is worth the effort to discover the answer though.
On Jan 24, 2014, at 1:35 AM, Benjamin Andre <firstname.lastname@example.org> wrote:
I've been working on bringing pFUnit into our project but hit a snag. We still support gfortran 4.7.x (and will probably continue as long as it is the "oldest maintained release" of gcc, http://gcc.gnu.org/). I've run into the "Deferred-length character component" bug:
class (SurrogateTestCase), intent(inout) :: this
Error: Deferred-length character component 'getname' at (1) is not yet supported
mentioned on the pfunit-support mailing list:
Only supporting unit testing on gfortran-4.8 is possible but suboptimal. Is supporting gfortran-4.7.x in the pfunit-2.1 branch feasible? I'm willing to work on it and submit patches, but I don't want to start down a never ending path of kludges to get it to work.
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
Pfunit-support mailing list
Thomas Clune, Ph. D. <Thomas.L.Clune@nasa.gov>
Chief, Software Systems Support Office Code 610.3
NASA GSFC 301-286-4635
MS 610.8 B33-C128 <http://ssso.gsfc.nasa.gov>
Greenbelt, MD 20771