HI

Just made it simpler for everyone interested, have a look at
https://svn.apache.org/repos/asf/openoffice/branches/capstone2013/student_work

it contains all output from the project.

have fun.
rgds
jan i:

Ps. dont hesitate to ask if you have questions.


On 24 November 2014 at 12:23, jan i <[email protected]> wrote:

>
>
> On 24 November 2014 at 00:56, Dennis E. Hamilton <[email protected]>
> 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’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
> 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 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
> 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 (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:[email protected]]
>> Sent: Sunday, November 23, 2014 02:39
>> To: [email protected]
>> Subject: Re: Unofficial photos ApacheCon EU 2014
>>
>> [ ... ]
>> Steve Hathaway (see
>>
>> https://wiki.openoffice.org/wiki/Capstone_2013_Client_Requirements_Document
>> )
>> [ ... ]
>>
>>
>>
>

Reply via email to