XE 2015 changes some project settings

[DavidWhite]

After installing XE 2015, but still using XE 2013 to build a project, I got this warning, and corresponding error that the DLL was not found:

HEADTANK: warning: TargetPath(C:\Open\kwc54dw\Dev\Winyldmd\trunk\HEADTANK\Release\HEADTANK.dll) does not match the Linker's OutputFile property value (C:\Open\kwc54dw\Dev\Winyldmd\trunk\HEADTANK\Release\yieldmod.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).

For this project, as indicated, I am not using the default Target Name, but in the configuration properties for the compiler, this has been changed back to $(ProjectName) instead of the previously specified name (yieldmod).

[Steven_L_Intel1]

What do you mean by "still using XE 2013 to build"?

I haven't run across the project settings changing on their own and I would have expected it to come up during beta. I'll try some experiments and see if I can reproduce this.

[DavidWhite]

Steve,

The installer resets the project setting for the output filename in the compiler only - reset from the hardcoded value back to $(TargetName).  The same change was not seen in the linker settings, hence the error in the build.

I was still using the older compiler for the build (i.e. have not selected <Latest>) in the compiler selection.

I have not encountered this change in project settings for any other recent install, so was surprised to see my build that executed perfectly yesterday fail after installing XE 2015.

Thanks,

David

[IanH]

I saw this when using in the beta and assumed that it was a historical mistake on my part - same situation where a DLL project had an output name different to the project name.

I don't think that Target Name property existed in earlier versions of the integration (or if it did it wasn't exposed to users) - so it isn't that the property got "reset" - it just wasn't previously defined. 

With the new version, set that Target Name property to be the base name that you want for the DLL (or whatever) and then you can "default" the output file property in the linked property settings.

[DavidWhite]

Ian,

This property very much was accessible under the previous version - in VS under Configuration Properties / General / Target Name.

It is just that previous integrations did not reset it during installation.  The new installer resets this to the default $(ProjectName).

Just one more area where the integration breaks current project and solution files.

Thanks,

David

[IanH]

Are you sure?  this shows the general tab as I see it with ifort 14.0.3 integration and the VS Shell.

With the 15.0 integration on VS2010 professional I see additional Target Name and Target Extension properties listed on that tab.

[DavidWhite]

Ian,

My projects also have TargetName - not sure if this is because they are DLL projects?

David

[IanH]

My screenshot was of a DLL project too.

Is your screenshot from a machine without ifort 15.0 installed?

[DavidWhite]

Ian,

This is from a machine with v15 installed.  I have no other machines I can access right now (the install at home trashed my machine).

However, this field was accessible before I installed v15, because I have been using it for several years.  The image I showed there was from a project where the DLL name is the same as the project name; the earlier error came from a project where they were different.

I appears that during installation of the VS integration the manual entry of the DLL name was replaced by the default (Project Name) for the compiler options, but did not make the same change for the linker options.

Regards,

David

[Steven_L_Intel1]

The installer itself didn't change anything. I could believe that opening a project with the new integration made a change. I'll try to reproduce this.

[Nathan_K_]

This issue occured for us as well: When I installed and tested 15.0 our solution did not build because the new integration appears to use the Target Name differently in 15.0 for Fortran DLL projects.

The projects that failed are DLL projects that have a different output file name in the Linker properties compared to $(TargetName)$(TargetExt) specified in the General properties of the project.

The previous integration on my system (Composer 2013 SP1 Update 3) did not appear to make any use of the default Target Name specified in the General properties so it did not fail to build. In our projects we did not manually specify the Target Name -- we had left it as the default.

[DavidWhite]

it's not just the previous integration - all previous integrations for the last 5 years or more have not touched any manually specified target names.  This is the first one to enforce the default in preference to a user specified one.

David

[Steven_L_Intel1]

Here's what I'm seeing.

Prior to the 2015 integration, there was no Target Name property. The Output File in the Linker properties had a default value using $(ProjectName). When you open a project with the 2015 integration, it adds the Target Name property with a default of $(ProjectName) and replaces the Output File property with $(OutDir)\$(TargetName)$(TargetExt), even if you had previously changed this. It's this last part that is inappropriate.

Does this match what others are seeing?

[IanH]

I don't see the change in the linker property being made automatically. 

However, I find that property needs to be manually changed (as per the warning message in the original post) in order to successfully build with the new integration - for example the manifest tool is using $(TargetName) and is oblivious to the customized linker output file property.  For the linker property the change is to simply "inherit from project defaults" (and then set TargetName to be the customised name).

This was with a simple DLL only project (dummy (free form!) source file, only change to properties being the linker output file) created using the ifort 14.0.3 integration within the VS 2010 Shell, with the solution and project files then copied across to a machine running VS2010 professional with ifort 15.0.

Immediately after copying over from the ifort 14.0.3 machine, changing properties such as the /warn:all diagnostic level made no other changes to the vfproj file other than the relevant changed property - there is no "TargetName" in the xml.  However, making the linker output file property "inherit from project defaults" results in the new TargetName property being written as an xml attribute to the vfproj file.

[Nick2]

My Linker->Output File used to be:

$(OUTDIR)/../../../../bin/$(ConfigurationName)/$(PlatformName)d/Blah.exe

So, I tried changed the TargetName to:

..\..\..\..\bin\$(ConfigurationName)\$(PlatformName)d\$(ProjectName)

And also changed the Linker->Output File to the default:

$(OutDir)\$(TargetName)$(TargetExt)

However, it's still complaining:

warning: TargetPath(C:\Data\Blah1\Blah2\Blah3\Blah4\Blah5\Win32D\Debug\..\..\..\..\bin\Debug\Win32d\Blah.exe) does not match the Linker's OutputFile property value (C:\Data\Blah1\Blah2\Blah3\bin\Debug\Win32d\Blah.exe). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).

So, I have two issues:

1) Having to manually change all of Linker->Output File into TargetName in order to use ifort 15 (in about 100 places)

2) Is the (whichever tool produced this warning) not recognizing that those two are the same paths?