Feature request: "Inherit from parent or project defaults" for Additional Options

[Øyvind_J_]

Sometimes it is useful, or even necessary(?), to type in compile flags manually in the property field Configuration Properties->Command Line->Additional Options. However, "Additional Options" behave somewhat inconsistently.

For C and C++ projects, you can specify project wide Additional Options, and you can also add source file specific Additional Options. In Visual Studio 2010, there is a tick box immediately above the "Additional Options" field that reads "Inherit from parent or project defaults". This toggle is very convenient and works exactly as you would expect. It allows you to mix project wide flags and source file specific compile flags easily.

Fortran projects, on the other hand, have no tick box to toggle inheritance of Additional Options. Instead, the compile flags are applied in a rather inconsistent way: Source files that have their own set of Additional Options do *not* inherit from the project, but all other source files do. This makes it easy to loose track of Additional Options, and creates difficulties for external tools, such as CMake. (I first encountered this issue using CMake, see: http://public.kitware.com/Bug/view.php?id=15381.)

So, here is my feature request: It would be great if Fortran projects would either always inherit Additional Options, or if there was a tick box like the one seen in C/C++ projects.

Øyvind

[FortranFan]

Is it possible for you to share what additional options are you using for your Fortran projects?

[Steven_L_Intel1]

Either I don't understand your request or the behavior you describe isn't consistent with what I have seen. Would you please attach a .vfproj file that demonstrates how a source file with modified options doesn't inherit the other options from the project?

[Øyvind_J_]

Sorry, I'll explain what I mean more clearly. I have attached a fortran project and a C++ project to demonstrate the missing feature.

In the .vfproj file you'll see that the project has an item which reads AdditionalOptions="/dummy_option1", and the source file has the item  AdditionalOptions="/dummy_option2". When I compile the project, it is only the source file specific flag "/dummy_option2" which is used. What I am requesting is that the AdditionalOptions of the source file should be appended to the AdditionalOptions of the project. The file would then be compiled with both flags: "/dummy_option1 /dummy_option2".

The feature I am requesting is available for C/C++ projects. In the attached C++ project you'll see that the AdditionalOptions of the source file are combined with the project's AdditionalOptions, so that both are used during compilation. In the IDE, there is a tick box that allows you to either replace or extend inherited AdditionalOptions.

Here is a use case where the feature would be very useful: You have a large project with lots of source files, and some of them have specialized compile flags listed in the AdditionalOptions field. If you then want to add a project wide flag to the AdditionalOptions field, you have to manually go through all source files that have specialized AdditionalOptions fields. This is cumbersome and error prone. On the other hand, if AdditionalOptions were handled as it is in C/C++ projects, you could just add the flag to the project's AdditionalOptions, and it would propagate to all files. (Except if you deliberately disabled inheritance for a certain file by unchecking the tick box.)

@FortranFan: The behaviour is the same whatever flag you enter in the AdditionalOptions field.

[Øyvind_J_]

This screenshot displays the properties dialog of a C++ project, and I have highlighted the feature I am requesting.

[jimdempseyatthecove]

You can somewhat accomplish the same thing:

Using Visual Studio, open Solution Explorer, browse for the Fortran Project of interest, open/explode, locate file of interest, Right-Click, select Properties, then in the appropriate options section(s), replace the "Inherit from parent..." with the specific options you desire. After saving these, you will then notice tick mark on the file listed in the solution explorer indicating file not inheriting from parent or project defaults.

Jim Dempsey

[Øyvind_J_]

Jim, thanks for pointing that out. The tick mark does help somewhat, at least for a small project.

However, the functionality of C/C++ projects is much more convenient, and it saves a lot of time and frustration. I'm thinking about the time and effort you might spend debugging a big project in which a few source files is accidentally compiled with the wrong options.

Øyvind

[jimdempseyatthecove]

This worked fine with me on a solution with 13 projects and 750 source files. I do not know if you consider this small or not.

In my situation, I use the different build options to overcome compiler bugs (rare, but they do occur), where the bug only crops up in one or a few source files. I also use this for debugging. I create different builds:

Debug (full debugging all files, no OpenMP)
DebugOpenMP (full debugging al file, with OpenMP)
DebugOpenMPfast (full debugging on only a few select files, no debugging on remainder, with OpenMP)
...

In a solution such as mine, it became untenable to perform tests with full runtime checking enabled. The release build, full optimization, may take several days to reach point of interest. With full debugging and runtime checking enabled, you couldn't work productively.

You likely have different requirements.

You also have an alternative:

Break your single project solution (my assumption) into multiple project solution. Each project can then have its own defaults. For example you may have one project with "firm" code (code that is known to be good and needs not to be debugged), and a second with "somewhat firm" code that does not need runtime checks, and "under development" that contains code that requires full debugging and runtime checks.

As you finish code in one group, you can then use the solution explorer to drag the source from one project and drop it into another.

Your feature requires of having a property page check box hides the fact that it is checked (you only know if you open the property sheet).

Jim Dempsey

[Øyvind_J_]

The solution I'm working on has 24 projects and ~200 source files which are a mix of Fortran and C/C++. I like the techniques you suggest, and especially to organize source files under different projects according to maturity of code. I haven't thought of that before, but it might be possible, because I think in general that the modules that are deeper in the hierarchy are also more thoroughly tested.

Øyvind