Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
21 Views

Source control multiple executables

Jump to solution

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?

0 Kudos

Accepted Solutions
Highlighted
Valued Contributor III
21 Views

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.

 

 

View solution in original post

0 Kudos
11 Replies
Highlighted
Valued Contributor III
21 Views

You can have two projects in the same solution and can have some shared source files between the two projects.

 

0 Kudos
Highlighted
21 Views

Correct, though only one executable can be the "startup project" at any one time.

0 Kudos
Highlighted
New Contributor I
21 Views

 

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

 

0 Kudos
Highlighted
21 Views

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.

0 Kudos
Highlighted
21 Views

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.

0 Kudos
Highlighted
21 Views

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.

0 Kudos
Highlighted
21 Views

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?

0 Kudos
Highlighted
Valued Contributor III
22 Views

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.

 

 

View solution in original post

0 Kudos
Highlighted
21 Views

Thanks for the response.  Sometimes it takes a "duh" moment to comprehend.

0 Kudos
Highlighted
21 Views

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

0 Kudos
Highlighted
21 Views

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.

0 Kudos