views:

159

answers:

2

Let's say we have an application that will need Boost to compile. Boost being an external library, updated regularly, and our application having multiple binaries and multiple versions ("multiple" as in "Let them grow and multiply"... don't ask...), we need an easy to update/maintain indirection to have for each app's version link with the right Boost version.

For example:

  • MyApp 8.0 => Boost 1.34
  • MyApp 8.1 => Boost 1.35
  • MyApp 9.0 => Boost 1.35
  • MyApp 10.0 => Boost 1.37

On a Linux filesystem, we would create a symbolic link redirecting to the right boost directory:

  • MyApp 8.0 => MyAppBoostLink_8.0 => Boost 1.34
  • MyApp 8.1 => MyAppBoostLink_8.1 => Boost 1.35
  • MyApp 9.0 => MyAppBoostLink_9.0 => Boost 1.35
  • MyApp 10.0 => MyAppBoostLink_10.0 => Boost 1.37

This would enable us to easily update MyApp 10.0 to link with Boost 1.38 when it will be available, just by replacing the symbolic link.

But on Windows, this does not work (or I missed something).

Boost itself seems to give up on the idea: With BJam, I recall seeing warnings saying BJam was copying the lib files because symbolic links did not work on WinNT. I tried an alternative, as we use Visual C++, but no pragma resolves this problem (I searched for a pragma adding default search directories for header includes and library links, but found none).

I can't believe I'll need to launch a script to check-out the VCPROJs files (Visual C++ XML makefiles), to update the Boost includes, and then check-in the modifications, but I see no other solution until Windows have working symbolic links (or either I discover how to create them).

Is there a better idea?

Edit

The problem disappeared when we updated our compiler, from Visual C++ 2003 to Visual C++ 2008. Apparently, Visual C++ 2008 sees symbolic links across networks.

+3  A: 

Windows symlinks equivalent on NTFS filesystems is called junctions: http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx

Jacek Ławrynowicz
Of course, you can't count on them being available. Upgraded PCs will be running off FAT32
MSalters
+2  A: 

You could keep the base directory of the boost installation in a version-specific environment variable that gets set in a "starter batch file" for VS2008. This is probably not quite as ugly as having to manipulate .vcproj files as part of the build process. Probably...

Timo Geusch