I am using the odb compiler as a custom build tool. The build tool is always executing even though the input file is not changing.
The command line:
odb -Ic:\menuplan\src\ingredient -o c:\menuplan\src\ingredient
-d mysql --hxx-prologue "#include \"odb/traits.hxx\"" --generate-query
--generate-schema --schema-format separate
c:\menuplan\src\ingredient\ing_odb_category.hpp`
The input file is:
ing_odb_category.hpp.
The outputs:
ing_odb_category-odb.hxx;ing_odb_category-odb.ixx;ing_odb_category-odb.cxx;ing_odb_category-schema.cxx
The additional dependencies:
ing_odb_category.hpp
The description:
odb ing_odb_category.hpp
The output from Visual Studio 2010:
2>------ Build started: Project: vs_2010, Configuration: Debug Win32 ------
2> odb ing_odb_category.hpp
The odb tool takes the ing_odb_category.hpp as input and produces ing_odb_category-odb.hxx, ing_odb_category-odb.ixx,ing_odb_category-odb.cxx,ing_odb_category-schema.cxx files.
I can build the solution many times in a row and the custom build event will always run, even though the ing_odb_category.hpp file never changes.
How can I make Visual Studio only perform the custom build if the header file changes?
From the vcxproj file:
<CustomBuild Include="..\ing_odb_category.hpp">
<Command Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">odb -Ic:\menuplan\src\ingredient -o c:\menuplan\src\ingredient -d mysql --hxx-prologue "#include \"odb/traits.hxx\"" --generate-query --generate-schema --schema-format separate c:\menuplan\src\ingredient\ing_odb_category.hpp</Command>
<Command Condition="'$(Configuration)|$(Platform)'=='Debug_Static_Unicode|Win32'">odb -Ic:\menuplan\src\ingredient -o c:\menuplan\src\ingredient -d mysql --hxx-prologue "#include \"odb/traits.hxx\"" --generate-query --generate-schema --schema-format separate c:\menuplan\src\ingredient\ing_odb_category.hpp</Command>
<Message Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">odb ing_odb_category.hpp</Message>
<Message Condition="'$(Configuration)|$(Platform)'=='Debug_Static_Unicode|Win32'">odb ing_odb_category.hpp</Message>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">ing_odb_category-odb.hxx;ing_odb_category-odb.ixx;ing_odb_category-odb.cxx;ing_odb_category-schema.cxx</Outputs>
<Outputs Condition="'$(Configuration)|$(Platform)'=='Debug_Static_Unicode|Win32'">ing_odb_category-odb.hxx;ing_odb_category-odb.ixx;ing_odb_category-odb.cxx;ing_odb_category-schema.cxx</Outputs>
<AdditionalInputs Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">ing_odb_category.hpp</AdditionalInputs>
</CustomBuild>
Environment:
Visual Studio 2010
Windows 7 - 64bit
Visual Studio was always building the files because it said they didn't exist.
Using the Visual Studio project logging article, especially running the DebugView showed that Visual Studio was using a different path for the dependencies. I did not specify the path of the output files and dependencies, so it was trying to locate them in the default project directory.
Also, Visual Studio expects only one output file, according to Specifying Custom Build Tools article. I was supplying all the output filenames.
Summary
In the Custom Build Tool window:
There should only be one output file.
Additional output files are listed in the Additional Dependencies
slot.
All output files should be prefixed with the path of their location,
relative or absolute.
Useful build process debugging aids can be found in the Visual Studio Project Logging article, especially the DebugView application.
Related
I have a project in my solution which gets built (consequently all the dependent projects as well) on every run due to the following file missing. I changed the build output verbosity to Diagnostics and got the following line at the top of the build of the said project:
Build started...
1>------ Up-To-Date check: Project: project_name.vcxproj, Configuration: Release x64 ------
1>Project is not up-to-date: build output 'c:\path\appdata\local\temp\lnk{24e28c62-71a7-43ad-81e2-9b34157645b4}.tmp' is missing
1>------ Build started: Project: project_name, Configuration: Release x64 ------
This number (24e28c62-71a7-43ad-81e2-9b34157645b4) changes on every build.
The solutions that I have tried which didn't work:
Deleted the .suo file.
Deleted temp folder, caches and settings.
Reinstalled the VS 2022.
The rebuild happens when I click the build solution regardless of any changes or lack there of in the code.
Edit:
The linker /VERBOSE output on building the said project:
Build started...
1>------ Build started: Project: project_name, Configuration: Release x64 ------
1>Invoking cvtres.exe:
1> /machine:amd64
1> /verbose
1> /out:"C:\Users\path\AppData\Local\Temp\lnk{01385313-5798-4F09-8223-983424FE6954}.tmp"
1> /readonly
1> "C:\Dev\dev\ws2\build\Release_x64\i\project_name\name-of-dll.res"
1>Microsoft (R) Windows Resource To Object Converter Version 14.30.30711.1
1>Copyright (C) Microsoft Corporation. All rights reserved.
1>
1>adding resource. type:VERSION, name:1, language:0x0407, flags:0x30, size:576
You seem to be building a DLL. So this doesn't apply to you.
But for others that get this when building a static library, hang on...
Here's a possible cause for rebuilds:
Your static library project might contain a resource (*.RC) file.
It's quite odd for a static library to contain a RC file because it could clash with other projects in your solution that consume the static library.
Deleting the .rc and resource.h files can solve the issue (at least it did for me).
The other (top) reason is that your project file points to header files that you have deleted. Since the compiler is not invoked for header files, you won't see errors when building so this is easy to miss!
My specific case was the one described by E. van Putten's answer, where Lib screws up when given a .res file as input. More precisely, it ends up writing the path of a temporary file into the .tlog file that is used for its subsequent up-to-date checks (at which point said file is long gone).
Until this is fixed, I've written a crude MSBuild target that is sequenced right after Lib and filters out nonexistent paths from the generated .tlog file.
<!--
This removes the broken temporary file paths that Lib.exe
puts in tlog files when it processes a .rc file.
See https://stackoverflow.com/q/74536502/3233393.
-->
<Target
Name="BugfixTempFilesInLibTlogs"
AfterTargets="Lib"
Condition="Exists('$(TLogLocation)Lib-link-cvtres.write.1.tlog')"
>
<ReadLinesFromFile
File="$(TLogLocation)Lib-link-cvtres.write.1.tlog"
>
<Output TaskParameter="Lines" ItemName="_LibWriteTlogLines" />
</ReadLinesFromFile>
<!--
Insane item juggling because MSBuild blows up as soon as one mentions `%(FullPath)`
for something that is not actually a path, such as the first line
from the .tlog file (which is of the form `^<file>|</file>|...`)
-->
<ItemGroup>
<_LibWriteTlogLinesToRemove Include="#(_LibWriteTlogLines)" />
<_LibWriteTlogLinesToRemove
Remove="#(_LibWriteTlogLinesToRemove)"
Condition="$([System.String]::new('%(Identity)').StartsWith('^'))"
/>
<_LibWriteTlogLinesToRemove Remove="#(_LibWriteTlogLinesToRemove->Exists())" />
<_LibWriteTlogLines Remove="#(_LibWriteTlogLinesToRemove)" />
</ItemGroup>
<WriteLinesToFile
Condition="'#(_LibWriteTlogLinesToRemove)' != ''"
File="$(TLogLocation)Lib-link-cvtres.write.1.tlog"
Lines="#(_LibWriteTlogLines)"
Overwrite="true"
/>
<ItemGroup>
<_LibWriteTlogLines Remove="#(_LibWriteTlogLines)" />
<_LibWriteTlogLinesToRemove Remove="#(_LibWriteTlogLinesToRemove)" />
</ItemGroup>
</Target>
The .tlog file's name seems to change depending on the input to Lib, so make sure that it matches your case.
I'm trying to write Parquet files on Windows using C++.
I followed the instructions I found here and chose the "Using conda-forge for build dependencies" and "Building using Visual Studio (MSVC) Solution Files" approaches.
In contrast to the article on the page mentioned before, my calls to cmake look like this:
cmake .. -G "Visual Studio 16 2019" -A x64 ^
-DARROW_BUILD_TESTS=OFF ^
-DARROW_PARQUET=ON ^
-DARROW_BUILD_SHARED=OFF ^
-DARROW_BUILD_STATIC=ON ^
-DARROW_DEPENDENCY_SOURCE=AUTO
cmake --build . --config Release
I want to use Parquet/Arrow as a static library, so I set -DARROW_BUILD_SHARED=OFF and -DARROW_BUILD_STATIC=ON.
In the "build" folder created after running cmake, I built the Parquet and Arrow INSTALL projects (build\src\parquet\INSTALL.vxcproj, build\src\arrow\INSTALL.vxcproj) with Visual Studio 2019. As a result, a folder structure was created under C:\Program Files\arrow\lib including arrow_static.lib and parquet_static.lib.
Under C:\Program Files\arrow\include\arrow respectively \parquet all related header files can be found.
I then set up a new C++ project (Release Build | x64) in Visual Studio referencing the previously build static libs and including directories.
In the project settings under "C/C++->Preprocessor->Preprocessor Definitions" I added PARQUET_STATIC and ARROW_STATIC.
For a first test, I use the "reader_writer" example from the apache arrow GitHub repo:
Now, if I build the reader_writer example, I receive multiple linking errors (LNK2001) like the following example:
Error LNK2001 unresolved external symbol "public: virtual char const * __cdecl apache::thrift::transport::TTransportException::what(void)const " (?what#TTransportException#transport#thrift#apache##UEBAPEBDXZ) ReaderWriterDemo D:\..\ReaderWriterDemo\parquet_static.lib(column_writer.obj)
All errors have in common that they refer to as "thrift" at some point.
I was under the impression that when using "conda-forge for build dependencies" (see first link above), that all required dependencies would be available/somehow integrated into the solutions built by CMake?!
When running "cmake .. -G "Visual Studio 16 2019" -A x64" I can see the following in the log output though:
-- Checking for module 'thrift'
-- Found thrift, version 0.15.0
-- Found Thrift: D:/Programs/Miniconda3/envs/arrow-dev/Library/lib/thriftmd.lib (found suitable version "0.15.0", minimum required is "0.11.0")
My attempts to build the thrift library separately by using the resources found here weren't successful; information regarding Windows seems to be incomplete/outdated.
I assume that it should be possible to set up the Arrow/Parquet libs only by using resources from https://github.com/apache/arrow/.
Perhaps some of you have already gone through the same process and can give me a hint as to where else I may have missed something.
I have a Visual Studio Project and want to write some Unit Test for it.
I tried doing that by using a "Native Unit Test Project".
The Problem is, that when I use a QString in the Test, the Test fails with following message:
Message: Failed to set up the execution context to run the test
Any suggestions how I can write Unit Test using Qt?
#include "stdafx.h"
#include "CppUnitTest.h"
#include <QtCore/QCoreApplication>
using namespace Microsoft::VisualStudio::CppUnitTestFramework;
namespace Test
{
TEST_CLASS(UnitTest1)
{
public:
TEST_METHOD(TestMethod1)
{
QString a = "Test";
Assert::IsTrue(true);
}
};
}
I have tried with the above example of yours and i am able to compile the unit test. These are the following changes I've done apart from copying your code.
Check if your QT is built with 32 bit or 64 bit compiler.
You need to set the same in Solution Platforms.
You need to add include directory path and the lib file path(Qt5Cored.lib(for
debug)/Qt5Core.lib(for release)) in the Project properties.
To run the unit test you need to copy the
Qt5Cored.dll/Qt5Core.dll file in the folder where your unit test dll file is generated(After compilation).
PS:- I am using VS 2015 but this doesn't matter.
I have also ran into this issue with Qt6 with a project created using the Qt Visual Studio Tools extension for Visual Studio 2019.
QString was one of the things popping up as an error during the build process, but there was various more errors. My solution was as follows:
Gone to the Microsoft Unit Testing Framework for C++ project's Properties (right-click on solution, bottom option of the menu "Properties")
As mentioned in #sonulohani's response, I had it running in x64 by default.
Under Configuration Properties > Linker > General Additional Library Directories I added the path to my QT installation location libs folder (for me this was C:\Qt\6.1.2\msvc2019_64\lib) at the top of the list.
Under Configuration Properties > Linker > Input Additional Dependencies I added a link to all the "*.lib" files from that very same QT installation (for me, this was C:\Qt\6.1.2\msvc2019_64\lib\*.lib) AND a link to the build output .obj files for the Qt project ($(SolutionDir)<MY PROJECT NAME>\$(IntDir)*.obj where <MY PROJECT NAME> was my project name). This second part may not necessarily be needed.
Copying just the Qt6Core.dll/Qt6Cored.dll as suggested by #sonulohani did not work. It was still missing stuff. So in the properties, under Configuration Properties > Build Events > Post-Build Event Command Line I added this script to copy all the Qt6 dll files to the test project .dll output directory:
for %%f in (C:\Qt\6.1.2\msvc2019_64\bin\Qt6*.dll) do #copy /y %%f $(SolutionDir)$(Platform)\$(Configuration)\Tests\
Now at that point I had another issue, since both my test project and my actual Qt project was dumping its files into the same output directory, and the Qt project did not like having all those dlls in there and did not run anymore. So I created the $(SolutionDir)$(Platform)\$(Configuration)\Tests\ directory within the regular output directory, and also made this \Tests\ subdirectory the output directory for the test project (Configuration Properties > General Output Directory).
I just have followed the tutorials from: https://www.youtube.com/watch?v=57dbxWj7b4U
to install c++, but I can't build the project even I take the example project in eclipse: "Hello World c++ Project".The building seems successful, for exe file is generated, and concole shows
13:38:04 **** Incremental Build of configuration Release for project FirstC ****
Info: Internal Builder is used for build
g++ -O3 -Wall -c -fmessage-length=0 -o FirstProgram.o "..\\FirstProgram.cpp"
g++ -o FirstC.exe FirstProgram.o
13:38:05 Build Finished (took 1s.90ms)
But when I press "run", it says "Info: Nothing to build for TestProject", as the enclosed picture.
The system path is as following:
"c:\program files\gcc\bin;c:\program files\gcc\libexec\gcc\x86_64-pc-mingw32\5.3.0;%MINGW_HOME%\bin;%MSYS_HOME%bin;C:\Program Files (x86)\Java\jre1.8.0_25\bin;C:\ProgramData\Oracle\Java\javapath;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files\Common Files\Autodesk Shared\;C:\Program Files (x86)\Autodesk\Backburner\;C:\Program Files\GDAL\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\nodejs\".
What will the reason probably be? I have install java several days before, and just install c++ today. Will they conflict?
"Nothing to build for TestProject" means that the project was already built before and nothing changed since then, so the project does not need to rebuild.
If you change anything in the source code, save and try again, the project should then rebuild again (once).
I have restarted the computer and now it runs well, and "hello world" comes out. I'm fooled by the system and feel so tired.....
I need to display a property browser under a MFC app.
I try to combine and compile the solution for the two
http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Windows/qtwinmigrate/
http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Widgets/qtpropertybrowser/
I am using VC2009, QT 2009.04 with Visual Studio Add-On 1.1.1
Take note, under my machine, there are no problem for me to compile them successfully separately.
I copy, and add all exsiting CPP and HEADER files found in
qtpropertybrowser-2.5-opensource\src
into
qtwinmigrate-2.8-opensource\examples\qtdll
Here is how my new project looks like in the screen shoot (qtwinmigrate - windows at right most)
(source: googlepages.com)
The qtpropertybrowser, is the project which I am able to compile with no problem :
1>------ Rebuild All started: Project: simple, Configuration: Release Win32 ------
1>Deleting intermediate and output files for project 'simple', configuration 'Release|Win32'
1>Moc'ing qtpropertybrowserutils_p.h...
1>RCC ..\..\src\qtpropertybrowser.qrc
1>MOC ..\..\src\qtvariantproperty.h
1>MOC ..\..\src\qttreepropertybrowser.h
1>MOC ..\..\src\qtpropertymanager.h
1>MOC ..\..\src\qtpropertybrowser.h
1>MOC ..\..\src\qtgroupboxpropertybrowser.h
1>MOC ..\..\src\qteditorfactory.h
1>MOC ..\..\src\qtbuttonpropertybrowser.h
1>Compiling...
.
.
.
1>Compiling...
1>moc_qtpropertybrowserutils_p.cpp
1>Linking...
1>Embedding manifest...
However, when come to build modified version of qtwinmigrate (original version of qtwinmigrate was able to compiled with no problem)
1>------ Rebuild All started: Project: qtdialog, Configuration: Release Win32 ------
1>Deleting intermediate and output files for project 'qtdialog', configuration 'Release|Win32'
1>Moc'ing qtpropertybrowserutils_p.h...
1>Moc'ing qteditorfactory.h...
1>Moc'ing qtvariantproperty.h...
1>Moc'ing qttreepropertybrowser.h...
1>Moc'ing qtpropertymanager.h...
1>Moc'ing qtpropertybrowser.h...
1>Moc'ing qtgroupboxpropertybrowser.h...
1>Moc'ing qtbuttonpropertybrowser.h...
1>Moc'ing qwinwidget.h...
1>Moc'ing qwinhost.h...
1>Compiling...
.
.
.
1>Compiling...
1>moc_qtpropertybrowserutils_p.cpp
1>moc_qteditorfactory.cpp
1>.\Release\moc_qteditorfactory.cpp(74) : error C2027: use of undefined type 'QtSpinBoxFactoryPrivate'
1> c:\documents and settings\yan-cheng.cheok\my documents\downloads\qtwinmigrate-2.8-opensource\qtwinmigrate-2.8-opensource\examples\qtdll\release\../../../lib/qtpropertybrowser-2.5-opensource/src/qteditorfactory.h(97) : see declaration of 'QtSpinBoxFactoryPrivate'
1>.\Release\moc_qteditorfactory.cpp(74) : error C2227: left of '->slotPropertyChanged' must point to class/struct/union/generic type
My questions is
Why qtpropertybrowser just perform "Moc'ing" in 1 file, but qtwinmigrate perform "Moc'ing" in so many files?
Why qtpropertybrowser just compile "moc_qtpropertybrowserutils_p.cpp", but qtwinmigrate try to compile so many "moc_....cpp"?
It looks like your two vcproj files don't have the same "moc" properties... It can leads to strange behaviors with the classes that uses the moc...
How did you generate the vcproj file in the second project ?
Did you build both vcproj from the PRO files or just by adding the existing cpp/h files directly in VS ?
If you build the first example from the example's PRO file then just copied the cpp files in another vcproj by adding them through VS, then something probably went wrong with moc properties...
In your vcproj files, try and look for "moc_" and look for differences between the two files... I think it will give you a further step in the process of finding the source of your problem...
I hope it helps a bit...
1) Under Visual Studio 2008, go to Qt -> Open Qt Project File (.pro), open
qtpropertybrowser.pro
2) Go to "simple" Properties, under Build Events -> Pre-Build Event, enter the
following commands :
moc ..\..\src\qttreepropertybrowser.cpp > ..\..\src\qttreepropertybrowser.moc
moc ..\..\src\qtpropertymanager.cpp > ..\..\src\qtpropertymanager.moc
moc ..\..\src\qteditorfactory.cpp > ..\..\src\qteditorfactory.moc
3) Under C/C++ -> Additional Include Directories, enter the following path :
..\..\lib\qtwinmigrate\src
4) Under General -> Configuration Type, change to Dynamic Library (.dll)
5) Under Linker -> General -> Output File, change to \qtdialog.dll
6) Exclude original main.cpp from simple project. Add in main.cpp from
..\..\lib\qtwinmigrate\examples\qtdll
7) Add in all 3 cpp files and 3 header files from
..\..\lib\qtwinmigrate\src
8) Build all. qtdialog.dll will be generated.
9) Open up \lib\qtwinmigrate\examples\mfc\step1. Build all.
10) Move qtdialog.dll same directory as step1 generated exe. Run the application.