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 RE: Visual Studio Solutions (was RE: platform with minzip, commit or not commit.)
Date Thu, 01 Jan 2015 22:31:58 GMT
 -- replying below to --
From: jan i [mailto:jani@apache.org] 
Sent: Thursday, January 1, 2015 13:06
To: dev@corinthia.incubator.apache.org; Dennis Hamilton
Subject: Re: Visual Studio Solutions (was RE: platform with minzip, commit or not commit.)

On 1 January 2015 at 20:31, Dennis E. Hamilton <dennis.hamilton@acm.org>
wrote:
[ ... ]
>  * 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.

<orcmid>
   Checking my understanding.

   When I create a VC Project myself, using existing source files, it
   will provide relative links to those files in the VC Project file.
   So, it does not matter where the root of the code tree is cloned,
   since its absolute location does not matter, so long as the 
   relative pathes from the VC Project to the existing source files in
   the repository are preserved.

   When CMake produces VC Project files, those will have absolute
   paths to the existing source files.  

   So when a VS user clones the repo and opens the solution, the
   VC Project files will be broken because there is little chance
   that the absolute path is preserved (except by happy accident).
   So this user has to run CMake to get new VC Project files to use?

   Is that it?
</orcmid>

[ ... ]

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.

<orcmid>
   OK, now I am flummoxed by the need to handle a CMake dependency.
   We are expecting the Visual Studio user to use CMake to build the
   system?  And to make the vc project files?

   What about when a Visual Studio developer *starts* some code using
   Visual Studio.  He is adding some source to the tree, he is putting
   his project and solution in some prescribed place so he can work
   on the code in Visual Studio, or he simply wants to add a project
   To the solution that is already there.

   And he expects to commit his source and the new solution/project.

   I am having difficulty imagining the instructions that the VS-skilled
   developer is given to have this work.

   ... and we're worrying about unzipping. Heh.
</orcmid>

[ ... ]
>  * 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.

<orcmid>
   I just double-checked.  I have a configuration set to build x86 and
   Release.  If I delete the .suo file, the solution opens with the
   default x86 and Debug configuration.  
</orcmid>


>
> Here are the problems I see with including these directly in a source tree:
[ ... ]
>  * 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

<orcmid>
   Well, I would love to say that, but I don't think it is accurate.
   The CMakeFile.txt is not generated is it?  I thought it was
   inserted by the developer to help CMake do the right thing.

   Am I mistaken?
</orcmid>

[ ... ]
> 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
files.

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

<orcmid>
   My use of zip is to keep the Visual Studio parts out of the direct 
   source tree.  (The zip is there, but it is the zip that is committed,
   not the individual Visual Studio components.)
   I can do that on my projects, because it is not at the ASF. 
   It also bypasses problems like the one I mentioned where Visual Studio
   for any reason modifies one of those artifacts when VS is used to
   work on the code.

   I do see that there is a lot of copying around done in the capstone
   project.  I am managing just to extract the build materials and leave
   the source code in its common location.

   I am also not coping with the constraints of a build-generation system
   like CMake.  I would love to never get to that.  These are for my
   personal projects that I want beginners to be able to use [;<).
</orcmid>


[ ... ]


Mime
View raw message