|
|
Up |
|
|
  |
Author: MikeMike Date: Apr 23, 2008 01: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.
|
| Show full article (0.78Kb) |
|
| | 19 Comments |
|
  |
Author: Jugoslav DujicJugoslav Dujic Date: Apr 23, 2008 02: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 ...
|
| Show full article (2.57Kb) |
|
| | no comments |
|
  |
Author: Steve LionelSteve Lionel Date: Apr 23, 2008 07:30
On Wed, 23 Apr 2008 01:03:32 -0700 (PDT), Mike 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!
|
| Show full article (1.70Kb) |
| 1 Comment |
|
  |
Author: MikeMike Date: Apr 23, 2008 17:42
On Apr 23, 10:30 pm, Steve Lionel wrote:
> On Wed, 23 Apr 2008 01:03:32 -0700 (PDT), Mike 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 ...
|
| Show full article (2.71Kb) |
| no comments |
|
  |
Author: Craig PowersCraig Powers Date: Apr 23, 2008 20: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)?
|
| |
| no comments |
|
  |
Author: MikeMike Date: Apr 23, 2008 20:51
On Apr 24, 11:39 am, Craig Powers hal-pc.org> wrote:
> 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)?
I edit the IncludeAllModules.f90, which have:
include module_purposeA.f90
include module_purposeB.f90
...
|
| Show full article (0.96Kb) |
| no comments |
|
  |
Author: Steve LionelSteve Lionel Date: Apr 24, 2008 12:03
On Wed, 23 Apr 2008 17:42:26 -0700 (PDT), Mike gmail.com> wrote:
>Is this what you mean? I use the following example:
[snip]
Yes,.
>
>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!"?
It depends on what you changed. In your case, you changed the executable code
only, so the object file that got created when module A was compiled a second
time got used in the subsequent link step.
In your example, module B doesn't actually use anything from module A. To see
what I was talking about, consider this version:
|
| Show full article (2.43Kb) |
| no comments |
|
  |
Author: Craig PowersCraig Powers Date: Apr 24, 2008 19:22
Mike wrote:
> On Apr 24, 11:39 am, Craig Powers hal-pc.org> wrote:
>> 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)?
>
> I edit the IncludeAllModules.f90, which have:
> include module_purposeA.f90
> include module_purposeB.f90
> ...
>
> Then, in my program begins: ...
|
| Show full article (1.26Kb) |
| no comments |
|
  |
Author: Gerry FordGerry Ford Date: Apr 24, 2008 20:33
"Craig Powers" hal-pc.org> wrote in message
news:4811406e$0$9833$a726171b@news.hal-pc.org...
> Mike wrote:
>> On Apr 24, 11:39 am, Craig Powers hal-pc.org> wrote:
>>> 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)?
>>
>> I edit the IncludeAllModules.f90, which have:
>> include module_purposeA.f90
>> include module_purposeB.f90
>> ... ...
|
| Show full article (1.76Kb) |
| no comments |
|
  |
|
|
  |
Author: MikeMike Date: Apr 24, 2008 21:04
On Apr 25, 3:03 am, Steve Lionel wrote:
> On Wed, 23 Apr 2008 17:42:26 -0700 (PDT), Mike gmail.com> wrote:
>>Is this what you mean? I use the following example:
>
> [snip]
>
> Yes,.
>
>
>
>>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!"?
> ...
|
| Show full article (4.02Kb) |
| no comments |
|
|
|
|