Welcome to our forums
In my software I am using
include <clearwin.ins>
include <exceptn.ins>
include <opengl.ins>
include <win32api.ins>
include <windows.ins>
Can I change all of them and use modules instead? Which modules?
For Silverfrost compilers...
INCLUDE <clearwin.ins> USE clrwin
INCLUDE <win32api.ins> USE mswin32
INCLUDE <win32prm.ins> USE msw32prm
INCLUDE <windows.ins> USE mswin
INCLUDE <opengl.ins> USE opengl
The code for mswin is:
module mswin
use msw32prm
use mswin32
use clrwin
end module mswin
So mswin is the same as clrwin + mswin32 + msw32prm.
There is no standard module for exceptn.ins.
Paul,
Can you clarify something please? The <> means 'search the default include directory' and is non-standard. As written above, presumably the default include directory is searched. How then do we differentiate between the current and default directories? Does USE use the same non-standard syntax?
Assuming that the type of the USE file is .MOD, this is not readable by a text editor, so in that case is the .INS file never totally redundant (assuming you need to know anything about its contents).
Eddie
Eddie
FTN95 uses a list of INCLUDE folders starting with the Silverfrost INCLUDE folder but also containing any folders added by the user via /INCLUDE or an environment variable.
When using <file>, this list is scanned first before scanning the local folder. When using 'file', the local folder is scanned first before scanning the list.
So it only makes a material difference if the name of an include file (that is found from the list) is duplicated locally.
USE statements contain the name of the module and not the name of a file. So you can have more than one module in a file and there is no quotation marks nor <> in a USE statement.
Mod files have the extension .mod (for 32 bits) and .mod64 (for 64 bits). For FTN95 the mod files are encoded but the corresponding .ins file will be maintained should you need to know the code for the module.
The Silverfrost folder FTN95\source64\ contains some source files for using ClearWin+ with third party compilers. These use ISO_C_BINDING interfaces so the corresponding mod files require associated obj files at link time. This is not the case when using Silverfrost compilers because the interfaces do not require any associated object code. This may change when we implement ISO_C_BINDING in FTN95.
Paul, my new problem is now that I have a directory ..\Moduls for my own globally used moduls. It is parallel to all my projects. I tried to add this direcctory to the standard mod_path environment variable, but the compiler does not except this. Erwin
Erwin
What does MOD_PATH look like? Use a semi-colon separator and the full path. Type SET on the command line to see it.
OK, I slept on it, but I still don't understand what this implies:
USE statements contain the name of the module and not the name of a file. So you can have more than one module in a file ...
OK if the module is coded into the same source code file, What if it isn't? Does it all get sorted out by SLINK? Where do you specify the name of the MOD file?
I think I'll stick to INS
Eddie
Paul, that's what I tried: mod_path=C:\Program Files (x86)\Silverfrost\FTN95\include;..\Moduls
INTEGER FUNCTION f3dReadData ()
USE f3dViewData
USE GrafFiles
USE opengl
IMPLICIT NONE
INCLUDE <clearwin.ins>
::
I changed include opengl to USE ...
Result: Compiling file: 3dReadData.f90 D:\Bgo_7.0\3dView\3dReadData.F90(6) : error 404 - Cannot find definition for MODULE OPENGL Compilation failed.
A .mod file is created for each module and FTN95 exports object code for any modules that are USEd.
So if test.f95 contains a module m1 and a main program then compiling will generate m1.mod and test.obj. Then linking generates test.exe.
Alternatively if test.f95 contains modules m1 and m2 and no main program then compiling generates m1.mod, m2.mod and test.obj.
Hi Paul,
Thanks for the clarification.
Erwin
Try using the full path instead of ..\. Try changing the order of the USE statements. Try using INCLUDE <opengl.ins> instead of USE opengl.
Failing that, please send me a short working program that demonstrates the failure.
Paul,
the problem is: There is no module file for opengl; neither .mod nor .mod64. Can you please provide these files and let me know where to place them.
There is no problem to change the other files from 'include' to 'use'.
Erwin
Erwin
These files should be in \Program Files (x86) \Silverfrost\FTN95\include but here is a link to download them files if they are missing.
Perfect. Thanks.
I have been puzzled by this thread. I would have expected that INCLUDE and USE would create different variable definitions. I think they could only be switched when they are only defining symbols. This is a very restricted subset of module usage and could be confusing as an example.
John
The standard Silverfrost INCLUDE files contain interfaces to functions and integer parameters that are in Silverfrost and common third party DLLs. There is no related object code for these files. In that sense that do only provide 'symbols'. The same is true for the corresponding modules.
Quoted from JohnCampbell I have been puzzled by this thread. I would have expected that INCLUDE and USE would create different variable definitions. John
Not necessarily.
The INCLUDEd source may contain only comments. It may contain only executable statements and no variable definitions. Or the converse. Included lines may be rejected by the compiler if they lead to syntax errors.
The compiler will judge the included lines only after they have been merged in place in the including source code.
The USE statement, on the other hand, can appear only after a subprogram declaration and before any variable declarations. The module that is being referred to must already exist. That module may provide variables or module procedures or both.
While it may 'Not necessarily' be the case, I was trying to highlight that it can be that local variables can be defined, which makes INCLUDE and MODULE/USE different in their use.
As clearwin.ins appears to only define Names or Symbols, it may be safe.
But in general, when using a library of routines, a module or include file can not be safely mixed, which is the case of all libraries I have developed.
I am still uncertain about the limitations on using a MODULE in a .dll
John