I have a problem when moving to our company's build system over which I have limited control. They have installed DirectX SDK plus Windows 8.1 SDK... My applications is using 8.1 specific features that conflict with DirectX SDK (it's deprecated for a reason). So basically, they have the DirectX SDK hardwired into include lookup and thus headers will resolve to it instead of Windows SDK.
Is there a way to exclude specific folders from "#include" lookup no matter if they were specified? Or is there a way to remove the DirectX SDK from the built-in lookup by some MSBuild command line argument etc?
Hypothetical Solution:
IgnoreIncludeDirectories="C:/program files/directx SDK/include"
:)
Thanks!
Actually it was easy.
set DXSDK_DIR=
%run your build script%
I am not sure if that is a general solution, but it worked and was suggested by one of our build engineers :). Maybe it will help someone else too.
Related
I post the following question at LunarG, as Issue #565, about Vulkan SDK redistributable parts for ready to go applications developed with Vulkan. I'd like to share it with Stack Overflow developers.
Let's say I have Vulkan application demo and wish to send it to
potential clients, in order to evaluate it. If I'd develop it using
SDK, what is the correct way to deploy it :
a) include the compatible SDK installer in a multi-install process ?
b) include some SDK's dlls and companion files ? Which ones ?
It also raises another question: Can I re-distribute SDK files ?
Karl Schultz, from LunarG, replied with the following:
On Windows, many IHVs include the Vulkan loader DLL in their install
packages, placing it in system32/vulkan-1.dll. So, in many cases, your
app might just work fine as long as the user has installed drivers
with Vulkan support.
You might also consider shipping only the RunTimeInstaller, which is
found in the SDK. This would let the user install the run time
(loader) as part of your application install. The RTI includes version
checking so that it doesn't clobber a newer version installed by IHV
drivers, or vice-versa. In short, this is probably the best way to go.
It would be better to include the RTI as part of the "multi-install
process" rather than include the entire SDK.
If your application needs layers or some other specific item from the
SDK, then you'd have to include those explicitly somehow.
Please check the licensing-related files within the SDK concerning
redistribution.
I have a Win32 app developed in C++ Builder XE, which has worked great in the WinPE 2.x/3.0 environments for the past couple of years. I have made some significant changes over the past couple of months, but now that it's complete and I try to run it under WinPE I get the error message: The program can't start because SHFOLDER.DLL is missing from your computer.
Since I can't control the WinPE environment, and this dll isn't included in WinPE, my first thought is to try and statically link the necessary components. However, it appears the functionality offered by this dll is only available from the dll.
I haven't been able to find any useful information on this DLL, and unfortunately I don't know which functionality I added that now requires this DLL. I am hoping that someone has experience with this, and can help guide me toward statically linking the required components, or finding a workaround so that this app no longer requires the dll. Thanks!
shfolder.dll is used to get shell folder paths like the Desktop, My Documents, Windows directory, etc. It implements SHGetFolderPath() consistently along all versions of Windows due to differences of implementation between SHGetSpecialFolderPath(), SHGetFolderLocation(), SHGetKnownFolderPath(), etc.
MSDN explains it better:
This function is a superset of SHGetSpecialFolderPath, included with
earlier versions of the Shell. On systems that preceded those that
include Shell32.dll version 5.0 (Windows Millennium Edition (Windows
Me) and Windows 2000), SHGetFolderPath was obtained through
SHFolder.dll, distributed with Microsoft Internet Explorer 4.0 and
later versions. SHFolder.dll always calls the current platform's
version of this function. If that fails, it tries to simulate the
appropriate behavior. SHFolder.dll continues to be included for
backward compatibility, but the function is now implemented in
Shell32.dll.
The DLL itself is redistributable so you can include it for WinPE. You can also just use any one of the other functions, if they work for you and you don't need any of the special cases.
I'd rather not install the entire VS 2008 installation given that I'm not going to be using anything other than the compiler. Will VS 2010's multitargeting work correctly using only the Platform SDK instead of the full VS2008 install?
The custom setup options are not nearly fine-grained enough to allow you to leave the big chunks like the IDE out. It isn't just the SDK that's used, at least the VC subdirectory needs to be there. And bits of Common7, also the folder that contains the IDE. Rename the folders, delete them later if it works out.
You can directly call the .net 3.5 MSBuild from command line by digging it out of the frameworks folder within windows. I am not certain if you could repoint Visual Studio at a different copy though. More importantly, unless you have found a bug, the copy of MSBuild included in the .Net 4 framework should properly build a project targeting the 3.5 framework. So you might be jumping through some unnecessary hoops in the first place.
I'm trying to compile someone elses C++ program using VS2005 on Windows 2003 (SP2).
The compile fails because it can't find iads.h
Which SDK should I install to get this header ?
When I install the SDK is there a danger I might break something already in use ? As far as I can tell the W2003 has no SDK's installed but if it did would installing a different one cause problems ?
You need to the windows sdk. The SDK doesn't install like a regular application. Just because you "installed" it it doesn't change any settings in your compiler.
You will still have to add the directories to header files and libraries in the vs settings page.
You can have multiple version of the windows sdk, you just need to update the directories in the vs options page.
It should be found in the vc\PlatformSDK\include folder. If not then you need to check your installation or you can install the Windows SDK.
The normal Windows SDK includes <iads.h>. I virtually never run a copy of Windows without an SDK installed, so I'm probably not in a good position to say what might work differently if it wasn't, but not much seems broken to me...
I'm involved in C++ project targeted for Windows and Linux (RHEL) platforms. Till now the development was purely done on Visual Studio 2008. For Linux compilation we used 3rd party Visual Studio plugin, which read VS solution/perojects files and remotely compiled on Linux machine.
Recently the decision was to abandon the 3rd party plugin.
Now my big concern is a build system. I was looking around for cross platform build tools. This way I don't need to maintain two set of build files (e.g. vcproj/solution for Windows and make files for Linux).
I found the following candidates:
a. Scons
b. cmake
What do you think about the tools for cross-platfrom development?
Yet another point that bothers me is that Visual Studio (+ Visual Assist) will loose a lot functionality without vcproj files - how you handle the issue with the tools?
Thanks
Dima
PS 1: Something that I like about Scons is that it
(a) uses python and hence it's flexible, while cmake uses propriety language (I understand that it's not a winner feature for a build-system) (b) self contained (no need to generate makefiles on Linux as with cmake).
So why not Scons? Why in your projects the decision was to use cmake?
CMake will allow you to still use Visual Studio solutions and project files. Cmake doesn't build the source code itself, rather it generated build-files for you. For Linux this can be Code::Blocks, KDevelop or plain makefiles or still other more esoteric choices . For Windows it can be among others Visual Studio project files and still others for MacOS.
So Visual Studio solutions and projects are created from your CMakeLists.txt. This works for big projects just fine. E.g. current Ogre3d uses CMake for all platforms (Windows, Linux, MacOS and IPhone) and it works really well.
I don't know much about scons in that regard though, I only used to build one library and only in Linux. So I can't compare these two on fair ground. But for our multi-platform projects CMake is strong enough.
I haven't used Scons before, so can't say how that works, but CMake works pretty well.
It works by producing the build files needed for the platform you're targeting.
When used to target VC++, it produces solution and project files so from VS, it appears as if they were native VS projects. The only difference is, of course, that if you edit the project or solution directly through VS, the changes will be erased the next time you run CMake, as it overwrites your project/solution files.
So any changes have to be made to the CMake files instead.
We have a big number of core libraries and applications based on those libraries. We maintain a Makefile based build system on Linux and on Windows using the Visual Studio solution for each project or library.
We find it works well for our needs, each library or app is developed either on linux or windows with cross compilation in mind (e.g. don't use platform specific api's). We use boost for stuff like file paths, threads and so on. In specific cases we use templates/#defines to select platform specific solution (for example events). When is ready we move to the other system (linux or windows), recompile, fix warnings/errors and test.
Instead of spending time figuring out tools that can cross compile on both platforms we use system that is best for each platform and spend time fixing specific issues and making the software better.
We have GUI apps only on Windows atm. so there's no GUI to cross compile. Most of our development that is shared between Windows and Linux is server side networking (sockets, TCP/IP, UDP ...) and then client side tools on Linux and GUI apps on Windows.
Using with perforce for source code version management we find in quite many cases that the Linux Makefile system is much more flexible for what we need then Windows VS. Especially for using multiple workspaces (views of source code versions) where we need to point to common directories and so on. On Linux this can be done automatically running a script to update environment variables, on Visual Studio referencing environment variables is very inflexible because it's hard to update automatically between views/branches.
Re sync question:
I assume you are asking how to make sure that the two build systems get synchronized between linux and windows. We are actually using Hudson on Linux and CruiseControl on Windows (we had windows first with cruise control, when I went to setup linux version I figured Hudson is better so now we have mixed environment). Our systems are running all the time. When something is updated it is tested and released (either windows or linux version) so you would know right away if it does not work. During testing we make sure all the latest features are there and fully functional. I guess that's it, no dark magic involved.
Oh you mean build scripts ... Each application has it's own solution, in solution you setup up dependencies. On Linux side I have a makefile for each project and a build script in project directory that takes care of all dependencies, this mostly means build core libraries and couple of specific frameworks required for given app. As you can see this is different for each platform, it is easy to add line to build script that changes to directory and makes required project.
It helps to have projects setup in consistent way.
On Windows you open project and add dependency project. Again no magic involved. I see this kind of tasks as development related, for example you added new functionality to a project and have to link in the frameworks and headers. So from my point of view there is no reason to automate these - as they are part of what developers do when they implement features.
Another options is premake. It's like cmake in that it generates solutions from definition files. It's open source and the latest version is very highly customizable using Lua scripting. We were able to add custom platform support without too much trouble. For your situation it has support for both Visual Studio and GNU makefiles standard.
See Premake 4.0 Homepage
CruiseControl is a good choice for continuous integration. We have it running on Linux using Mono with success.
Here is an article about the decision made by KDE developers to choose CMake over SCons. However I've to point that this article is almost three years old, so scons should have improved.
Here is comparison of SCons with other building tools.
Had to do this a lot in the past. What we did is use gnu make for virtually everything including windows at times.
You can use the project files under windows if you prefer and use gnu make for Linux.
There isn't really a nice way to write cross platform makefiles because the target file will
be different among other things (and pathname issues, \ vs / etc). In general, you'll probably be tweaking the code across the various platforms to take subtle differences into account, so a tweak to a make file and checking on the other platforms would have to happen
anyway.
Many OS projects maintain Makefiles for different platforms such as zlib where they are named like Makefile.win, Makefile.linux etc. You could follow their lead.