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:[email protected]] Sent: Thursday, January 1, 2015 02:15 To: [email protected]; 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.
