-- replying below to -- From: jan i [mailto:[email protected]] Sent: Thursday, January 1, 2015 13:06 To: [email protected]; 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 <[email protected]> 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> [ ... ]
