- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a Visual Studio solution which compiles/builds a Fortran project and batch builds four executables: Debug/Release, Win32/x64. The release executables are used by our clients. Unfortunately, there exists an equivalent solution which compiles/builds four more executables: Debug/Release, Win32/x64 with a tiny change (code-wise) to the source. This second set of code has different resource files (3) and two different source files (2 modules). Admittedly, the difference here is trivial but the necessity for the second solution is crucial.
Why? The difference in the two solutions is the module
MODULE PRECISION_SPECIFICATION INTEGER, PARAMETER :: P = SELECTED_REAL_KIND(6, 30) END MODULE PRECISION_SPECIFICATION
This module either uses this specification for "single" precision or the specification
SELECTED_REAL_KIND(12, 100)
for "double" precision. Then every other piece of code which has floating-point processing uses this module. Obviously, the executables created between the solutions differ greatly.
The question I have is whether I can create BOTH sets of executables in the same solution. The problem lies in keeping the two solutions current. It is a pain to tweak code in one solution, copy the changes to the other, and compile/build each separately. Is there any way out of this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Project1 lives in its own folder has the SPmodule and all the other source files
Project2 live in its own folder and ONLY had the DPmodule, all the other files are added to the project by picking files in the project1 folder (except the Spmodule!).
So when you build the exe's and other stuff for project1 are created in release, debug folders of project 1 and stuff for project2 are created in release, debug folders of project 2
There are only one set of source.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can have two projects in the same solution and can have some shared source files between the two projects.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Correct, though only one executable can be the "startup project" at any one time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can perhaps use preprocessor variables to select precision.
! default real types (rldf) as type 4 or 8
!DEC$ IF DEFINED (WIN32)
integer, parameter :: rldf = 4 ! default real floating point
!DEC$ ELSEIF DEFINED (WIN64)
integer, parameter :: rldf = 8 ! default real floating point
!DEC$ ENDIF
scott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh, I hope one isn't changing the kinds based on address width! That would be... wrong. I didn't get that the OP wanted that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, no kinds are being changed based on address width. It is just that in numerous routines, including the PROGRAM itself, there is an entry at the top
USE PRECISION_SPECIFICATION
Then deeper in the routine would be declarations
REAL (KIND = P) :: A, B, C
and often there are constants within the code declared as
0.12345_P
or the like. Assuming the PRECISION_SPECIFICATION module is in its own file (one for each project), how might one keep the sources separate and yet connected? The real problem I am having is code duplication. I have carbon-copy code for 100+ files between these two projects and, despite my best intentions, features sometimes creep in one or the other. I have source control at present over just one of the projects.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The way I would do this is make the PRECISION_SPECIFICATION module its own library projects, one for each kind. Then the various projects would use project dependencies to select one of the other. You can have the same source file in multiple projects, so a change to one will be reflected when the others are built.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So something along the lines of
- SinglePrecision (project consisting of the PRECISION_SPECIFICATION for single and whatever else is needed)
- Single (project consisting of the rest of the source code with project dependency on SinglePrecision)
- DoublePrecision (project consisting of the PRECISION_SPECIFICATION for double and whatever else is needed)
- Double (project consisting of the rest of the source code, same as above, but with project dependency DoublePrecision)
Can I maintain the source for one total without duplication? Do the "precision projects" need to be compiled to libraries?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Project1 lives in its own folder has the SPmodule and all the other source files
Project2 live in its own folder and ONLY had the DPmodule, all the other files are added to the project by picking files in the project1 folder (except the Spmodule!).
So when you build the exe's and other stuff for project1 are created in release, debug folders of project 1 and stuff for project2 are created in release, debug folders of project 2
There are only one set of source.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the response. Sometimes it takes a "duh" moment to comprehend.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the same Solution, you can create additional builds (not just Release and Debug). For example you might create
ReleaseSingle
ReleaseDouble
ReleaseSingleTBB
ReleaseDoubleOpenMP
DebugSingle
DebugDouble
DebugSingleTBB
DebugDoubleOpenMP
Whatever number you want.
You would want to be smart to build the non-configuration dependent code into a library, such that it is not unnecessarily recompiled.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, getting the TBB and OpenMP versions included is part of the development process as well as GPU when and if I can put out the effort.
The re-factoring which is accompanying this code development is ongoing. Thanks for the help.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page