Visual Studio 2005 Custom Build for Qt - visual-studio

i've the following in the custom build property of every header file that uses Q_OBJECT:
Command Line: $(THIRDPARTY_DIR)\qt\4.7.0\win32-vc10\bin\moc.exe $(InputFileName) -o moc\$(ConfigurationName)\moc_$(InputName).cpp
Description: ################### moc'ing $(InputFileName)
Outputs: moc\$(ConfigurationName)\moc_$(InputName).cpp
This generates the necessary moc files. I now want to ask visual studio to compile and link these too, to my other source files. Presently i'm using
#include "moc\{Release OR Debug}\moc_Whatever.cpp"# statements in any of the files to force compilation and linking. Evidently i have to keep changing my #include according to debug or release build (i cannot discard $(ConfiguarationName) during moc file generation above for reasons). Plus i dont like the idea of writing this #include in the source files just for the purposes of compilation and linking.
Is there any build step in properties anywhere where i can mention what files will be generated in future and to compile and link them when they are available (VS2005)?
(i cannot use QtPlugin right now)

You simply add those files to the project, my project structure usually looks like this (in Visual Studio Solution Explorer):
Solution
|
+- Project1
|
+- Generated Files
+- Header Files
+- Source Files
In Generated Files, I include References to both, the Debug and the Release moc_xxx.cpp and qrc_xxx.cpp files. For the Debug files, you need to set "Exclude from Build" to true for the Release references and vice versa.
That's pretty much the same what the plugin does.

Related

Have Intermediate CMake Files Appear in the IDE

I am developing a system of build scripts for CMake and have an issue with wanting to have intermediate CMakeLists.txt files appear in the IDE for easier search and edit.
I have a main CMake file that includes a directory that includes several subdirectories for libraries.
CMakeLists.txt
--- SubProjects:
-------CMakeLists.txt
-------ProjectAFolder:
----------CMakeLists.txt
-------ProjectBFolder:
----------CMakeLists.txt
-------ProjectCFolder:
----------CMakeLists.txt
In the SubProjects folder, the CMakeLists.txt is very simple and just includes the subproject folders one after the other:
SET(SUBDIRECTORIES ProjectAFolder
ProjectBFolder
ProjectCFolder )
foreach (subdirectory ${SUBDIRECTORIES})
add_subdirectory(${subdirectory})
endforeach ()
However, when I generate this in XCode or Visual Studio, the IDE does not include the intermediate CMakeLists.txt file anywhere because it does not belong to any individual library or executable target. What is the best way to include this somewhere so it appears in an IDE?
Depends on where you want the file to show up, since it doesn't belong to any target. You can simply add it to any existing target (just as you do with source files) or you can create a new custom target.
add_library(AnyExistingTarget <other source files> SubProjects/CMakeLists.txt)
Or create a custom target:
add_custom_target(MyIntermediateCMakeFiles SubProjects/CMakeLists.txt)
For Visual Studio, you could also use the built-in support for cmake. It will display the source tree in the IDE without any extra work.

How does Visual Studio know my project is up to date so it can skip running MSBuild?

I have a custom MSBuild target included in my C++ project that produces a data file in the $(OutDir) folder for each item of a given item type. I have the item type hooked up with a property page schema so you can select it on files in the solution explorer and my target declares input and outputs so incremental builds work. I have also added my target to the $(BuildDependsOn) property so it is automatically evaluated during the Build target Visual Studio invokes.
Everything seems to work except for one thing: If I delete one of my output data files in the $(OutDir) and then build Visual Studio does nothing and says my project is up to date. If I delete the exe file the project produces or touch the modified time of one of the MSBuild scripts Visual Studio re-evaluates the targts and finds the output file is missing, causing it to be re-built using my target.
From the MSBuild diagnostic logging it seems like Visual Studio is internally maintaining some list of output files and input files that it checks to avoid evaluating the MSBuild script at all. How do I add my output files to this list?
MsBuild/VS indeed have a mechanism to determine what is up-to-date with respect to the input files, it revolves around an executable tracker.exe which scans .tlog files to figure out what a project's output files are. There might be more to it, and if you look around on the internet you can probably get more info about this.
But the thing is you don't really need to understand every single detail of it: you can find a simple usage example for it when inspecting how the built-in CustomBuildStep works and apply that to your case. I'll briefly explain how I got to this because I think it might be useful for you as well in dealing with msbuild questions like these.
If you add
<ItemDefinitionGroup>
<CustomBuildStep>
<Command>echo foo > $(OutDir)\foo.txt</Command>
<Outputs>$(OutDir)\foo.txt</Outputs>
</CustomBuildStep>
</ItemDefinitionGroup>
either manually or via the project's property pages for Custom Build Step you'll see the beahviour is eactly what you need: if foo.txt is deleted a build will start, while a build is marked up-to-date if it is not (well, and when the rest of the outputs are also up-to-date).
Hence the key is to do what CustomBuildStep does under the hood, and figuring that out is just a matter of using your tool of choice to search all occurrences of CustomBuildStep in all files under C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120 (adjust path for platform/VS version used).
This leads us to Microsoft.CppCommon.Targets where the target named CustomBuildStep (mind you, that's the same name as the entry in the ItemDefinitionGroup above) invokes the actual CustomBuildStep command. It also has this particularily interesting bit:
<!-- Appended tlog to track custom build events -->
<WriteLinesToFile Encoding="Unicode"
File="$(TLogLocation)$(ProjectName).write.1u.tlog"
Lines="#(CustomBuildStep->'^%(Identity)');#(CustomBuildStep->MetaData('Outputs')->FullPath()->Distinct())"/>
So this writes the path of the Outputs to a .tlog file in the directory used by the tracker and makes it work as desired. Also see here for more information about the format.
tl;dr Use WriteLinesToFile to append full paths of your targets' outputs to a file like $(TLogLocation)$(ProjectName).write.1u.tlog. I'm saying like because write.tlog, write.u.tlog etc also work.
Visual Studio uses something called Visual Studio Common Project System (CPS) (https://github.com/Microsoft/VSProjectSystem) (VS 2017)
to manage projects, including build process.
Within CPS anything that implements IBuildUpToDateCheckProvider interface can be used
as a 'UpToDateChecker' for a project.
'UpToDateChecker' is invoked before invoking MsBuild. Its main purpose is to determine whether or not invoke MsBuild to build project, or to mark project as 'Up To Date' and skip msbuild all along.
This 'UpToDateChecker' is exactly what prints into diagnostic build output:
1>------ Up-To-Date check: Project: "ProjectName", Configuration:
Debug x86 ------ Project is not up-to-date: build input 'header.h' was
modified after build output 'a.out'. Input time: 12/27/2018 4:43:08
PM, Output time: 1/1/0001 2:00:00 AM
As for C++ Projects, for VS 2017 its default 'UpToDateChecker' is VCProjectBuildUpToDateCheck
( Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.dll ).
As starter, it looks into tlogs directory ( usually something like Debug\x86\.tlog) for these files:
.lastbuildstate
unsuccessfulbuild
all '.read..tlog' - input files, marked as 'build input' in diagnostic build output
all '.write..tlog' - output files, marked as 'build output' in diagnostic build output
There's actually more checks, but most fails occur when checking these 4 types
The original question here relates to C++ projects, but for anyone finding this while searching for information about modern (SDK-style) C#/VB/F# projects, you can customise Visual Studio's fast up-to-date check as described in this document:
https://github.com/dotnet/project-system/blob/master/docs/up-to-date-check.md
In a nutshell, you specify inputs and outputs as items:
UpToDateCheckInput — Describes an input file that MSBuild would not otherwise know about
UpToDateCheckBuilt — Describes an output file that MSBuild would not otherwise know about
It can be very helpful to increase the diagnostic logging level for the up-to-date check via this setting:
You can find out why a project is being rebuilt by enabling the verbosity of the fast up to date checker in the registry key:
New-ItemProperty `
-Name U2DCheckVerbosity `
-PropertyType DWORD -Value 1 `
-Path HKCU:\Software\Microsoft\VisualStudio\14.0\General -Force
You should be able to see in the build log messages like
Project 'Caliburn.Micro.Silverlight.Extensions' is not up to date. Project item 'C:\dev\projects\Caliburn.Micro.Silverlight.Extensions\NavigationBootstrapperSample.cs.pp' has 'Copy to Output Directory' attribute set to 'Copy always'.
[1] https://blogs.msdn.microsoft.com/kirillosenkov/2014/08/04/how-to-investigate-rebuilding-in-visual-studio-when-nothing-has-changed/
To enable logging for old-style projects (i.e. non-SDK-style projects, common in the .NET Framework era):
Open a "Developer Command Prompt" for the particular version of Visual Studio you are using.
Enter command:
vsregedit set "%cd%" HKCU General U2DCheckVerbosity dword 1
The message Set value for U2DCheckVerbosity should be displayed.
Run the same command with a 0 instead of a 1 to disable this logging.
More information at: https://github.com/dotnet/project-system/blob/main/docs/up-to-date-check.md#net-framework-projects

Conditionally add content file to visual studio C++ project

I have a visual C++ project for a DLL and a setup project for it. In the installer i've added the content files of my project.
Is there a way to add a file as a content file depending on if you are compiling debug or release? I want to include boost_date_time-vc100-mt-gd-1_51.dll if I compile under debug and boost_date_time-vc100-mt-1_51.dll if I compile under release.
My additional deps looks like this
Shell32.lib;libzmq.lib;log4cxx.lib;boost_date_time-vc100-mt-gd-1_51.lib;...
Under additional library directories i've added the path to all these .lib files which also contains their respective .dll files
I've tried the following with no success...
Added a Custom build step to run before build that copies the correct dll files to the OutDir and set the Output of this custom build step to be the dll files.
Conditionally include a content file by manually editing the vcxproj file. If configuration was release mode I would set the non-debug version as deployment content and the debug version to false and vice versa for Debug mode. This looked something like this,
<ItemGroup Condition="'$(Configuration)'=='Release'">
<None Include="boost_date_time-vc100-mt-1_51.dll ">
<DeploymentContent>true</DeploymentContent>....
</None></ItemGroup
Neither of these worked however. The second option seemed to always default to debug mode no matter how I built my project.
When you add a dependency, you can add it to one configuration or all configurations:
[This picture is of VS 2012, but 2010 and 2008 look pretty much the same.]
So, you pick the configuration you want to modify at the top-left, then add the library to the additional dependencies. Note that what you add here will be the .lib file associated with a DLL, not the dll itself (the compiler will make the executable depend on the DLL because you link with its .lib file).

Customize building VC++ in VS2010

I have a big C++ project and I need to do many steps in the building phase because I am building an application that is compatible with both 64 and 32, I have three projects:
proj1,Porj2,Proj3
and I need to do the following:
Exclude a cpp File from proj1 (32bit version)
Include a cpp file to proj1 (64bit version)
build proj1
build proj2
Execute output of proj2
Exclude a cpp File from proj3 (32bit version)
Include a cpp file to proj3 (64bit version)
Build proj3
Rename the exe that was built from proj3
Exclude a cpp File from proj1 (64bit version)
Include a cpp file to proj1 (32bit version)
still there are some other steps ... I was doing that manually and its frustrating, I found the I need to use MSBUILD but is it used for building native code ? and how can I perfrom these tasks ?
-Excluding and Including cpp files into projects
-Building proj
In Visual Studio 2010 and later, C++ projects use MSBuild.
Rather than excluding or including files based on the configuration, it would be simpler to use a preprocessor directive to conditionally compile the contents of the file. E.g., wrap the entire contents of the file in:
#ifdef MY_32BIT_BUILD_MACRO
// Source file contents here
#endif
And likewise with a macro for 64-bit builds. When using Visual C++, you can use the _M_IX86 and _M_X64 predefined macros to detect whether you are compiling for x86 or x64, respectively.
Alternatively, you could add a Condition property to the ClCompile item for the particular source file in the project file, and have it only included in the build when certain properties are set. I think that conditional compilation within the source file is a better option, though, unless you have complex rules that you need to use to determine whether to include a file or not.
In your solution, you can set project dependencies to ensure that one project is built before another. Right-click the solution, select Properties, and browse to Common Properties -> Project Dependencies. Dependencies can also be specified in a project file.
You can execute the output of a build by using a post-build task. Right-click the project, select Properties, and browse to Configuration Properties -> Build Events. The Post-Build event can be used to execute a command when the build has completed.
Rather than renaming an executable after build, it's easier to just have the build produce an executable with the right name. In the Project properties, under Configuration Properties -> General, the Target Name property can be used to set the name of the primary build output.

#include file found in debug build but not in release build

I have a C++ (Brew C++) project in MVSC++ 10 which compiles in debug build but not in release build, but I cannot fathom out why not.
The problem is that header files within a certain directory cannot be found, the directory structure is:
.mak
.sln
etc.
/inc/A/m.h
/inc/B/n.h
/inc/C/o.h
/inc/util/html/a.h
/inc/util/html/b.h
/src/A/
/src/B/
/src/C/
/src/util/html/
i.e. the main project files are at the root directory and the header and source files distributed into sub folders.
a.h and b.h can be found in debug build but not found in release build.
Yet the .mak file contains:
....
INCDIRS := ....
$(ProjectDir)inc/A \
$(ProjectDir)inc/B \
$(ProjectDir)inc/util/html
So even though /inc/util/html is specified as an include directory in the .mak the project cannot find it - but only in release build.
There is no conditional behaviour between debug and relase builds that I can see - the header files are included within the source code irrespective of build configuration. And the above snippet is the only spot in the .mak file wehre the include directories are specified.
So why should there be a difference between the debug builds and release builds?
Any ideas?
Thanks

Resources