Is there an Ignore Standard Library Path in VS2008

Question

I have a C++/MFC app that I am trying to make more portable in preparation for cross-platform conversion to something like wxWidgets.

My first step was to identify all of its compiler and linker dependences, such as the CRT library, Windows SDK, and MFC, and collect these together in the same filestore as the project, so that the whole package would be independent of any particular working environment (WinSDK version, etc) that might vary from one computer to another.

For compiler dependencies, this was relatively easy. By using the (/X) option

Project > Properties > C/C++ > Preprocessor > Ignore Standard Include Path

I was able to detach the project from the default include folders defined in

Tools > Options > Projects and Solutions > VC++ Directories

This of course generated a slew of compilation errors, and by transferring all of these required libraries to my filestore and adding their new paths manually to the

Project > Properties > C/C++ > General > Additional Include Directories

I was able to ensure that I had my own copy of everything the compiler depends on for my project.

However, for the linker it was not so easy. While it does have the option

Project > Properties > Linker > General > Additional Library Directories

for adding the custom dependencies, I could not find a way to get the linker to ignore the standard library paths to help me identify these dependencies.

All I could find was

Project > Properties > Linker > Input > Ignore All Default Libraries

but this is not the same thing at all. It just causes the linker to ignore the pragmas in the headers that specify which library files should be linked to, but leaves the standard library paths available for the linker to search.

In the end, I had to go back to

Tools > Options > Projects and Solutions > VC++ Directories

and delete all of the "Library files" directories to ensure I was not inadvertently overlooking a dependency. This of course now makes VS2008 unable to build other projects, where I am not trying to achieve the same type of dependency isolation.

It seems odd that the compiler has this useful override switch (/X) for disabling standard environment paths, but the linker does not.

Can anyone shed light on this? Or am I missing something?

Answer 1

How does gathering all dependencies advances you towards something resembling cross-platform? Cross platform in what way exactly? If you want your source to compile on non-VS or non-Windows platforms, (which is my personal default interpretation of 'cross platform') marshaling binary dependencies has nothing to do with it.

If you migrate to say wxWidgets you're still dependent on the version of wxWidgets - or any other framework for that matter - and its dependencies. Marshaling binary dependencies is also a lot harder than it looks: The redistributable binaries (CRT, MFC, OpenMP) were side-by-side assemblies in VS2008, which essentially means multiple versions co-exist on your disk - typically under C:\Windows\winSxS folder - and your application guides the windows loader on which version exactly it depends via its manifest. You might technically be able to track it and select your particular versions, but it won't be fun.

But really, why stop there? Win32 dlls - user32, kernel32 etc. - are also runtime dependencies that might vary among environments, depending on updates installed. I hope you won't try to collect those and drop with an installation, I'm just trying to make a point that marshaling dependencies is not the way to go.

---

EDIT: With cross-platform out of the way, I can say that personally I divide the binary dependencies into two categories:

1. Stuff that comes with an installer - e.g WinSDK, DirectX, CUDA.

2. Stuff that comes without an installer - e.g. custom 3rd party components.

About category (1): I maintain a dev-station installation list, and apply it to all workstations that I need to build on. Regarding category (2): I push these items to source control, and use post build events to place them at the approprite bin directory. (You might need pre-build event for some type libraries, though).