Setting Visual Studio specific options with Scons - visual-studio

Does Scons have anything like CMake source_groups, or some other way to control under what category files are shown in the solution outline of Visual Studio?
Also, how do you set variables like the vs_debugger_working_directory that are IDE specific? Is there a way to do this in Scons?

Sorry SCons doesn't currently have support for such.
I'd guess it wouldn't be that hard to add.
Pull Requests welcomed.
Or just file an issue on github. (put link to this SO question there as well as describing what/how it should work)

Related

Visual Studio Not Finding 'vulkan-1.lib'

I read this tutorial to try to set up Vulkan in Visual Studio. I got to the very end, compiled, and got this:
A few more screenshots:
I'm using version 1.1.114.0 while the tutorial is using 1.1.77.0, which may be at the root of the issue. However, I have not been able to find another tutorial showing how to set Vulkan up like this. How do I get Vulkan to work in Visual Studio?
I believe you must have missed a step in the tutorial. Specifically, look for the text
Next, open the editor for library directories under Linker -> General
in the linked tutorial page.
In the linker Input tab, either use a complete path to the Vulkan library (for example C:\VulkanSDK\1.1.101.0\Lib\vulkan-1.lib) or in the General tab, add the location of the library (for example C:\VulkanSDK\1.1.101.0\Lib to the Additional Library Directories entry).
If you can express the values in terms of an environment variable, then you'd want to use either VULKAN_SDK or VK_SDK_PATH, which in the above examples would resolve to C:\VulkanSDK\1.1.101.0. That way when you update your Vulkan SDK you don't need to update your project files, and they'll work on other machines that might have different versions installed.
In the long run I'd recommend switching to CMake for project generation, rather than maintaining Visual Studio project files directly. With CMake, adding a Vulkan dependency to your application is as easy as doing this:
find_package(Vulkan REQUIRED)
target_link_libraries(MyApp Vulkan::Vulkan)
You can find existing CMake-based Vulkan examples here or here.

Visualstudio makefile (NMAKE)

I am in need to create a makefile for visual studio. however the documentation for this on Microsoft websites is very gently speaking: lousy. Googling doesn't help either. Could somebody paste a link or simple tutorial on how to create such makefile (for example compiling one program from two cpp files). Also mentioning if include files like in GNU are possible to use (and how to import them in makefile). Or how can i echo something in makefile.
I have seen this but is of not much help.
Try using CMake. It's a cross platform build system. I have used it to generate project and solution files for VS 2010, however there is NMake generator also.
This video should get you started - http://www.youtube.com/watch?v=w9sKd8f0kFo.

Compiling libexif as static lib with Visual Studio 2010 - then linking from Visual C++ project

Is it possible to compile libexif with Visual Studio 2010? I have been trying to do so and have been running into a whole slew of problems. I cannot find any information about whether anybody has successfully done this before. I know I can use MinGW to compile the library, but I am in a situation where I need it to be compiled with Visual Studio and then need to link to it from a Visual C++ app. Is this possible?
To answer your question: Yes it is possible... but it is a bit of a hack. Libexif uses functions that MSVC has chosen not to implement. See my working example VS2010 project below (if you don't like downloading files then skip to my explanation of what needed changing to get it to work below):
https://www.dropbox.com/s/l6wowl8pouux01a/libexif-0.6.21_CompiledInVS2010%2BExample.7z?dl=0
To elaborate, the issues that needed a "hack" (as hinted in the LibExif readme-win32.txt documentation) are:
Libexif uses inline in several places which is not defined in VS for C, only C++ (see this)
Libexif uses snprintf extensively in the code which is not defined in VS (see here)
You need to create the config.h yourself without a ./configure command to help you. You could read through the script but most of it doesn't make sense for Windows VS2010.
You will need to define GETTEXT_PACKAGE because it's probably setup in the configure file. I just choose UTF-8, whether that is correct or not I'm not sure.
There was a random unsigned static * that needed to be moved from a .c file to the .h file as C in VS doesn't allow you to create new variables inside functions in the particular way they were trying to do.
Read the "readme-win32.txt" file. Advice is:
hack yourself a build system somehow. This seems to be the Windows way of doing things.
Don't get your hopes up. The *nix way of doing things is the configuration script that needs to be run first. It auto-generates source files to marry the library to the specific flavor of *nix. The configuration script is almost half a megabyte. Three times as much code as in the actual .c files :) You cannot reasonably get that working without MinGW so you can execute the script. Once you got that done, you've got a better shot at it with a VS solution. As long as it doesn't use too much C99 specific syntax.

CMake: Making a Visual Studio project for Windows Mobile

so far, my night has been extremely frustrating, trying to learn CMake. However, I'm slowly getting there. There are a couple of things bugging me though:
1) Additional Library Directories
I can either have this:
CMake: link_directories ("../../YoghurtGum/bin")
Output: AdditionalLibraryDirectories="..\..\YoghurtGum\bin\$(OutDir),..\..\YoghurtGum\bin"
Or this:
CMake: link_directories ("${PROJECT_SOURCE_DIR}../../YoghurtGum/bin")
Output: AdditionalLibraryDirectories="F:\Projects\YG3\Tests\Galaxians..\..\YoghurtGum\bin\$(OutDir),F:\Projects\YG3\Tests\Galaxians..\..\YoghurtGum\bin"
Or this:
CMake: link_directories ("${PROJECT_SOURCE_DIR}/../../YoghurtGum/bin")
Output: AdditionalLibraryDirectories="..\..\YoghurtGum\bin\$(OutDir),..\..\YoghurtGum\bin"
While what I really want is this:
Output: "..\..\YoghurtGum\bin"
2) Setting the platform name
I haven't been able to set it, but I want it to be Windows Mobile 5.0 Pocket PC SDK (ARMV4I) instead of Win32.
3) Setting the intermediate directory
I want to have this:
IntermediateDirectory="intermediate"
instead of this:
IntermediateDirectory="Galaxians.dir\Release"
but nothing seems to work.
4) Output file
It should be:
OutputFile="$(OutDir)\$(ProjectName)_debug.exe"
instead of:
OutputFile="F:\Projects\YG3\Tests\Galaxians\bin\Debug\Galaxians.exe"
Any help on any of these issues would be much appreciated.
To quote a famous (infamous?) line:
"You can't always get what you want."
1) Additional Library Directories
2) Setting the platform name
3) Setting the intermediate directory
These are just the way you've observed them. They are as they are, and you cannot change them with an "as-is" build/install of CMake.
Of course, having said that, CMake is an open source project. You could dive in and submit a patch that changes CMake to support these features. :-)
There are a few outstanding bugs (cough, feature requests) for CMake that, if fixed/implemented, would add support for other platform types. It will take quite a lot of effort to do it properly, though, and so far nobody has had the time/energy/funding to finish it off. See related CMake bug reports here:
http://public.kitware.com/Bug/view.php?id=7919
http://public.kitware.com/Bug/view.php?id=8102
http://public.kitware.com/Bug/view.php?id=8486
4) Output File
This one you can change. Set the OUTPUT_NAME or OUTPUT_NAME_DEBUG target property.
http://cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:OUTPUT_NAME
http://cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:OUTPUT_NAME_CONFIG

How do I see the contents of Qt objects during debugging?

Many Qt classes uses pimpl, so they're very opaque to VS's debugger.
This is bothersome when I want to check some internal Qt state to see if my code is doing it wrong or if I'm having wrong expectations of how things stand.
I'm using the Qt VS add-in (1.1.0), but that doesn't seem to help.
Any ideas?
Update
My autoexp.dat file is filled with Qt stuff, but I'm still not able to look inside the heavier classes (QWidget, QTcpSocket, etc).
I can see the simpler classes contents, so the autoexp.dat below seems to be working, but trying to look inside a QWidget doesn't work.
Update 2
For some reason, after reading comments and looking more, it does work, and I can see the data stuff.
I don't know what happened in the mean time (when I just worked and ignored it), but I did have problems seeing the data before.
I'm accepting the "just works" answer, because I can't delete a bountied question and that's the closest answer available. (The autoexp-dat just pretty-formats the debug lines, using data that's already visible if one digs down)
This might help http://daniel-albuschat.blogspot.com/2008/02/qt-debugging-with-visual-studio-2005.html
IIRC the install of Qt for Windows includes an autoexp.dat file -
Correction, it's part of the the qt-vs-addin
You need to add custom dumpers for your debugger.
There are pre-built ones for GDB. You may have to roll your own for other debuggers, although for visual studio it's possible to get some decent results pretty easily by tweaking the autoexp.dat file. There are plenty of resources online for how to change this file.
Editing autoexp.dat is an option. See http://eecs.vanderbilt.edu/research/hmtl/wiki/pmwiki.php?n=Knowledge.Qt for a set of visualizers.
It seems like you might be out of luck.
Currently this page has the most complete list of macros for QT wariables that can be added to the autoexp.dat:
QT with Visual Studio 2008 (updated for Qt 4.5.2)
ActiveQt also sounds promising, but it might be a bit of an overkill for you.
Beyond this, you would have to roll your own expressions, or maybe write a Visual Studio Debugger Visualizer. (more about that is on CodeProject or MSDN)
Since there is nothing like that out there, it might be a good opportunity for development from scratch. :)
It's definitely possible to look into the pimpl when Qt is compiled with debugging information. Not sure about VS, but with gdb it Just Works™.

Resources