openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Capstone 2013 Client Requirements Document Status?
Date Mon, 24 Nov 2014 11:23:54 GMT
On 24 November 2014 at 00:56, Dennis E. Hamilton <>

> 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?
yes it did, sadly enough the students did not really put effort into it.
Steve Hathaway helped me a lot onsite.

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.)
We ended having a pretty good converting tool for the simple function
groups, so in general this was more a proof of concept, than an actual

I learned enough to verify, that with a couple of students one more
semester we could have a microsoft visual studio solution running.

The project files dont need to be svn, we have tested to have Cmake
generator files, that can make both makefiles and project files.

The whole subject was discussed earlier, and it was clearly stated that we
do not want an extra build system, on top of the unfinished ones we already
have, that is the main reason why the results never went further than the
wiki, the branch, and our google drive.

> 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.
 I do too....goal was to get rid of cygwin, and work like a windows
programmer works.

> 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.
yes, and please do not forget that all committers can get the full version
for free together with a bunch of other microsoft tools.

> 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.
you might want to check the capstone branch, some of the latest stuff
should be in there, otherwise I can privately share my google drive with

Steve and I discussed continuing the project with this capstone semester,
but due to a lot of problems with their registration, and the somewhat
personal discussions on this and other AOO lists, I decided to  take a

I still hope we can make a future project with capstone, because I at
least, find this to be a cornerstone in acquiring and keeping new
developers. Who knows in the future I might find others who share my point
of view.

jan i.

> - Dennis
> 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 []
> Sent: Sunday, November 23, 2014 02:39
> To:
> Subject: Re: Unofficial photos ApacheCon EU 2014
> [ ... ]
> Steve Hathaway (see
> )
> [ ... ]

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message