VS 2019 keeps finding qrc cpp files as modified even when they are not - c++

I work in a project using Qt compiled with Visual Studio C++ compiler.
I noticed after migrating from VS2017 to VS2019 that when building the application, VS always find qrc cpp files as modified and try to rebuild them.
Is not happening for all projects though, only some unit tests.
Does someone notice this behavior?

I've had the same issues when upgrading from vc141 (2017) to vc142 (2019). It's old but the only post I found, so:
The difference in the toolkits is that in vc142 "Custom Build Tools" are now appended to include inherited values. If your project is configured to use a build tool projectwide by default (for example meta objects from QTs signal/slot), the compiler will try to do that as well when trying to rcc the qrc files, and ultimately failing without throwing an error.
Simply removing ;%(Outputs) in Properties->Custom Build Tool->General->Outputs solved it for me.

Related

Using fuzzylite in Visual Studio 2010

Has anyone done this before ? I am not able to get it to work.
Following are my steps:
Download the windows package from link
I can run qfuzzylite (gui-tool) without any problem. Now I want to use the fuzzylite lib in my Visual Studio + Qt Integration Project.
In the CMake GUI I give fuzzylite source folder as the input folder and select Visual Studio 2010 as the compiler.
I am able to generate the Visual Studio fuzzylite solution in CMake without any errors.
Then, I tried to build the Visual Studio solution, but it fails with some weird errors. However, it does generate the fuzzylite-dbg.lib file (which I need).
Then I use this lib file and the fuzzylite.dll and include the path to the Headers in the VS Project. The project builds without any errors.
Now in the code I am doing
fl::Engine* engine = new fl::Engine("simple-dimmer");
This fails with the following exception:
exception text: bad allocation
exception type: class std::bad_alloc
Thank you for your detailed steps, but the solution seems to be a bit random (or weird as you put it). Unless more information is provided about the error, I strongly discourage the use of such a solution to attempt any fix to fuzzylite.
If you are running into problems, I strongly encourage you to report the problem in the forums at http://www.fuzzylite.com, where I and others will be very happy to help you.
As for the compiling errors, fuzzylite treats warnings as errors. A warning that is being raised in fuzzylite 4.0 when compiled using Visual Studio (not from console via nmake), and potentially in previous versions, is warning C4702, which refers to unreachable code. You can fix this by adding in file fl/fuzzylite.h the following line within the #ifdef FL_WINDOWS (together other #pragmas):
#pragma warning(disable:4702) //Ignore unreachable code
If the library was not built correctly, errors are bound to happen during runtime.
Ok, got it :)
Here are the steps for future reference:
Download the windows package from link
In the CMake GUI I give fuzzylite source folder as the input folder and select Visual Studio 2010 as the compiler. Now, if you want to use the lib in Debug mode tick the FL_DEBUG box (this is where I went wrong)
Now on clicking "generate", it will generate 5 projects:
ALL_BUILD
fl-bin
fl-shared
fl-static
INSTALL
ZERO_CHECK
Now in the Project properties in fl-bin, shared and static go to the Project Properties. In C/C++ go to Preprocessor get rid of the space in FL_DATA="mm.dd.yyyy " to "mm.dd.yyyy" (weird).
The solution should build fine and will generate fuzzylite-dbg.dll and fuzzylite-dbg.lib in the lib folder.
Use these files in your VC Project by adding the fuzzy-dbg.lib as the linker input and place the dll in the solution folder. Give the path "path\to\fuzzylite\fuzzylite." to the Include Directories.
Do the same process for Release mode (don't tick the FL_DEBUG flag)

Can I compile a Visual C++ project on Linux using xbuild?

I have an existing project that I compile on both Windows using Visual C++ 2008, and Debian Linux. This project uses a standard Visual C++ .vcproj file, and some .cpp and .h files. It does not rely on any Windows specific stuff. Just plain C++.
It compiles and run well on Linux, using a home made tool that reads the .vcproj file to generate a Makefile which is used with make to compile and link all files using g++.
The trouble is that with Visual C++ 2010 (and 2012), the format of the project files have changed. Even the name has been changed from .vcproj to .vcxproj. My home made tool cannot read this new project file to generate the Makefile.
Instead of upgrading the home made tool to support new project files, I was wondering if xbuild would be able to compile my Linux executable?
I tried first to compile my own (VC++2008) project, but xbuild complains that my project is a VS2003 project, which is not supported by xbuild. However when googling on this matter, I find that xbuild is supposed to support VS2005 project files. There are also some references to mdtool to support these old project files, but I seems to be integrated into xbuild now.
Furthermore, I tried to compile a Visual C++ 2010 example (HuoChess) got from the MSDN site. The result is
/Microsoft.Cpp.Default.props: Project file could not be imported, it was being
imported by [...] /HuoChessConsole/HuoChessConsole.vcxproj: Imported project:
"//Microsoft.Cpp.Default.props" does not exist.`
Now, this looks like the project file wants some Microsoft definitions of rules for the Cpp compiler. Should I fake these definitions to use gcc instead? How can I do this?
Is what I want to do ever possible with xbuild?
There is a project GCCBuild which you can use to build vcxproj projects in Linux. It simply uses same vcxproj but uses GCC to compile and build. There are multiple examples there too.
PS. I am the author of that project.

Using Qt with Visual Studio without add-in

I recently started using Qt library and I've got a question.
Is this possible to use Qt with Visual Studio without special add-in?
I want to just design the UI using qt designer and do the rest in VS Express.
How do I do that?
Thanks.
Yes you can, if you would prefer not to use the QtVSAddin it is very easy to use Qt with VS Express without the VS add-in and without having to do any of the uic or moc steps manually. Let QMake (installed with Qt but not part of the QtVSAddin) create your VS project file and do all your project setup in a qmake project file. Whenever you make a change like adding/removing a form or source, modify the qmake project file and regenerate the VS project. Don't modify the VS project file at all, treat it only as a temporary item. QMake will add the rules automatically to the VS project file to rerun uic and moc, you don't need to do anything if you're just modifying source code or forms.
For configuration management purposes I find this a much cleaner approach to use this workflow as you treat the VS project file as only a temporary item (they tend to diff badly and are a pain to maintain in version control).
A couple snippets to help you out:
In your qmake project file ensure you add the following line into it so that VS project files are generated when running on Windows (qmake defaults to generating a makefile).
your_qmake_proj.pro
win32: TEMPLATE = vcapp
Additionally, it's convenient to have a batch file to rerun qmake so you don't have to bring up a command prompt and set environment up (or change directory to your project in a command prompt that already has the environment setup). If you haven't set the various Qt environment variables with Windows (or prefer not to) make sure to add them to your batch file.
makevcproj.bat
set QTDIR=C:\Qt\x.y.z
set PATH=%PATH%;%QTDIR%\bin
set QMAKESPEC=win32-msvcXXXX
qmake your_qmake_proj.pro
pause
CMake is also an answer and it does work with express versions of Visual Studio. I mean if you use the Qt support in CMake you can develop Qt projects in Visual Studio (like I have done for years) without the Qt Addon. I install the addon just for the debug expansion that comes in the same package.
It is certainly possible, but without the add-in you will need to UI and MOC the needed files either before you compile the rest within VS, or through pre-compile scripting.
Specifically:
uic generates the headers from .ui files.
and
moc generates the additional implementation files for classes that has Qt macros in it.
The add-in helps you call these smoothly on the required files before compiling the rest.
It's is possible if you create the UI in QtCreator and manually setup VS in a way that generate the UI and MOC files.
But it's too much work and you can use QtCreator which is an amazing light IDE.

Using a DLL with unmanaged code in Visual Studio 2010?

I'm fairly new to C++ and an trying to figure out to use the TagLib library for a project I am working on. I'm working with unmanaged C++ in Visual Studio 2010 on Windows 7 64bit. I've never used an external library before so I'm very confused on how to go about this.
From this blog entry I got the libtaglib.a and taglib.dll files. I ran across this SO question on how to use TagLib, but it deals with QT Creator, not Visual Studio and I'm not knowledgeable enough about the subject to understand what is being said to translate it into what needs done for Visual Studio.
So, some questions:
Is it even possible to do this with unmanaged code?
What exactly is the function of a .a file?
Most importantly, how do I go about using the taglib.dll in my program??
I've been all over Google looking for a way to do this, but my major problem is that everything I run across is over my head. Please let me know if more info is required. Any help is very much appreciated! Thanks!
I seem to have gotten it working successfully. Here's a rough outline of what I did:
1.) I used CMake to generate the Visual Studio solution.
2.) I attempted to build the tag project in the VS solution, but it failed.
3.) I made the corrections to a few source files as outlined here: http://old.nabble.com/taglib-fails-to-compile-with-MS-VC%2B%2B-2010-td29185593.html
4.) I built the tag project again in release mode. This time it was successful.
5.) I copied the resulting dll, def, and lib files to the same directory as the source files for my project.
6.) I copied the header files from the taglib source to a subdirectory in my project (not sure if this entirely good practice)
7.) In my project settings, I set the subdirectory with the header files as an additional include directory.
8.) I added the dll, exp, and lib files to my project by just going to Add>Existing Item.
9.) I added some code from the taglib examples and built it. Everything worked so I think I got it.
One caveat I ran into, since the DLL was built in release mode, my project had to be run in release mode or it would crash. I'm guessing that if I replaced the DLL with one built in debug mode I could run my program in debug mode, but I have not tried this.
You cannot use libraries specific to GCC (you can tell because they have .a extensions) with Visual Studio. You will have to build the library from source in order to use it with MSVC. Once you have done that it's a simple matter of adding the .lib generated from the build process to your project and things should work out of the box. (Note that it's a .lib you need whether you're compiling for dynamic linking or not -- doesn't matter in msvc land)
EDIT -- after looking at TagLib itself --
In order to compile TagLib you'll need to get the CMake build system, and TagLib itself, and have CMake build you a visual studio solution. Using that solution you'll be able to build the .libs and .dlls you need. Note that because TagLib is a KDE library, you'll probably need to also build some QT bits in order for everything work work successfully. However, I don't have specific experience with the library so I'm not going to be all that helpful here.
Yo do not have to recompile the source (to create the .lib file) if you have the .dll file. With dumpbin /exports and lib (both came with Visual Studio) yo can create a lib that you can link with your application. In this link you can see a nice explanation: http://www.coderetard.com/2009/01/21/generate-a-lib-from-a-dll-with-visual-studio/
But as Billy Said, probably you would need other parts of QT to use this library.

Cross-platform svn management (Makefiles & Visual Studio)

I'm working on a little game called freegemas, it's an open source version of the classic Bejeweled written in C++ and using gosu as the graphic API. I've been developing it under Ubuntu Linux as usual, but the other day I wanted to give it a try and I compiled it on Windows using Visual Studio 2005 (which I had never used before). The program worked flawlessly.
To compile it on Windows I manually copied all the source and header files to a new project on MSVC, but I would like to adapt the SVN so I don't have to recreate the project every time I want to compile it.
Therefore, the question would be: What's the best way of organizing the svn so I can have, on the one hand, a Makefile to compile the project in Linux, and, on the other side, the MSVC project's files? Right now I've got a simple folder called trunk with all header, source and resource files on it.
I've never used Visual Studio before, so I don't know which files are the most important either. Maybe some of those files are auto-generated and do not need to be svn-versioned.
Thanks in advance.
You could just keep the project files in a seperate directory "winbuild" or similar. Still, to maintain them would require manual interaction (ie adding every new file manually). The only files you would need to upload to svn are the *.vcproj (for MSVC 2005/2008) and *.vcxproj (MSVC 2010).
Alternatively, you could opt for a cross-platform solution like CMake, which could generate makefiles and Visual Studio project files from a common CMakeLists.txt, which is the only "project file" that would have to be maintained (instead of your makefile). Especially for a simple (?) project like yours (some headers+sources). There would be no need to include any makefiles or vcproj files at all, just the CMakelists.txt file would suffice.
There are others like CMake (SCons, boost.jam, jam, premake, etc.)
It should be feasable, but requires some testing and trial-and-error.