Hi,

I normally work on linux and use cmake. In cmake I can specify requirements that a library I am linking to is (1) present and (2) satisfies certain version number requirements. Currently I am working on a project on windows using visual studio express 2010 that does not use cmake. I am trying to figure out what is the 'right way' of specifying a version number constraint on the libraries we link against. In theory, we could use cmake on windows to do this, but I am trying to introduce as little change to the build infrastructure as possible.

Any suggestions?

-Josh

Presumably these are 'native' libraries and not CLI assemblies?

And I guess we're talking about dynamic libraries rather than static libraries?

And on Windows, where would you expect libraries to be 'present' if not produced by your build? I ask because there isn't typical install location for libraries like there is on Linux (except for the Global Assembly Cache, hence my first question).

(assuming c/c++)

It seems odd not to mention windows/system32 (as an oft-abused dumping ground for dlls) or WinSxS

Working out which particular dll file windows will try to use at runtime on a given machine has been something of a black art for the last few years - WinSxS was supposed to fix 'dll hell'by allowing you to specify a version number and hash to ensure you get the file you want, but it's rather awkward, so nobody except microsoft wanted to use it.

Apparently the latest solution used for the platform runtimes is to have a version number in the file name, tada.

COM has a whole version/dependency system unto itself, and I suspect WinRT has something similar but new too. I may be wrong.

But really this is all unlikely to help, sorry OP! WinSxS will do what you want, but I suggest you avoid it. Common practice on windows is to package every dll you depend on with your app's installer and dump all the dlls into the app's folder. (then test will something like ProcessMonitor, to make sure WinSxS or similar isn't doing something unexpected). If an installer or (better) merge modules are available for some of the libs you depend on, great.

Not sure how much sense that makes, but gives you some more googleable terms to work with

Thanks for the replies! This is for C++ projects (should have mentioned that). The issue is that we have several 3rd party libraries that we link against in our code. They could be static or dynamic libraries, but the issue is really the version of the library. For instance, we recently updated our version of Qt, so now our software should link against the newer version.

One solution is to dump all of the 3rd party libraries into the repository with our code so that upgrades stay in sync. However, it would be really nice to keep the repo small and focused solely on our code in the interests of performance (pulling down boost and Qt is not something I would want to have to do regularly). So my idea/hope was that using something like cmake I could at least check that the 3rd party libraries being linked on a developers machine are consistent with the code.

It's been a while since I worked on windows, but I couldn't remember any system for organizing libraries (other than dumping DLLs into system32 as mentioned above). I hoped that it was more my ignorance than anything, but it sounds like it is not entirely the case.

Thanks for the help, I think I may try converting our code to cmake since that is where I would like to go with the code-base eventually anyway.

-Josh

Thanks for the replies! This is for C++ projects (should have mentioned that). The issue is that we have several 3rd party libraries that we link against in our code. They could be static or dynamic libraries, but the issue is really the version of the library. For instance, we recently updated our version of Qt, so now our software should link against the newer version.

I think the best you can do is hope that the Qt SDK (for example) defines an environment variable

One solution is to dump all of the 3rd party libraries into the repository with our code so that upgrades stay in sync. However, it would be really nice to keep the repo small and focused solely on our code in the interests of performance (pulling down boost and Qt is not something I would want to have to do regularly).
[/quote]
But you'd only have to do it on each upgrade of a library. In that sense there's little difference in pulling it from a VCS compared with copying it from a network share, except that it would be automated. It's also a good idea (IMHO) to make sure everyone is building against exactly the same versions of each library you depend on, if only to reduce the "works for me" factor.

At an old job of mine, we used to keep both boost and Qt in Perforce and it wasn't so bad. Actually we used to do that with all third party libraries, but those were the biggest two by quite a large margin. I was pulling the source code from Belgium -> England, too. But I do understand your desire to keep the repo clean. Perhaps you could use a separate repo/depot/whatever for third party code? That might not be a bad idea from a licensing administration standpoint anyway.

So my idea/hope was that using something like cmake I could at least check that the 3rd party libraries being linked on a developers machine are consistent with the code.

It's been a while since I worked on windows, but I couldn't remember any system for organizing libraries (other than dumping DLLs into system32 as mentioned above). I hoped that it was more my ignorance than anything, but it sounds like it is not entirely the case.
[/quote]

Indeed, I fear you'll come up empty-handed

As mrbastard mentioned, it's far more common on Windows to ship copies of dlls with each application.

[grrr -- quoted myself rather than editing existing post]