right sequence of included module files
Mike
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
Jugoslav Dujic
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.
Steve Lionel
>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
Mike
> On Wed, 23 Apr 2008 01:03:32 -0700 (PDT), Mike <Sulfate...@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.
Craig Powers
>
> 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)?
Mike
I edit the IncludeAllModules.f90, which have:
include module_purposeA.f90
include module_purposeB.f90
...
Then, in my program begins:
include "IncludeAllModules.f90"
program main
use modules_whatever_are_needed
If I add these modules in this specific program and another program
(second project), then once some modules in second project are
modified, wouldn't I have to remodify these modules again in the first
project?
Mike
Steve Lionel
>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:
program test
use A
call sub(3)
end program test
module A
contains
subroutine sub (arg)
integer arg
print *, arg
end subroutine sub
end module A
Compile this once. The first compile will fail. If you compile it a second
time, it will succeed (if your compiler allows this - ifort will give you an
error message). Now, after one compile, edit the source to change:
integer arg
to
real arg
and recompile. What may happen is an error saying that the actual argument 3
doesn't match the type of the corresponding dummy argument "arg". This is
because the USE is still seeing the old module, before the revised one is
compiled. Or your compiler may look ahead and compile module B first. Or it
may give an error about the module order (as ifiort does.)
>I usually separate each module into its own file.
>Then create a include file like:
>
>include module_purposeA.f90
>include module_purposeB.f90
As already noted, don't do that. If you're using makefiles, have the main
program object depend on the objects for the modules used. If you're
compiling by hand, be sure to compile the modules first. If you're using an
IDE, let it work out the compile order. In other words, keep the modules as
separate files and compile them separately, in the correct order.
Craig Powers
If you're using the IDE for Visual Fortran, as long as the module files
are part of the project, things should be rebuilt automatically when
rebuilding is needed. It's difficult or impossible for VF to do that
when the module is brought into a program file using INCLUDE.
Gerry Ford
"Craig Powers" <eni...@hal-pc.org> wrote in message
news:4811406e$0$9833$a726...@news.hal-pc.org...
My claim is that when you're using IDE's, it's impossible to communicate
without screenshots in relevant places.
--
"Life in Lubbock, Texas, taught me two things: One is that God loves you
and you're going to burn in hell. The other is that sex is the most
awful, filthy thing on earth and you should save it for someone you love."
~~ Butch Hancock
Mike
I also include module B.
program test
use A
call sub(3)
end program test
module B
use A
contains
subroutine subB()
print *,'B'
end subroutine subB
end module B
module A
contains
subroutine sub (arg)
integer arg
print *, arg
end subroutine sub
end module A
Temporarily, I am a little confused about how to compile main and many
module files separately as you suggested. I'll do it as a whole file.
The first compile will fail.
Yes "Error: Error in opening the Library module file. [A]"
If you compile it a second
> time, it will succeed (if your compiler allows this - ifort will give you an
> error message).
No. Error happens with "Error: Declaration of module 'A' comes after
the use of that module. A module's declaration must precede its
use.".
Now, after one compile, edit the source to change:
>
> integer arg
>
> to
>
> real arg
>
> and recompile. What may happen is an error saying that the actual argument 3
> doesn't match the type of the corresponding dummy argument "arg".
Error: Declaration of module 'A' comes after the use of that module.
A module's declaration must precede its use.
This is
> because the USE is still seeing the old module, before the revised one is
> compiled. Or your compiler may look ahead and compile module B first. Or it
> may give an error about the module order (as ifiort does.)
>
Then compile once again:
Error: The type of the actual argument differs from the type of the
dummy argument. [3]
> >I usually separate each module into its own file.
> >Then create a include file like:
>
> >include module_purposeA.f90
> >include module_purposeB.f90
>
> As already noted, don't do that. If you're using makefiles, have the main
> program object depend on the objects for the modules used. If you're
> compiling by hand, be sure to compile the modules first. If you're using an
> IDE, let it work out the compile order. In other words, keep the modules as
> separate files and compile them separately, in the correct order.
I use IDE to compile.
Do you mean creating a project then add every module files into this
project?
Will it show every module files in "Source Files" of Workspace?
Then I compile every file including main program separately.
Then I saw ***.mod appears in "External Dependencies" of Workspace
window.
Then I remember I did these steps before.
But when I want to copy the main project to have a test, I need to
manually add these separate module files to this project. Therefore I
did this by INCLUDE way.
Mike
Mike
sorry. Then if I use INCLUDE way, these files will automatically
appeared in "External Dependencies" of Workspace window.
>
> Mike
>
>
>
> > --
> > 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- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Steve Lionel
>If you compile it a second
>> time, it will succeed (if your compiler allows this - ifort will give you an
>> error message).
>
>No. Error happens with "Error: Declaration of module 'A' comes after
>the use of that module. A module's declaration must precede its
>use.".
I did say that ifort will give you an error message. That's it.
>I use IDE to compile.
>Do you mean creating a project then add every module files into this
>project?
Yes.
>Will it show every module files in "Source Files" of Workspace?
Yes.
>Then I compile every file including main program separately.
Don't "compile every file". Build the project (or Solution).
>Then I saw ***.mod appears in "External Dependencies" of Workspace
>window.
No. .mod files never appear by themselves in the IDE. They are intermediate
files similar to object files.
>Then I remember I did these steps before.
>But when I want to copy the main project to have a test, I need to
>manually add these separate module files to this project. Therefore I
>did this by INCLUDE way.
Don't. Just add the .f90 files to the project and they'll get built properly.
Mike
> On Thu, 24 Apr 2008 21:04:05 -0700 (PDT), Mike <Sulfate...@gmail.com> wrote:
> >If you compile it a second
> >> time, it will succeed (if your compiler allows this - ifort will give you an
> >> error message).
>
> >No. Error happens with "Error: Declaration of module 'A' comes after
> >the use of that module. A module's declaration must precede its
> >use.".
>
> I did say that ifort will give you an error message. That's it.
>
> >I use IDE to compile.
> >Do you mean creating a project then add every module files into this
> >project?
>
> Yes.
>
> >Will it show every module files in "Source Files" of Workspace?
>
> Yes.
>
> >Then I compile every file including main program separately.
>
> Don't "compile every file". Build the project (or Solution).
All right.
>
> >Then I saw ***.mod appears in "External Dependencies" of Workspace
> >window.
>
> No. .mod files never appear by themselves in the IDE. They are intermediate
> files similar to object files.
No. As you just say, I Build the project. There are *.obj and *.mod
appeared in Debug directory. Then I see *.mod do appear in "External
Dependencies" of Workspace/Fileview.
Can you figure any wrong step?
>
> >Then I remember I did these steps before.
> >But when I want to copy the main project to have a test, I need to
> >manually add these separate module files to this project. Therefore I
> >did this by INCLUDE way.
>
> Don't. Just add the .f90 files to the project and they'll get built properly.
I did put all of my .f90 files into the project, since I don't want to
figure out which modules I have to USE or not USE.
I put all of them into the project.
Then I find some of the .f90 are main programs.
So I delete all of them. I compile the main program I have.
Figure out what module files are needed, after linking.
Then add them to project. Need a lot of time to do this.
Is there a way to filter out all of main programs (except current one
I want), when I Add all .f90 to the project?
Mike
Steve Lionel
> No. As you just say, I Build the project. There are *.obj and *.mod
> appeared in Debug directory. Then I see *.mod do appear in "External
> Dependencies" of Workspace/Fileview.
> Can you figure any wrong step?
I've never seen that happen. Which compiler are you using?
> I did put all of my .f90 files into the project, since I don't want to
> figure out which modules I have to USE or not USE.
> I put all of them into the project.
> Then I find some of the .f90 are main programs.
> So I delete all of them. I compile the main program I have.
> Figure out what module files are needed, after linking.
> Then add them to project. Need a lot of time to do this.
> Is there a way to filter out all of main programs (except current one
> I want), when I Add all .f90 to the project?
There's no automatic way to do this. You might get a clue when the
linker complains about multiple main programs, but figuring out which
other sources aren't needed requires you to understand the application.
Most people separate the sources of different applications.
jwm
>
> I've never seen that happen. Which compiler are you using?
>
the external dependencies folder in Digital/Compaq Visual Fortran.
That feature seems to have been removed in IVF/VS2002, along with the
ability for the IDE to automatically add the included files as
external dependencies (i.e., if you want them listed in the solution
explorer in VS200x, they must be added manually and excluded from
build).
Mike
> Mike wrote:
> > No. As you just say, I Build the project. There are *.obj and *.mod
> > appeared in Debug directory. Then I see *.mod do appear in "External
> > Dependencies" of Workspace/Fileview.
> > Can you figure any wrong step?
>
> I've never seen that happen. Which compiler are you using?
Compaq Visual Fortran 6.6C
>
> > I did put all of my .f90 files into the project, since I don't want to
> > figure out which modules I have to USE or not USE.
> > I put all of them into the project.
> > Then I find some of the .f90 are main programs.
> > So I delete all of them. I compile the main program I have.
> > Figure out what module files are needed, after linking.
> > Then add them to project. Need a lot of time to do this.
> > Is there a way to filter out all of main programs (except current one
> > I want), when I Add all .f90 to the project?
>
> There's no automatic way to do this. You might get a clue when the
> linker complains about multiple main programs, but figuring out which
> other sources aren't needed requires you to understand the application.
> Most people separate the sources of different applications.
>
I hope the programmer decide the main program and those module files
being used only. Let compiler automatically find the necessary module
files.
Mike
Mike
> On Apr 26, 2:57 pm, Steve Lionel <steve.lio...@intel.invalid> wrote:
>
> > I've never seen that happen. Which compiler are you using?
>
> If I recall correctly, the *.mod and included files used to show up in
> the external dependencies folder in Digital/Compaq Visual Fortran.
> That feature seems to have been removed in IVF/VS2002, along with the
> ability for the IDE to automatically add the included files as
> external dependencies
Do you mean using INCLUDE statement or USE?
Mike
dpb
...
> I hope the programmer decide the main program and those module files
> being used only. Let compiler automatically find the necessary module
> files.
The IDE isn't that smart...you'll want/need to add all the source files
to the project so they're available. This is relatively easy if you
will organized files into subdirectories by application with those that
may be shared between multiple applications in locations suitably named.
You can then easily add all the *.f/f90/for files in a subdirectory and
update dependencies which will find the modules referenced by USE or
other source files referenced by INCLUDE, but doesn't have the smarts to
automagically add them.
If you're using modules that aren't being built as part of this project
(earlier libraries, etc.), then those are included as part of the
include path...
To control the placement of module files in directories, use the
/[no]module compiler option.
To control the search for module files in directories, use the
/[no]include and the /assume:source_include compiler options.
HTH...
--
Steve Lionel
>If I recall correctly, the *.mod and included files used to show up in
>the external dependencies folder in Digital/Compaq Visual Fortran.
>That feature seems to have been removed in IVF/VS2002, along with the
>ability for the IDE to automatically add the included files as
>external dependencies (i.e., if you want them listed in the solution
>explorer in VS200x, they must be added manually and excluded from
>build).
I had forgotten that CVF did that, but you are correct. Current versions of
Intel Visual Fortran will try to sort out include files when you add them to
the project, but it does so by file type (.fi for example) and not by looking
at INCLUDEs.
dpb
> Mike wrote:
> ...
>> I hope the programmer decide the main program and those module files
>> being used only. Let compiler automatically find the necessary module
>> files.
>
>
> The IDE isn't that smart...you'll want/need to add all the source files
> to the project so they're available. This is relatively easy if you
> will organized files into subdirectories by application with those that
> may be shared between multiple applications in locations suitably named.
> You can then easily add all the *.f/f90/for files in a subdirectory and
> update dependencies which will find the modules referenced by USE or
> other source files referenced by INCLUDE, but doesn't have the smarts to
> automagically add them.
Sorry, I meant it doesn't have the smarts to automagically add only
additional reference Fortran source w/ other subroutines and/or
functions, only the INCLUDE'd or USE'd files that have an explicit
reference that can be resolved.
--