[OpenAFS-win32-devel] Visual Studio Solution

[Mickey Lane]

Re: A Visual Studio solution for OpenAFS on Windows...

The solution as it is currently implemented requires that a user first
complete a build using the existing method. The main reason for this is
that the existing method builds tools (i.e. rxgen) that create source
files. The solution currently builds some of these tools but not all of
them.

There's also the practice of copying many header files into the
dest tree and compiling from there. I have not yet configured the
projects to use the header files from their initial locations.

My goals with this project are as follows, in order:

1. Provide a source browsing environment

2. Build selected components with debug/development code to run in
   conjunction with the 'official' release.

3. Build everything and prove the client functions in the same
   manner as the official release. Support 32 & 64-bits, debug &
   release (checked or free if you prefer).

4. Have the solution produce .msi files and be a replacement for the 
   existing process (or at least an alternative).

I'm currently about 75% through #2. The solution (running on XP) has
been able to debug clients running in several VMware Workstation guest
systems (i.e. XP, Server 2008, etc).


re some of Jeffrey Altman's comments:


> I would suggest that you maintain and package your VS2008 solution
> separate from the OpenAFS source tree.


That's pretty much what I had in mind when I started this. The solution
consists of a tree named msft_vc8. This directory contains the solution
file (OpenAFS.sln) and one subdirectory for each of the ~33 projects.
A user would unzip everything into the directory containing the src
and doc trees. Everything in the projects use relative access to the
src, dest, etc trees.


> 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.


I think the following are true:

  Visual Studio 2008 will not install on 2000. XP+ only.
  Some products built using XP+ & VS2008 will run on 2000.

I need to discover if the OpenAFS client is one of those products.

If it is, I don't think it's unreasonable to require XP+ as a
development platform for this. I suspect a typical 2000 system is
probably not up to the task from a hardware point of view anyway.

If it's not, I would try to learn why.


> 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.


For the foreseeable future, I think the only reasonable thing to do
is leave the existing process alone and have the VS solution pick
up any changes to the build structure as they are accepted. I'm
willing to do that.

It's on my 'to-do' list to implement a nightly build of everything.
If I do that using both nmake (the existing build) and the
command line interface to VS solutions/projects, I'll know
pretty quick when something in the solution breaks due to an update.


> 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.


Migrating from the current VS 2008 back to VS 2005 is not impossible.
I would be reluctant to do it until I had a better understanding of
the 32 vs. 64-bit impact. VS 2003 & 2005 don't do 64-bit very well.

We can probably stand to wait a year or two before dealing with 2010.


> 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.


Quite true.


I'm pretty sure I can get SNA to host a download point for this stuff.
When I get it cleaned up a little, I'll look into setting that up
and providing a pointer.

Regards,
Mickey.