Return-Path: X-Original-To: apmail-openoffice-dev-archive@www.apache.org Delivered-To: apmail-openoffice-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A6CB910579 for ; Mon, 24 Nov 2014 11:23:58 +0000 (UTC) Received: (qmail 78751 invoked by uid 500); 24 Nov 2014 11:23:58 -0000 Delivered-To: apmail-openoffice-dev-archive@openoffice.apache.org Received: (qmail 78656 invoked by uid 500); 24 Nov 2014 11:23:58 -0000 Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openoffice.apache.org Delivered-To: mailing list dev@openoffice.apache.org Received: (qmail 78645 invoked by uid 99); 24 Nov 2014 11:23:58 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Nov 2014 11:23:58 +0000 Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 5AA361A0602 for ; Mon, 24 Nov 2014 11:23:48 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id 10so4334232lbg.36 for ; Mon, 24 Nov 2014 03:23:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.201.6 with SMTP id jw6mr20160715lbc.30.1416828234745; Mon, 24 Nov 2014 03:23:54 -0800 (PST) Received: by 10.112.10.16 with HTTP; Mon, 24 Nov 2014 03:23:54 -0800 (PST) In-Reply-To: <007101d00779$23ed83f0$6bc88bd0$@acm.org> References: <007101d00779$23ed83f0$6bc88bd0$@acm.org> Date: Mon, 24 Nov 2014 12:23:54 +0100 Message-ID: Subject: Re: Capstone 2013 Client Requirements Document Status? From: jan i To: Dennis Hamilton Cc: dev , shathaway@apache.org, jan iversen Content-Type: multipart/alternative; boundary=001a11c372b0a3ce8f05089907f6 --001a11c372b0a3ce8f05089907f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 24 November 2014 at 00:56, Dennis E. Hamilton wrote: > 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=E2=80=99t think the builds should requ= ire > 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 implementation. 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 mor= e, > 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 you. 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 break. 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. rgds jan i. > - 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 (Eclips= e, > 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 tha= t > 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 abo= ut > not using it here. I would avoid it out of preference for factoring buil= ds > 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 stab= le > 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_Docume= nt > ) > [ ... ] > > > --001a11c372b0a3ce8f05089907f6--