For example, in my vs2010 project file, I have "Output File Name" (from Project Properties -> C/C++ -> Output Files) to $(IntDir)/%(RelativeDir)/. I know how to do this manually, but for CMake I'm not at all sure.
How do I set such a property, in the CMakeLists.txt file?
When you do add_executable() or add_library(), the target name is the name of resulting binary, which, i think, will turn into "Output File Name" property during generation.
You can also try to set OUTPUT_NAME property for your target.
Related
My build system manually generates some files from others. It's using Visual Studio 2015 with CMake 3.11.4. It uses ADD_CUSTOM_TARGET to invoke some internal scripts. Those scripts end up creating a file containing the timestamp when files where generated and this file is later used to only generate what needs to be.
I want this file containing the timestamp to be deleted when we clean the solution (In Visual Studio, "Build" -> "Clean solution"). I tried to add some CMake instruction:
SET_TARGET_PROPERTIES( MY_TARGET PROPERTIES ADDITIONAL_CLEAN_FILES "C:/dev/build/generated.timestamp" )
SET_PROPERTY( TARGET MY_TARGET APPEND PROPERTY ADDITIONAL_CLEAN_FILES "C:/dev/build/generated.timestamp" )
SET_PROPERTY( GLOBAL APPEND PROPERTY ADDITIONAL_CLEAN_FILES "C:/dev/build/generated.timestamp" )
SET_DIRECTORY_PROPERTIES( PROPERTIES ADDITIONAL_CLEAN_FILES "C:/dev/build/generated.timestamp" )
But none of them makes the file be deleted when I clean.
Is this doable and if so, what am I doing wrong?
I have a solution with 9 projects. All references in each project have their CopyLocal property set to False.
When I build it from VS, none of these referenced binaries are copyed to the output build directory. Similarly, when I build using msbuild, I only see the project binaries and no references.
However, when I specify an output path in the msbuild command, some references are copied and I don't know why? Is there some setting I am forgetting to set? Has anyone seen this before?
When you build your application without setting the OutDir property, the files are copied to the path specified in project properties (Build\Output path). After this, there is another step that copies the referenced project output (*.dll file) to the OutDir of your application (*.exe). But if you set CopyLocal to false, this last step doesn't happen. Like this:
ProjectEXE\OutDir = c:\a\bin
ProjectDLL\OutDir = c:\b\bin
Pay attention to the fact that the two OutDir are different (and differently specified in your projects properties).
But when you set the OutDir using the command-prompt, you are setting both OutDir parameters to the same path. Still there is no final copy of the DLL to the same directory of your application, except for the fact that it is the same location you built the DLL and EXE first time. Like this:
msbuild yourSolution.sln /p:OutDir="c:\a\bin\"
ProjectEXE\OutDir = c:\a\bin
ProjectDLL\OutDir = c:\a\bin
I installed Visual Studio 2010, Qt and Cmake. I configured them. Then I wanted to test by an example code. However, the program cannot find the header files. I searched on the internet and found that there might be a problem with the PATH.
Then, I followed this way that results in failure:
I wrote each folder name separately by putting semicolon between them to
Project > Properties > C/C++ > General > Additional Include Directories.
In this way, program found the header files but it gave me an error LNK1104. I think it happened because the Path for file name expands to more than 260 characters. I learned that from this site.
I tried to find one folder that I can write to PATH. I think it's lib file. But I could not find it.
what should I do to fix this problem?
Setting two values in visual studio will remove this error.
Go to Properties of the project -> C/C++ -> All Options -> Set the correct value for "Additional Options".
Go to Properties of the project -> Linker -> Input -> Set correct the value for "Additional Dependencies".
If you create the project using CMake, then these values will be setup automatically.
When I build a Visual Studio project, the executable is written to the output directory specified in the projects Property Page.
I have a project that has some extra files (e.g., .ini file) that are used by the program.
How can I configure the project to copy the file to the output directory so that when the program runs, it has a copy of the other file in its CWD?
I checked the Property Page of the file and there was nothing useful other than an option to exclude it from the build (which is disabled), and the custom-build-tool command is empty (plus it is a plain-text file that does not need any processing).
For copying a files to the output directory in Visual Studio 2003 you could use Post-Build event:
Right click on the project->Properties
Common Properties->Build Events
Set Post-Build Event Command Line to:
xcopy /y $(ProjectDir)my_file.ini $(ProjectDir)$(OutDir)
OK and build!
Please try select the file in Solution Explorer. Then you should be able to see its properties in Properties window (press F4 if it is not visible). You will find there two properties:
"Build Action" and
"Copy to Output Directory"
Set "Build Action" to "Content", and then - select an appropriate value for "Copy to Output Directory" setting.
File properties window with "Build Action" and "Copy to Output Directory" settings
If the way above doesn't work for you, please read this post "Copy to output directory issue with .inf file". And have a look at this one then "Visual Studio: default build action for non-default file-types"
While I was searching the file’s Property Page for a build-action field, I had a thought: set the custom build step to copy the file (manually). This turned out to be easier than I thought. I had figured it would require using cmd or other external executable (xcopy, robocopy, etc.), but that is not necessary.
I set the Custom Build Step as follows:
Command Line : copy $(InputFileName) $(OutDir)
Description : Copying foobar...
Outputs : $(InputFileName)
Setting the outputs field (correctly) was critical in order to prevent VS from always thinking the project is out of date and requiring to be rebuilt (I’m not certain if it needs to be prefixed with $(OutDir)\).
It is reflected in the Output window as such:
Copying foobar...
1 file(s) copied.
Compiling resources...
Linking...
For VS 2017 the command Dmitry Pavlov posted would be the following:
xcopy /y "$(ProjectDir)my_file.ini" "$(OutDir)"
Quotes are important in case there are spaces in the path to the project directory.
Expanding on Synetech's answer.
In VS2019 right click the file you want to copy in the Solution Explorer and select Properties. Then under General >> Item Type change to Copy File then hit Apply.
You now should have UI fields in the Properties Page for Destination etc.
In case this helps anyone, I needed to copy the output dll of the project i was building into another project.
xcopy /y "$(ProjectDir)$(OutDir)$(TargetName)$(TargetExt)"
"C:\Application\MyApplicationName\bin\x86\Debug"
/y = overwrite file if already exists
$(ProjectDir) = location on your machine where the project lives
$(OutDir) = is where your current build setup outputs the build
$(TargetName) = What the project being built is set to be called. Ex: XXX of XXX.dll
$(TargetExt) = the extension of the build Ex: .dll of XXX.dll
"C:/..../x86/Debug" is the location to copy to.
You need the extra $(OutDir). Otherwise, in the rebuild/clean step it will throw away your source.
CommandLine : copy "$(SolutionDir)last-script.js" "$(TargetDir)Debug"
Outputs : $(TargetDir)Debug\last-script.js
Improving Synetech
answer :
In VS 2013 C++ project Command Line : copy %(Identity) $(OutDir) Description : Copying foobar... Outputs : %(Identity)
It works , But it leads to circular dependency , i.e. it will be executed each time you demand increamental build, no meter it has been already copied.
To solve this , you can add that item at target folder, change path to $(OutDir), and use that in first added item as Output. Drawback - two items with similar name are in solution.
Also usefull xcopy with /d /y parameters in postbuild - copy only if target file date is older.
You could also after the unload the project (Right click on the project >> Unload Project) add the following inside an existent <ItemGroup> tag:
<Content Include="..\..\Config\db.config">
<Link>Config\db.config</Link>
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
<SubType>Designer</SubType>
</Content>
In this case it will grab the db.config file from 2 folders up and put it in the output folder(by default bin/Debug) after creating a Config folder with the db.config file inside
I am getting the following error when building my code.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5):
warning MSB8012:
TargetPath(E:\Study\FWIF\demola\ext-libs\libcommoncpp2-1.6.0\w32\Debug\ccgnu2.dll)
does not match the Linker's OutputFile property value
g\CapeCommon14.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).
I hope that some one will know what to do.
Did you upgrade a project to Visual Studio 2010 from a previous version? If so, this is a well-known issue.
Visual Studio 2010 C++ Project Upgrade Guide
http://blogs.msdn.com/b/vcblog/archive/2010/03/02/visual-studio-2010-c-project-upgrade-guide.aspx
Warnings during upgrade
Here are some of the common warnings that you may run into during conversion:
1) Linker output directory
One of the warnings you may see when upgrading you applications is MSB8012: $(TargetPath) and Linker’s OutputFile property value does not match:
MSB8012: $(TargetExt) ('.dll') does not match the Linker's OutputFile property value 'C:\foo\Debug\MFCActiveX.ocx' ('.ocx') in project configuration 'Debug|Win32'. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetExt) property value matches the value specified in %(Link.OutputFile).
MSB8012: $(TargetPath) ('C:\foo\Debug\MFCActiveX.dll') does not match the Linker's OutputFile property value 'C:\foo\Debug\MFCActiveX.ocx' ('C:\foo\Debug\MFCActiveX.ocx') in project configuration 'Debug|Win32'. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetPath) property value matches the value specified in %(Link.OutputFile).
Link.OutputFile is the value defined at Linker -> General -> Output File on the property page. By default, its value is $(OutDir)$(TargetName)$(TargetExt), which is the same as the value of $(TargetPath). When we convert an application from a previous version, however, there is not an easy way for conversion to parse Link.OutputFile to figure out what exactly the values are for $(TargetName) and $(TargetExt), as different customers may have formatted them in different ways. To work around that, we decided to preserve the value of Linker.OutputFile during conversion. After conversion, $(TargetName) will default to $(ProjectName). $(TargetExt) will default to the default extension for the application type: .dll for Dynamic Library, .lib for Static Library and .exe for Application. Link.OutputFile value will be preserved. Warning MSB8012 will be issued in the conversion log if Link.OutputFile and $(TargetPath) are not the same. You will get the same warnings when building the application.
$(OutDir), $(TargetName) and $(TargetExt) are exposed on the "General" property page, as "Output Directory", "Target Name", "Target Extension", respectively. You can manually change the values of these properties so that you no longer get the warning.
If your project produces Import Library (Linker -> Advanced -> Import Library), you may need to change the Output folder of the Import Library as well after conversion if the Linker output directory is not the default output directory. Otherwise, the generated import lib maybe in a different directory than the linker output.
Debugging.Command is set to default $(TargetPath) after conversion. You may need to make changes so that the right executable will be launched upon F5 (Debugging) or Ctrl + F5 (Start without debugging).
See also here Stackoverflow MSB8012.
What worked for me when converting a VS2008 C++ project to VS2012: right click the project in solution explorer, select properties, in the pop-up: configuration properties, linker, general. Select Output file on the right, this gives a drop-down, select inherent from parent or project defaults. Click apply. This gives the default linker setting: $(OutDir)$(TargetName)$(TargetExt). Re-build the project and the warning should no longer appear.
The same problem occured to me for debug DLLs, that I wanted to have a trailing "D" in the basename. For example, foo.dll (Release) but fooD.dll (Debug). When you refine the output name in the Linker settings of the Debug-Configuration -- the ugly MSB8012 warning occurs.
The only solution that works with Visual-Studio 2010 seems to be a Postbuild-Event for the Debug-Configuration:
#echo off
echo Copying $(OutDir)$(TargetName)$(TargetExt) as $(TargetName)D$(TargetExt)
copy /Y $(OutDir)$(TargetName)$(TargetExt) $(OutDir)$(TargetName)D$(TargetExt)
I had the scenario where my executable name was different than the project name AND I wanted it to build the executable/dll to a different location than where the project was located.
1)Change the default project name to be different.
General->TargetName
< my executable name>
2) Output to a different location where I want the executable to build.
General->OutputDirectory
< my new location goes here >
3) Update the Linker settings.
Linker->General
new value: $(OutDir)$(TargetName)$(TargetExt)
This takes on the new settings from 1 and 2.
I obtained the same error after converting from old project to VS 2010.
To fix this I created empty project of the same type (e.g. .dll, .lib, .exe).
Then I copied its default values in Project Propeties to my project for Output Directory, Intermediate directory and Output File
Goto Project->Properties->Configuration Properties -> Linker->General section
Specify 'Output File' as $(OutDir)$(TargetName)$(TargetExt)
I managed to fix a similar issue by editing the vcxproj file manually.
The OutDir and TargetName settings were at the bottom of the project file.
...
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<OutDir>$(OUTPUT_DIRECTORY)\</OutDir>
<IntDir>$(ProjectDir)\$(Configuration)\$(ProjectName)\</IntDir>
<TargetName>$(ProjectName)</TargetName>
</PropertyGroup>
</Project>
Moving the block above the ClCompile block solved the issue.
I solved this by comparing the project to a very similar project that was working properly. All of the settings in the project properties matched but I found the following extra lines in the vcxproj file of the malfunctioning project:
<Lib>
<OutputFile>.\MCtlDrvX.lib</OutputFile>
</Lib>
I deleted them and the message went away and the output went to the directory specified in the project settings.