Prev: Interpretation of RECL resolution; help file in CVF
Next: open file in subroutine
From: Mike on 23 Apr 2008 04:03
Hi

The sequence of the following modules is very important.
module A
end module A

module B
use A
end module B

If module B is put before module A then there will be compiled error:
Error: Error in opening the Library module file. [A]
I use CVF6.6c.

However, if I compiled it again, there will be no error.
It is a simple example.
When more module files use other module, things will be more complex.
I usually have to decide very carefully the sequence of the included
module files. Otherwise, there will be some unexpected error. I
found this today, after I arrange the sequence correctly. Some errors
are disappeared.

I am wondering if other compiler needs right sequence of included
module files.
And for user of CVF6.6c, do I have a better way to do it?

Mike
From: Jugoslav Dujic on 23 Apr 2008 05:37
Mike wrote:
| Hi
|
| The sequence of the following modules is very important.
| module A
| end module A
|
| module B
| use A
| end module B
|
| If module B is put before module A then there will be compiled error:
| Error: Error in opening the Library module file. [A]
| I use CVF6.6c.
|
| However, if I compiled it again, there will be no error.
| It is a simple example.
| When more module files use other module, things will be more complex.
| I usually have to decide very carefully the sequence of the included
| module files. Otherwise, there will be some unexpected error. I
| found this today, after I arrange the sequence correctly. Some errors
| are disappeared.
|
| I am wondering if other compiler needs right sequence of included
| module files.
| And for user of CVF6.6c, do I have a better way to do it?

Of course every compiler needs to compile modules in the right
order. The question is, how is the right order determined?

You can see for yourself that the task is non-trivial: the
source files should be parsed at least at the basic level,
USE and INCLUDE statements therein found, checked if they're
not commented or orphaned, then the dependency information
analysed, resulting in the correct compile order.

"Traditionally", for non-trivial projects, it was
programmer's task to do most of the above, and write a
makefile (google for it) containing dependency information and
build commands. The make.exe would process the makefile
and do the things in the correct order.

There were also some auxiliary tools that automate the task,
such as http://personal.inet.fi/private/erikedelmann/makedepf90/.
The other -- you're talking about -- is built-in by Compaq into
Visual Studio and it's not a part of "compiler proper"... It
is active only when you build from the Visual Studio itself.

....and, as you discovered, it is sort of buggy, especially for
complex intermodule dependencies. The known
limitation occurs when the dependency tree is relatively deep
(documsntation says deeper than 3 levels if I recall correctly),
but it does tend to be quirky otherwise, asking that you compile
again the files that you have just compiled. However, I didn't
notice problems on shallow dependency trees?

There are a couple of workarounds to reduce the recompiling pain,
but basically you either should live with it, do your own
compiling through command prompt and makefiles, or upgrade to
IVF :-).

--
Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.
From: Steve Lionel on 23 Apr 2008 10:30
On Wed, 23 Apr 2008 01:03:32 -0700 (PDT), Mike <SulfateIon(a)gmail.com> wrote:

>If module B is put before module A then there will be compiled error:
>Error: Error in opening the Library module file. [A]
>I use CVF6.6c.
>
>However, if I compiled it again, there will be no error.
>It is a simple example.
>When more module files use other module, things will be more complex.
>I usually have to decide very carefully the sequence of the included
>module files. Otherwise, there will be some unexpected error. I
>found this today, after I arrange the sequence correctly. Some errors
>are disappeared.

The standard says that a module must be "available" before you USE it. What
that means is not specified. For the compiler you're using, it means that
module A must have been compiled before a USE A can be processed. Since that
compiler processes program units sequentially in the source, if you put the
USE A earlier in the source file that defines module A, then you'll get this
error. On a recompile, module A was compiled previously so you don't see the
error, but if you changed module A you won't see the changes!

Some compilers will "look ahead" in the source to resolve this, but others
will not. Both behaviors are correct. My advice is to separate each module
into its own source file and let the dependency manager do its job.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran
From: Mike on 23 Apr 2008 20:42
On Apr 23, 10:30 pm, Steve Lionel <Steve.Lio...(a)intel.invalid> wrote:
> On Wed, 23 Apr 2008 01:03:32 -0700 (PDT), Mike <Sulfate...(a)gmail.com> wrote:
> >If module B is put before module A then there will be compiled error:
> >Error: Error in opening the Library module file.   [A]
> >I use CVF6.6c.
>
> >However, if I compiled it again, there will be no error.
> >It is a simple example.
> >When more module files use other module, things will be more complex.
> >I usually have to decide very carefully the sequence of the included
> >module files.  Otherwise, there will be some unexpected error.  I
> >found this today, after I arrange the sequence correctly.  Some errors
> >are disappeared.
>
> The standard says that a module must be "available" before you USE it.  What
> that means is not specified.  For the compiler you're using, it means that
> module A must have been compiled before a USE A can be processed.  Since that
> compiler processes program units sequentially in the source, if you put the
> USE A earlier in the source file that defines module A, then you'll get this
> error. On a recompile, module A was compiled previously so you don't see the
> error, but if you changed module A you won't see the changes!

Is this what you mean? I use the following example:

module B
use A
contains
subroutine subB()
print *,'B'
end subroutine subB
end module B

module A
contains
subroutine subA()
print *,'A'
end subroutine subA
end module A

program main
use A;use B;
call subA()
call subB()
end program main

As first, errors of module A and B happened. However, A.mod is
generated.
After 2nd compilation, B.mod is generated because A.mod is generated.
Then I modify 'A' to 'AA', then compiled, I can still have the correct
results:
AA
B
Why do you say "but if you changed module A you won't see the
changes!"?

>
> Some compilers will "look ahead" in the source to resolve this, but others
> will not. Both behaviors are correct.  My advice is to separate each module
> into its own source file and let the dependency manager do its job.

I usually separate each module into its own file.
Then create a include file like:

include module_purposeA.f90
include module_purposeB.f90
...

And put this include file as the beginning of a main program.

Still I have this problem.

>
> --
> Steve Lionel
> Developer Products Division
> Intel Corporation
> Nashua, NH
>
> For email address, replace "invalid" with "com"
>
> User communities for Intel Software Development Products
>  http://softwareforums.intel.com/
> Intel Fortran Support
>  http://support.intel.com/support/performancetools/fortran
> My Fortran blog
>  http://www.intel.com/software/drfortran

From: Craig Powers on 23 Apr 2008 23:39
Mike wrote:
>
> I usually separate each module into its own file.
> Then create a include file like:
>
> include module_purposeA.f90
> include module_purposeB.f90
> ...
>
> And put this include file as the beginning of a main program.

If you're already creating separate files for the modules, then why on
earth would you then INCLUDE them in the main program file, instead of
just adding them to the project (where, typically, IJW)?
 |  Next  |  Last
Pages: 1 2 3
Prev: Interpretation of RECL resolution; help file in CVF
Next: open file in subroutine