openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject Capstone 2013 Client Requirements Document Status?
Date Sun, 23 Nov 2014 23:56:45 GMT
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:pescetti@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org


Mime
View raw message