Flawed logic in Rinit wrt %RFORTRAN_PATH%

*** What steps will reproduce the problem?

1. Run RFortran (Rinit) twice on a machine that sets the RFortran paths 
programatically and does NOT have %RFortran_PATH% environment variable.

*** What is the expected output?

Correct reinitialization

*** What do you see instead?

Rinit returns error

*** What version of RFortran are you using?

RFortran 2.1.2

*** If you have a coding solution to this defect please include the file
(or preferably a svn patch) as an attachment

see attached

*** Please provide any additional information below.

Caused by the horrendous flaw of using the function return argument 'ok' 
denoting a fatal error to inquire regarding a minor setup aspect (does an 
optional Windows environment variable exist?). On the 1st call to Rinit, 'ok' 
gets fortuitously reset to 0 down the line, but on the 2nd call, when 
R/RFortran is already initialized Rinit (correctly) exits earlier, and ok/=0 
gets returned to calling unit.

More generally, the logic of RFortran of relying on Windows environmental 
variables is quite fragile at the moment and not very clear to grassroots 
"ma&pa" developers using RFortran. For example, an error gets logged despite 
the program working seemingly ok.

Though currently working (lamely), I recommend a major re-evaluation/cleanup of 
the logic/sequence of steps/setup surrounding Rinit/init_log to avoid 
accumulating difficult-to-resolve problems.

The problem is a blocker as it prevents hundreds of potential (indirect) users 
of RFortran from calling it twice in the same code execution instance.

Original issue reported on code.google.com by dmitri.k...@gmail.com on 22 Jun 2010 at 7:59

Attachments:

RinitEnvVarFlaw.patch

hodgesse1 / rfortran

Flawed logic in Rinit wrt %RFORTRAN_PATH% #71