[OpenAFS-win32-devel] Visual Studio Solution

[Jeffrey Altman]

Mickey Lane wrote:
> I would like to know if there is any interest in the OpenAFS for Windows
> community for a Visual Studio Solution for the Windows client. 
> 
> I have one (VS 2008) that contains projects for most of the libraries,
> DLLs and executables. It'll need some work before it's usable by anyone
> other than myself. If there's interest, I don't mind doing that work and
> making it available, time permitting.
> 
> The solution I implemented lives in a peer directory of the src, doc,
> obj and dest directories. The files it builds wind up under that peer
> directory, not in the existing obj and dest directories. The peer output
> directory structure mimics the existing obj and dest output structure.
> The solution does not require any modifications the existing source
> code, build files, etc in any way.
> 
> My reason for doing this is that after many years, I am most comfortable
> searching, navigating and editing within the Visual Studio environment.
> I use it all the time. It was easier for me to do this than it was to
> deal with a different set of tools. 
> 
> While the solution has built components that have successfully executed
> in conjunction with the files from the current install package and the
> run-time debugging things work, I do not suggest that the solution be
> considered a replacement for the current build process. It could be some
> day but it'd take a awful lot of testing and proving before I'd trust it.
> 
> Comments?
> 
> Mickey.

Mickey:

Thank you for offering this functionality to the community.  I would
suggest that you maintain and package your VS2008 solution separate from
the OpenAFS source tree.   As you are aware, OpenAFS distributions are
not built from VS2008 and the compatible SDKs because OpenAFS still
supports Microsoft Windows 2000.  For that reason binaries are built
using VS2005 and the 2003 R2 SDK / DDK.  Upgrading to VS2008 and later
SDK / DDKs will require the abandonment of Windows 2000 support.
Several large sites that deploy OpenAFS still have large numbers of
Windows 2000 based clients.

In addition to the binaries built and distributed by Secure Endpoints
for OpenAFS, there are still several organizations that build their
own distributions using VS 2003.  One organization builds a subset of
the tree using the Platform SDK compiler and no Visual Studio.

I have several concerns regarding OpenAFS distribution of
Visual Studio solutions.

1. Many developers that contribute to OpenAFS do not use visual
   studio for their Windows development.  I do not want to add
   maintaining a Visual Studio solution as a barrier to new
   developers contributing to OpenAFS.

2. Visual Studio solutions are tied to a particular release.
   VS2003 and VS2005 cannot read a VS2008 solution and VS2010
   must upgrade a VS2008 solution.  This implies that solutions
   would need to be maintained for each of the visual studio
   versions that are in use by the community.

3. Visual Studio solutions have not proven to be very portable
   when defining rules for third party tool sets such as those
   required for building the help files, pdfs, installers,
   cygwin library generation, etc.

Regarding Brant's comment about moving to Microsoft build projects.
The nmake based build system takes care of many steps in the release
process that go beyond just building the binaries.  The nmake system
also digitally signs the binaries, adds binaries and symbols to
a symbol store, and permits third party tools to be seamlessly
added to the build system.  Microsoft build has the downside that
it cannot generate output into a build tree separate from the source
tree.  It is not possible to build OpenAFS for Windows out of a
read only volume in AFS but that is certainly something I would
like to see be possible someday in the future.

Jeffrey Altman