Prev: Compile and link optimization using gfortran
Next: Random number in Fortran 90/95
From: yaqi on 18 Jun 2010 23:40
To demonstrate this issue, I created three files.

The first 'dim.h' is a head file with a variable definition in it:

#define dim 2

The second file 'typ_boundary.f90' contains a module definition:


#include "dim.h"
#if (dim==2)
MODULE TypBoundary_2D
#elif (dim==3)
MODULE TypBoundary_3D
#endif

INTEGER, PARAMETER :: vacuum_bc =-1
INTEGER, PARAMETER :: reflecting_bc =-2
INTEGER, PARAMETER :: MaxNonHom_bc =-10
INTEGER, PARAMETER :: MinNonHom_bc =-99

! boundary types
INTEGER, PARAMETER, PRIVATE :: num_bdry_types = 2

INTEGER, PARAMETER :: vacuum = 1
INTEGER, PARAMETER :: reflecting = 2

CONTAINS

FUNCTION boundary_type(boundary_indicator)
IMPLICIT NONE
INTEGER :: boundary_indicator, boundary_type
SELECT CASE (boundary_indicator)
CASE (vacuum_bc, MinNonHom_bc:MaxNonHom_bc)
boundary_type = vacuum
CASE (reflecting_bc)
boundary_type = reflecting
CASE DEFAULT
stop 'wrong indicator'
END SELECT
RETURN
END FUNCTION boundary_type

LOGICAL FUNCTION is_boundary(boundary_indicator)
IMPLICIT NONE
INTEGER :: boundary_indicator
SELECT CASE (boundary_indicator)
CASE (vacuum_bc, MinNonHom_bc:MaxNonHom_bc, reflecting_bc)
is_boundary = .true.
CASE DEFAULT
is_boundary = .false.
END SELECT
RETURN
END FUNCTION is_boundary

INTEGER FUNCTION num_boundary_type()
IMPLICIT NONE
num_boundary_type = num_bdry_types + 1
RETURN
END FUNCTION num_boundary_type

INTEGER FUNCTION periodic_type()
IMPLICIT NONE
periodic_type = num_boundary_type()
RETURN
END FUNCTION periodic_type

#if (dim==2)
END MODULE TypBoundary_2D
#elif (dim==3)
END MODULE TypBoundary_3D
#endif

The last file 'Source1.f90' is the main:


#include "dim.h"
program test
#if (dim==2)
USE TypBoundary_2D
#elif (dim==3)
USE TypBoundary_3D
#endif
implicit none

print *, num_boundary_type()

stop
end program test

We can compile these three files with Visual Studio+Intel Visual
Fortran by turning fpp (fortran preprocess for all derivatives) on and
adding the directory where dim.h is in into the including directory.
I am using Intel(R) Visual Fortran Compiler Integration for Microsoft
Visual Studio* 2008, 11.1.3471.2008.
The problem is that Visual Studio always do the rebuild even nothing
is changed after the last build.

I also create a simple makefile with gfortran in cygwin:

testpre : typ_boundary.o Source1.o
gfortran -o testpre typ_boundary.o Source1.o

typ_boundary.o : typ_boundary.f90 dim.h
gfortran -c -cpp -I. typ_boundary.f90

Source1.o : Source1.f90 dim.h typ_boundary.o
gfortran -c -cpp -I. Source1.f90

It just works fine.

So it must be the preprocessing derivatives that cause VS always do
the rebuild. Is this a bug in VS or something I misunderstand?

Thanks.

From: Richard Maine on 19 Jun 2010 01:11
I'm afraid I don't know much useful about the Visual Studio environment
to answer your question, but I will make one side note.

yaqi <yaqiwang(a)gmail.com> wrote:

> The first 'dim.h' is a head file with a variable definition in it:
>
> #define dim 2

No, that is not a variable definition. That defines a preprocessor
macro. It is not particularly close to being a variable. If you start to
confuse things like that with variables, further confusions will
probably follow, which is why I make the correction.

Variables can vary; thus the term "variable". Constants cannot vary;
they are constant. The 2 here is a literal constant (once it is
preprocessed). The dim is a C preprocessir macro.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
 | 
Pages: 1
Prev: Compile and link optimization using gfortran
Next: Random number in Fortran 90/95