corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Visual Studio Solutions (was RE: platform with minzip, commit or not commit.)
Date Thu, 01 Jan 2015 21:05:39 GMT
On 1 January 2015 at 20:31, Dennis E. Hamilton <>

> 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.
At the moment I dont know other projects, except that in AOO we have run
experiments how to do this (capstone branch).

But since it is XML files, there are no problem seen from the bylaws of
Apache, that is something I checked last year before starting the capstone
project in AOO.

>  - Dennis
>  -- responding below to --
> From: jan i []
> Sent: Thursday, January 1, 2015 02:15
> To:; 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.
> [ ... ]
> The TL;DR of it: I can do it, but not without putting binary artifacts in
> the tree.
> 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.
A Zip file, would be a solution, but not one I prefer.

> 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.
That is correct, this is the first file we need to commit.

There is a slight challenge here, cmake generates full path, and we need
relative path (to enable windows programmers to relocate the sources).
Microsoft has no problem with relative path.

  * 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.
These files are changed by cmake, and should not be changed  manually. One
should not change settings within visual studio.

There is a slight challenge here, cmake generates full path, and we need
relative path (to enable windows programmers to relocate the sources).
Microsoft has no problem with relative path.

Again these are files we need to commit.

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

Everything changes (at least vcxproj and filter file both change when a
file is added/removed).

Please remember that the origin is CMakeFile.txt, so whenever someone
changes in CMakeFile.txt a cmake -G must be run to update the VC files.
This was if I remember right why peter did not like my proposal, the fear
of those not being in sync.

These 3 files are the only ones you need to start visual studio. Try for
the fun of it, to delete all other visual studio files, and you will see
the others get recreated (I do it very often, in another 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.
This is not needed, but VC generates it. In a multiuser environment it
allows you to have local personal settings.

> 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.
No it is not needed, it will be generated if not there. The compilation
configuration, is stored as XML in the vcxproj file.

> Here are the problems I see with including these directly in a source tree:
>  * They include one binary artifact, the User Options file.
not needed

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

You could say the same about our CMakeFile.txt

> .
>  * They can change through incidental use that need not mean the sourceYou
>    tree actually needs to be synchronized (and we'd get collisions on this
>    stuff that would be bizarre to resolve).
You could say the same about our CMakeFile.txt

> 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.
NO binary artifacts, that is illegal, but also not needed. In the capstone
project (AOO), we managed to generate all that was needed with ONLY XML

I would also not make a zip file. I would make a directory
and commit it normally.

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

> I don't like where this is leading.  It makes no sense to treat Visual
> Studio projects as externals.
No we should not, and not as zip, we should treat it as a normal directory
( with xml files (.sln .vcxproj, .vcxproj.filter)

> 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.
I agree that would be unpleasant.

> 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).
Why not use the simple way I suggest.

> This seems totally bizarre.
> rgds
jan i

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message