Porting from Silverfrost FTN95 - anyone been here before?

[Kenny_T_1]

Hi,

I'm evaluating IVF with a view to "changing horses" from Silverfrost's FTN95 compiler.  I've tried compiling a source file with module definitions but get "loads of errors" that I don't know how to fix.  Has anyone trod this path before and is prepared to get me kick-started by "fixing" the attached source file?

TIA

K

[Kenny_T_1]

OK, going in leaps and bounds now :). But I have a n00b question about VS...

is it possible to have a "complete solution", containing the source for an EXE and DLLs and to build them all "in one go" or should I rather have separate solution files for each of my DLLs?... (I may be using the wrong terminology, so if more explanation/ clarification is needed, let me know).

K

[Les_Neilson]

Yes. A solution consists of one or more projects, so you can have projects that build the dlls and a project that builds the exe. You just need to ensure that you mark the project that builds the exe as depending on all of the other projects.

Les

[IanH]

Also, in cases where there is no logical dependency between a DLL and an EXE (perhaps they are independent outputs from the same source code) or where your solution involves multiple EXE's, the menu command Build > BuIld Solution does what it says, on good days.

[Steven_L_Intel1]

Kenny T. wrote:

But, Steve, your exe file in Winapp1 project has tripped over my virus checker?

This is common with antivirus programs - a false positive on something it is not familiar with. Ignore it.

[Kenny_T_1]

ok, i've told Avira to ignore the exe, seems to be happy now!

now, back to the main fun and games...

The toolkit that i'm using works nicely, providing me with a "windows" application, from a "console" IVF main linked via an FTN95 DLL (!).  The only irritation is the appearance of the black console window - is there a way to stop it from appearing?  I'm not sure i want to delve into the mysteries of "winapp" quite yet as that seems to duplicate (and may interfere with) the operation of the toolkit that i'm using.

K

PS, a belated thanks to Ian and Les for their replies...

[Steven_L_Intel1]

No - if you have a console application, you get the console. A "winapp" would avoid this. It should not be a problem as you're running a separate executable. Just strip out all of the code that deals with windows, leaving a WinMain function as the equivalent of the main program and have this call your DLL.

[Kenny_T_1]

thanks Steve, i think i'm missing a trick...

[fortran]

function WinMain()

      CALL REP
      
      winmain = 0
end      

    
subroutine REP
[/fortran]

but i get a link error:

Error    4     error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup    LIBCMTD.lib(wincrt0.obj)    

Sorry to be a dunce!

K

[Steven_L_Intel1]

Needs to look like this:

[fortran]
function WinMain (hCurrentInst, hPreviousInst, lpszCmdLine, nCmdShow)
!DEC$ ATTRIBUTES STDCALL,DECORATE,ALIAS:"WinMain" :: WinMain
use IFWIN

integer(SINT) :: WinMain
integer(HANDLE), intent(IN) :: hCurrentInst, hPreviousInst
integer(LPCSTR), intent(IN) :: lpszCmdLine
integer(SINT), intent(IN) :: nCmdShow

call REP
WinMain=0
end function WinMain
[/fortran]

[Kenny_T_1]

perfick, thank you!

K

[Kenny_T_1]

ok, so now to build my complete app using IVF...

For all our apps, we have a common set of modules - how do I refer to them?  I don't think i want to copy the module source files (and resulting MOD files) into each project folder.  Also, the order of the compilation of the modules is important, as some files USE modules defined in others.  How do i force the order of compilation?

K

[Steven_L_Intel1]

What I usually recommend is that you create a static library project for your modules. Then make this a "dependent project" of the executable projects - this will automatically make the compiled modules and the library available to the executable project. Add the library project to the app "solution", right click on the executable project and select Dependencies. Check the box for the library project.

You do not force the order of compilation. If the module sources are part of the project, they will be compiled in the proper order. If you are using a subproject, then they'll all be compiled before the app project needs them.

[Kenny_T_1]

ok, thanks.  in an effort to play at "arne saknussemm" it should be noted that FTN95 uses a different KIND scheme.  See:

http://stackoverflow.com/questions/838310/fortran-90-kind-parameter

K

[Kenny_T_1]

i'm having some issues with modules.  The .mod file is being generated in the "debug" folder, but i don't seem to be able to "USE" it?  i get errors such as:

C:\intel_vs\Lib1\x_units.f90(258): error #6457: This derived type name has not been declared.   [DSCA]

DSCA is declared here, in a different source file.

[fortran]

MODULE D_TYPES

...

 TYPE DSCA
  SEQUENCE
  REAL*8        :: V                    ! 0                               
  CHARACTER*32    :: STR                  ! 8
  TYPE (RUNIT)    :: VU                   ! 40, 44, 48                      
  INTEGER        :: SET, ICODE, PREC, US ! 64, 68, 72, 76
  CHARACTER*16    :: CAT, CODE               ! 80, 96
  CHARACTER*32    :: MASK                 ! 112
  REAL*8        :: MN, MX, DEF          ! 144, 152, 160
  CHARACTER*20    :: PROMPT               ! 168
  CHARACTER*40    :: DESC                    ! 188
  REAL            :: ERR                    ! 228
 
  END TYPE DSCA

...

[/fortran]

and i'm using it, thus:

[fortran]

MODULE X_UNITS

  USE D_TYPES
...

INTERFACE

...

SUBROUTINE X_DateIAdd (D1, IM, D2)
  TYPE (DSCA)    :: D1, D2
  INTEGER        :: IM(:)
  END SUBROUTINE

...

END INTERFACE
[/fortran]

my compiler command line (which i haven't edited) looks like this:

/nologo /debug:full /Od /warn:interfaces /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /check:stack /libs:static /threads /dbglibs /c

What else do I need to set?

K

[IanH]

Interface bodies for external subprograms (the SUBROUTINE X_DateIAdd... thing inside the X_UNITS module) do not, by default, inherit things from their host scope.  DSCA is known in the host scope because it has a use - there's no such USE in side the interface body so that name is not defined.

You can either add `USE D_TYPES` to the inside of that SUBROUTINE X_DateIAdd interface body, or if you want to play on the Fortran 2003 swings, you could add `IMPORT DSCA` to that interface body - this enables inheritance of that symbol from its host.

(Because the type is a sequence type, you could also repeat its entire definition, but that's a lot of typing.)

Your previous compiler needs a bit of a kick up the backside if it didn't complain about this.

[Kenny_T_1]

Thanks Ian, that fixed that problem but i have a subtly different one as well!  (sorry, but hopefully the effort involved here will help others in the future!)

i have the following source, in a single file:

[fortran]

MODULE D_TYPES
...

TYPE CSCA
  SEQUENCE
  CHARACTER*40    :: V
  INTEGER        :: SET, ICODE
  CHARACTER*16    :: CAT, CODE
  CHARACTER*20    :: PROMPT
  CHARACTER*40    :: DESC
  CHARACTER*40    :: DEF
  END TYPE CSCA
...

INTERFACE
! ===========================================================================

SUBROUTINE DT_CSCADflt (V, CDEF)
  USE D_TYPES
  TYPE (CSCA)    :: V
  CHARACTER*(*)    :: CDEF
END SUBROUTINE
...

END INTERFACE

[/fortran]

but i get the following errors

C:\intel_vs\Lib1\d_type.f90(1045): error #6928: The module-name on a USE statement in a program unit cannot be the name of any encompassing scoping unit.   [D_TYPES]
C:\intel_vs\Lib1\d_type.f90(1046): error #6457: This derived type name has not been declared.   [CSCA]

if i leave out the "USE D_TYPES" line, i still get the second error...

what's the fix?

K

[IanH]

If you stick to Fortran 95, the fix is to either move the type definition into a new module and then USE that module in both D_TYPES and the interface body, or (and this is only because the type is a sequence type) repeat the entire type definition inside the interface body. 

(If the type wasn't a sequence type, then you would need to go the separate module approach.)

If you advance to Fortran 2003, then you can use the statement IMPORT CSCA in place of the USE inside the interface body.

[Kenny_T_1]

OK, if I understand correctly, i have to have separate MODULE source files for the TYPE definitions, INTERFACE block and CONTAINS block?  or can the INTERFACE and CONTAINS blocks stay together?

K

[Les_Neilson]

Kenny
The simplest solution is to add the IMPORT statement within the interafce block.
You may specify specific items(s) e.g. IMPORT :: CSCA
or
just have IMPORT on its own then "all of the accessible named entities in the host scoping unit are imported." (from the help).

Les

[IanH]

If you don't want to use the F2003 import statement that Les mentions, the F95 module arrangement looks something like:

[fortran]MODULE some_name
  IMPLICIT NONE
  TYPE CSCA
    ...
  END TYPE CSCA
  ...
END MODULE some_name

MODULE D_TYPES
  USE some_name
  IMPLICIT NONE
  INTERFACE
    SUBROUTINE DT_CSCADflt(V, ...)
      USE some_name
      IMPLICIT NONE
      TYPE(CSCA) V
    END SUBROUTINE DT_CSCADflt
  END INTERFACE
  ...
END MODULE D_TYPES[/fortran]

The contains statement (in this case) is a structural part of the syntax of a module - it separates the specification part of a module from the procedures defined by the module.

[Steven_L_Intel1]

For more information on this topic, see Domestic or Imported?

[Kenny_T_1]

ok, but...

I still have to have an "import" line for each function, thus?

[fortran]

INTERFACE
! ===========================================================================

import
SUBROUTINE DT_CSCADflt (V, CDEF)
  TYPE (CSCA)    :: V
  CHARACTER*(*)    :: CDEF
END SUBROUTINE

import
SUBROUTINE DT_FSCADflt (V, CDEF)
  TYPE (FSCA)    :: V
  CHARACTER*(*)    :: CDEF
END SUBROUTINE
[/fortran]

K