I would like to run a code generator every time my project is built in Visual Studio, even if no source file in the project was changed. Therefore I would like to have a custom build step set up as explained in Visual Studio: Run C++ project Post-Build Event even if project is up-to-date.
How can I create such a build step with CMake?
I think a custom target is what you are looking for: add_custom_target
From the documentation:
Add a target with no output so it will always be built.
Or if you are generating a code file,
https://cmake.org/cmake/help/v2.8.8/cmake.html#command:add_custom_target
can be run POST_BUILD and generate output.
This is afaik not possible with CMake, and is therefore a missing feature for sure.
The answer from Tarydon in the question you refer to, is about setting up precisely what you want - a "Custom Build Step". This means that you still only have your main target (VS Project), with something that looks like a "Post-Build Event" but technically isn't, since Post-Build Events aren't run if the project is up-to-date.
The answer from tpg2114 works, but has one major drawback; it spams your solution with phony projects. In case you have a hundred projects in a solution, having to add another hundred just as post-build wrappers to the first hundred is of course undesirable.
Depending on your situation, it might sometimes be easier to use Post-Build Events and force a rebuild of at least one source file, for the project to actually build and therefore also run your custom command.
Related
I've been redesigning my custom VC++ build to be compatible with the new TFS 2015 Build solution.
The issue is running msbuild. I can post perhaps a simplified version, but my solution contains two items:
1 Makefile Project designed to build all of the libraries required, and
1 .exe project.
I have a reference in the .exe project to the makefile project, so that the build of the .exe forces the build of the library if needed.
The issue we are seeing is that when we do a rebuild with msbuild of the solution, it first rebuilds the library, and then when it gets to the .exe, it cleans the library project, causing some of the rebuilt files to be deleted and then preventing the link of the .exe file because the .lib file was deleted.
Why is it cleaning the makefile project again? It seems like when it gets to the .exe project, it re-resolves the dependency, and does not know that the library project was already rebuilt.
Thanks in advance. Larry
If multiple projects are in the same folder, Visual Studio attempts to erase output folder (typically Debug or Release) when the next project will be compiled. The best solution is to put each project in the separate folder.
I didn't go through all details but the reason this happens is that when building on the command-line, rebuilding the exe project results in Clean + Build of the exe project, and the Clean target for the exe project eventually calls the CleanReferencedProjects Target which results in Clean being called on your Makefile project (and later on, Build as well).
This CleanReferencedProjects is conditional on the properties BuildingInsideVisualStudio and BuildProjectReferences, so building inside VS skips this step anyway because BuildingInsideVisualStudio is true, and it's even documented:
When building the project directly from the command-line, clean those referenced projects
that exist on disk. For IDE builds and command-line .SLN builds, the solution build manager
takes care of this.
The BuildProjectReferences property is documented as follows:
By default we will build (and if applicable, clean) all project references. But this can be used to disable that
So one possible solution is calling msbuild some.sln /t:Rebuild /p:BuildProjectReferences=False. In the case with only 2 projects this will work properly, but I cannot guarantee this will always work in more complicated situations with more inter-project dependencies.
Now one thing got me wondering: how come I've never seen this behaviour myself? The answer lies in that I don't use makefile projects often, and the C++ projects which I do use are slightly different: there, the Rebuid target is defined in terms of Clean+Build (while for a Makefile project it is a standalone, separate target). As such when the exe project calls BuildProjectReferences, it will call Clean in the C++ project, but that results in
Target "Clean" skipped. Previously built successfully.
because when the C++ project's Rebuild was called it called Clean and Build already.
So another possible solution is doing the same for the Makefile project. You say that your Rebuild has additional requirements; I don't know what they are nor why they are needed (and arguably it is wrong that Rebuild does not have the same effect as Clean + Build) but this might work anyway, for example with this in the makefile project (all the way at the end of the file):
<Target Name="Rebuild" DependsOnTargets="Clean;Build">
<!--additional requirements here perhaps?-->
</Target>
everything beaves properly and Clean/Build is called once only.
If none of these solutions apply I don't immediately see another way than removing the makefile project from the solution, and manually building it before the solution both locally and in TFS.
I have a C++ project for which I need to run a custom build tool on some header files to generate code that is required when compiling this project. In general my configuration works. I trigger a build, VS/MSBuild detects whether the output files are up-to-date and runs the custom build tool only if necessary.
However, a problem arises if the build is run in combination with another configuration of the same project. Both configurations depend on the output files of the custom build tool. So if run sequentially only one configuration should trigger the custom build tool to run. For which ever configuration a build is triggered second the output files of the custom build tool are already present and up-to-date. So there is no need to build them again. Unfortunately this is exactly what is happening. Since the custom build tool takes quite some time to run, this increases build times dramatically.
Another interesting aspect is, that once both configuration have run, I can trigger any of them again and the custom build tool is not invoked.
What I would have expected from the documentation is that the custom build tool is triggered:
If any of the files specified as Outputs is missing
If the file for which I specified the custom build tool was modified later than any of the existing files specified as Outputs
If any of the files I specified as Additional Dependencies were modified later than any of the existing files specified as Outputs
But all of this independent from the configuration for which the build was triggered.
Does anyone have an idea on why this might happen? I checked that the settings for the custom build tool are identical for both configurations. The output files are generated into the same folder for both configurations.
The documentation you're referring to is basically correct but it omits to say that everything in there is basically per project configuration/platform because it uses tracker.exe which depends on .tlog files which by default go into the intermediate directory. So as you figured out, making all configurations use the same location for the tlog files should keep the tracker happy and only invoke the custom build tool when needed, independent of configuration/platform. I'm not sure I'd recommend any of this though, sharing temporary object files might cause you problems later.
Another way to deal with this is adding a seperate project with just one configuration, say 'Custom', and do the custom build there. Than make your current project(s) depend on that project and in the solution's Configuration Manager adjust all entries so each configuration you have now builds the 'Custom' configuration for the new project.
I'd like to setup a TeamCity build that will perform an incremental build.
For this, i want to store the build outputs (.dll files) as artifacts, and reuse them on every subsequent build (copy the latest artifacts to the build agent before starting the build).
This will effectively place the last build's artifacts in the project's output folder, so MSBuild could use those artifacts to determine whether it needs to rebuild anything from sources.
I've tried to do this, but it seems TeamCity doesn't allow configuring artifact dependencies from the same build configuration.
For example, if i have a "Build Plugins" configuration that generates a collection of plugin DLLs, i cannot use these as a dependency for the same build configuration...
Is there any inherent way to overcome this in TeamCity, or to create an easy solution myself?
It appears it is only possible to do this when using templates.
You can create a template for a build. Then you create a build from that template. After that you add this build to the artefact dependencies from the template. This allows for circular dependencies.
I have found no other way.
It looks like you can do this now! It seems to work in 9.0.1, and TW-12984 says it should work as far back as 8.1.
I have a source code for a project with their make files. I want to create a Visual Studio (2005) solution from it. Is there any direct way to do this? can anyone help me please. I spent hours for searching, but couldn't find a way to do this.
Thanks.
Unfortunately, Microsoft removed this capability after VC++ 6.
If all you're looking to do is to build a Visual Studio project from a command line or script, you can use the devenv command to build using the settings in a project.
Something like:
devenv /build debug /project myproj myapp.sln
Ans starting with VS2010, C++ projects will use the MSBuild system, so you can drive builds using that technology.
If you really want a makefile, you'll need to write it up by hand (or maybe there's some 3rd party tool out there that I'm unaware of).
I'm not sure whether this solution can help you. Which I tried and it worked well in my previous projects. It need manually add the files.
Create a blank VS solution/project. Add the source files into that project.
Mark all source files as "Excluded from building". You can right click the files in project explorer and find the setting. So now nothing will happen when you build your project.
In project setting, find something like "Custom build step". Add the commands that invoke your original build command. (You may write different build command for debug/release ). You can also set the post-build actions such to copy your result to some folder....
Now you can edit and build source files.
For my experience, I can even debug it after setting the executable.
Hope this can help you.
If this is a one-off then it is easier to just create the VS project manually in visual studio.
If you are going to need to do this often look at ceating the project in something like cmake or Qt's .pro whcihc an generate makefiles and VS build files from the same defintion.
Do you want to use the makefile to build? You can create a project from existing source in VS 2005 and setup the project to use make to build (and the wizard will take you through all of this).
I am using VS2010.In order to build you can create a project from existing code. In VS2010 you can create project from existing code File->New->Project from Existing code. You can specify the other parameters and then ready with the solution. I did not go with make file but followed this approach which is working great.
In Visual Studio (2008) is it possible to force the Post-Build Event for a C++ project to run even if the project is up-to-date?
Specifically, I have a project which builds a COM in-process server DLL. The project has a post-build step which runs "regsvr32.exe $(TargetPath)". This runs fine on a "Rebuild", but runs on a "Build" only if changes have been made to the project's source.
If I do a "Build" without making any changes, Visual Studio simply reports that the project is up-to-date and does nothing - the Post-Build Event is not run. Is there any way that I can force the Event to run in this situation? This is necessary since although the DLL itself is up-to-date, the registration information may not be.
You can use the Custom Build Step property page to set up a batch file to run. This runs if the File specified in the Outputs setting is not found, or is out-of-date. Simply specify some non-existent file there, and the custom build step will always run. It will run even if your project is up-to-date, since the Output file is never found.
Use this DisableFastUpToDateCheck
See an example:
<PropertyGroup>
<PostBuildEvent>IF EXIST C:\Projects\Copy_Files_To_Instance.ps1 ( powershell -file C:\Projects\Copy_Files_To_Instance.ps1)</PostBuildEvent>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
The registration information is determined largely by what's in the .rgs file. If that file changes the project will get built. I am not sure how else COM registration can change without making the project dirty. Do you mind providing more details about your particular situation?
In Visual Studio 2017 (perhaps other versions as well), for C# projects (haven't checked for C++ projects per OP's actual question) there is an option for "Run the post-build event:", and one option is "Always", which will run the Post-Build even if nothing has changed, rather than simply reporting that the project is up to date: