Oh my. I wasn't around when that project was created. Is there any update on what was accomplished? It ended before Summer 2014, yes?
I have the same itch, although I don’t think the builds should require Microsoft Project files. There are too many problems with those, along with other bloat. (One problem is how each release of the VS IDE updates them, so having those be committed to the code base screws things up for someone using older versions.) But I think clean builds using Microsoft tooling is a great idea, and it would be great if it did not require a POSIX shim and the friction that creates for what developers on the Windows platform are taught, know, and have free tools for. It could be all right to use a POSIX shim by those whose toolcraft favors it, but it should not be required. The availability of the Visual Studio 2013 Community Edition can have a great impact on this idea, since that now includes ATL, MFC, and much more, including built-in git support. A REQUEST: I'd like to see a module that was converted along the lines of this project to see if my ideas can also be applied to it. - Dennis THINKING OUT LOUD I see there are several more pages on the wiki about this project, so my hypothesis may already be refuted. Here it is, for now: There is a way of structuring a project repository so that the build ephemera and even the creation of VS Solutions/Projects is in directories that are not part of the shared code. I saw this done beautifully in a project on GitHub that built with gcc or Clang on Windows. (They needed C++11 features and apparently VC++ didn't have enough of those.) I think the same can be done with VC++ and makefile Projects. The VS IDE can still be used, with the benefits that provides, and one can use the toolset and Debug builds locally if the repository is structured properly. This provides local efficiencies in compile-test-revise, etc., without forcing onto others. It should be possible to use a different IDE (Eclipse, whatever), since that choice is not bolted into the repository and it can be factored in a way to allow that. I have the impression that it is not understood how well the VS toolset can be operated from the command line and scripts, no matter how well that is hidden when it is all driven from the IDE. I agree that dependency management and the ability to have separately buildable and testable modules is very important to figure out. That should be a feature rather than having to swallow the whole thing as a entrance test to AOO development. (I thought CMake could have been used that way too and I may be misunderstanding CMake and/or the rationale about not using it here. I would avoid it out of preference for factoring builds differently. [I don't use #ifdef much either [;<]). I favor the approach in the project of starting on a module-by-module basis and having everything still build completely after each module rearrangement. It does mean that CygWin (or the friendlier but less stable MSYS2) would need to still be used and the non-Windows CMake-generated builds must also not be messed up. The kind of repository reorganization that allows module separation has great appeal, and it is more aligned with how Git-hosted projects tend to be more-optimally coordinated. -----Original Message----- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Sunday, November 23, 2014 02:39 To: dev@openoffice.apache.org Subject: Re: Unofficial photos ApacheCon EU 2014 [ ... ] Steve Hathaway (see https://wiki.openoffice.org/wiki/Capstone_2013_Client_Requirements_Document ) [ ... ] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
