corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject Visual Studio Solutions (was RE: platform with minzip, commit or not commit.)
Date Thu, 01 Jan 2015 19:31:13 GMT
Do we know of any ASF Project that includes Visual Studio artifacts in its source-code tree?
 If someone has managed it, we need to find out what they do and how they satisfy the strict
rules about what Apache Project Releases are.

 - Dennis

 -- responding below to --
From: jan i [mailto:jani@apache.org] 
Sent: Thursday, January 1, 2015 02:15
To: dev@corinthia.incubator.apache.org; Dennis Hamilton
Subject: Re: platform with minzip, commit or not commit.

[ ... ]

I still believe we should have visual studio solution checked in, so that
windows developers are up an running in no time.

[ ... ]

BACKGROUND OBSERVATIONS

The TL;DR of it: I can do it, but not without putting binary artifacts in the tree.

DETAILS

I have been looking, in a side project, at how to include Visual Studio Solutions in the source
tree without making the code hard to work with if you don't want to (or can't) use Visual
Studio.  What I have been doing there, but can't do here, is put the VS project into a Zip
that is extracted into a directory that is not under source control and that Visual Studio
can be launched on.  In that context I don't need a command-line way to unzip the project,
I can just use the Windows GUI to extract the zip into the directory whenever I want to use
the Visual Studio Project.  These are all tiny little projects.

What may be useful to know for Corinthia is this: 

 * A Visual Studio solution .sln file is just a text file. 
   It appears to be rather stable, in that launching VS from it does
   not cause it to be altered.

 * A Visual Studio VC project .vcxproj file is an XML (MSBuild) Document.
   It is not altered by a build.  Configuration and setting changes might
   impact it.

 * The Visual Studio VC Project Filter .vcxproj.filters file is another
   MSBuild XML Document.  This is essential - it changes if anything is
   added to the code, whether includes to use, more source files, any
   resources, or locations of those.  (I have the source code external
   to the project, not in the same directory with the project.)

 * The Visual Studio VC Project User .vcxproj.user file is another 
   MSBuild XML Document.  I don't know what has this change.  Mine 
   don't have much in them.

Then there are some binary artifacts

 * The .sdf file is a cache that Visual Studio builds, which is quite
   large.  This does not have to be preserved.  It can be gigantic.
   It will be rebuilt on the first Build or Compile.

 * The VS User Options .suo file (one for each version of Visual Studio 
   that has been used) is a *binary* file.  And it is needed in order
   to preserve the compilation configuration. For example, the target
   platform and whether Debug or Release.  The extension is .v12.suo
   for Visual Studio 2013.  It is .v14.suo for Visual Studio 2015 and
   2015 will upgrade the .v12.suo to a .v14.suo but leave the .v12
   one.

Here are the problems I see with including these directly in a source tree:

 * They include one binary artifact, the User Options file.
 * They are not actually source code, even when in text or XML, in that
   producing or understanding them manually, while possible, is not 
   normal and they are useless to non-Visual Studio developers.
 * They can change through incidental use that need not mean the source
   tree actually needs to be synchronized (and we'd get collisions on this
   stuff that would be bizarre to resolve).

Bundling these into Zip files so they are stable and in the code tree but
their extracted form is not works just fine *except* it puts a binary 
artifact in the source-code tree and that is quite toxic on ASF projects.
I see no point in fighting City Hall on this one.

In a way, such Zips are a form of convenience binary, just not the usual
kind.  But they aren't derived from anything in the source tree, so they
are really external artifacts.  And they need to be injected into a 
working copy of the source tree to be useful, since they operate along-
side the source code.

I don't like where this is leading.  It makes no sense to treat Visual
Studio projects as externals.  

An alternative would be places in the source code tree are sort of "Your
Visual Studio Project Here" with instructions on what project to create.
That's even more unpleasant in my thinking.

Maybe there's a hybrid case.  There can be placeholders in the source
tree.  That makes sense.  There are probably alternative build arrangements
nearby.  One could have a convenience binary that is a Zip for Visual
Studio Developers.  If downloaded to the root of the working copy of the
Source and extracted right there, it could interleave the Visual Studio
Projects in just the right places (along with all the .gitignores that
keep its material out of the source tree).

This seems totally bizarre.


Mime
View raw message