From bil.kleb at nasa.gov  Tue Nov  3 16:27:10 2009
From: bil.kleb at nasa.gov (Bil Kleb)
Date: Tue, 3 Nov 2009 16:27:10 -0500
Subject: [NASArb-developers] F2003 dependancy generation failure
In-Reply-To: <93f264080911031308w4ef5e25bn31a80f69b6044b3f@mail.gmail.com>
References: <93f264080911031308w4ef5e25bn31a80f69b6044b3f@mail.gmail.com>
Message-ID: <618B7E43-DE1A-496E-B910-94D25891DE4F@nasa.gov>


On Nov 3, 2009, at 4:08 PM, Izaak Beekman wrote:

> Just FYI I posted a bug at ruby forge.  If you specify, using F2003  
> syntax, modules used by the module under test the dependency  
> generation fails.  Just need to modify or add a regexp I think. I  
> know fUnit is "opinionated" software, but the 2003 syntax is better  
> because it protects your module namespace, and is generally more  
> defensive.
>
> F2003 syntax:
> USE :: ModuleName, ONLY: x,y,z
> or
> USE, NON_INTRINSIC :: ModuleName, ONLY: x,y,z
>
> I think that the most robust fix would be just test for :: after a  
> USE statement, then grab the module right after the double colon.  
> One major complication could occur if the 2003 standard allows  
> multiple modules to be specified on the same line.  I don't know  
> whether or not the 03 or 95 standard allow this and would have to  
> consult the standard definition (rather than my trusty Fortran  
> reference, Metcalf, Reid and Cohen).

I hear you, but Cray is the only vendor offering a F2003 compiler at  
this point.

So you're suggesting funit support both F2003 and F95 forms?

> Also, I am contemplating devising a patch to allow fUnit to perform  
> more robustly when the sources and tests are stored under different  
> directories.  One nice option is to use the Makefile vpath feature  
> or VPATH variable for the makeTestRunner makefile.  This way you  
> don't have cd to different directories etc.  Obviously the  
> dependency resolution/computation section of the code may also need  
> some slight tweaking.

Sounds good, just revisit "How Not to Use VPATH" <http://make.paulandlesley.org 
 >
before hacking away.

> Another area that I may try to help with (if you would be  
> interested) would be the .el files for emacs.  They are not terribly  
> mature (in fact, I think one of them is more of an email than a .el  
> file and could break stuff in emacs if you load it.....) and they  
> could also use some improved documentation.  My general idea is that  
> when C-c C-c is hit funit should run the tests corresponding to the  
> current .fun file only, not all of them.  Also better integration/ 
> abstraction within emacs might be nice, so that for example you  
> could set a variable in your .emacs (or through some other means) to  
> override FC and the other environment variables required, or  
> temporarily set them if they are undefined.

Sounds good.  Note: there is a minor mode available in the utils  
directory.

> Any way, I like this tool a lot, and I figure I should try to pay it  
> forward.  (Also I can only report so many bugs/feature requests  
> without taking on some of the dev. burden myself....)

:)

> Thanks again for your free software.


'welcome, but I don't know about "free".  It is developed at tax payer  
expense. :)

Regards,
--
Bil

P.S. Please consider using nasarb-developers at rubyforge.org and  
splitting into single-topic emails.