RE: Putting Windows First ( was RE: null)

["Dennis E. Hamilton" <de...@acm.org>]

> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Wednesday, July 13, 2016 12:57
> To: dev@openoffice.apache.org
> Subject: Re: Putting Windows First ( was RE: null)
> 
[ ... ]
[orcmid] 
> I would like to suggest a way of squeezing out from between the rock and
> hard place, and getting more developers:
> 
> Separate out the Windows build process. Pick one of the common IDE's,
> and create a project file that sets all environment variables for
> Windows. Get as close as possible to the step-by-step build instructions
> for Windows being:
> 
> Check out the source from SVN.
> 
> Open the project file in $IDE$.
[orcmid] 

I don't think it is necessary to have an IDE commitment.

Everything needed to do a build on Windows can be done with command-line tools that are part of the Windows SDK.  Other externals needed for builds can be obtained in Windows versions.  It is how Visual Studio works -- it spawns command-line operations.

So long as the SVN Working copy has the correct ignore settings, once could then create projects if desired, and there might be a way to download a .zip of project files that could be expanded into a build slot in the Working copy.  Although, since most of what is needed is in text and XML files, there is a way to do this at a lower level that doesn't require binaries in the source tree. 

That should get rid of the CygWin dependency for Windows builds and let the available tools work at their best.

I think the bigger challenge is to be able to do incremental builds or even build libraries shared within AOO separately as a way to get problems of massive clean builds that take hours and don't help localize errors much.  That's probably the way to build up the Windows build case anyhow.  

Note: If one is careful about the filepath rewriting business in CygWin, one can execute Windows command-line tools pretty easily, using .bat files as bridges -- .bat files execute properly in CygWin and MSys where I have tried it, and they will work correctly when used directly via cmd.exe.  That is also how one gets environment variables set properly, etc.  (One needs to get around a couple of glitches where CygWin and its cousins treat the environment as case sensitive but the Windows SDK tools do not.)

And then there's [unit] testing to consider.


 - Dennis

> 
> Build it.
> 
> In particular, use of a UNIX-derived shell must not be required for
> Windows builds.
> 
> In this vision, the core work would be done on Windows, using an IDE.
> There would still be a need for a small number of Linux etc. people to
> handle building for their environments, and to keep the Windows-based
> developers from building in unwarranted assumptions.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Putting Windows First ( was RE: null)

[Patricia Shanahan <pa...@acm.org>]

On 8/31/2016 10:25 AM, Dennis E. Hamilton wrote:
>
>
>> -----Original Message-----
>> From: Patricia Shanahan [mailto:pats@acm.org]
>> Sent: Wednesday, July 13, 2016 12:57
>> To: dev@openoffice.apache.org
>> Subject: Re: Putting Windows First ( was RE: null)
>>
> [ ... ]
> [orcmid]
>> I would like to suggest a way of squeezing out from between the rock and
>> hard place, and getting more developers:
>>
>> Separate out the Windows build process. Pick one of the common IDE's,
>> and create a project file that sets all environment variables for
>> Windows. Get as close as possible to the step-by-step build instructions
>> for Windows being:
>>
>> Check out the source from SVN.
>>
>> Open the project file in $IDE$.
> [orcmid]
>
> I don't think it is necessary to have an IDE commitment.
>
> Everything needed to do a build on Windows can be done with command-line tools that are part of the Windows SDK.  Other externals needed for builds can be obtained in Windows versions.  It is how Visual Studio works -- it spawns command-line operations.
>
> So long as the SVN Working copy has the correct ignore settings, once could then create projects if desired, and there might be a way to download a .zip of project files that could be expanded into a build slot in the Working copy.  Although, since most of what is needed is in text and XML files, there is a way to do this at a lower level that doesn't require binaries in the source tree.
>
> That should get rid of the CygWin dependency for Windows builds and let the available tools work at their best.
>
> I think the bigger challenge is to be able to do incremental builds or even build libraries shared within AOO separately as a way to get problems of massive clean builds that take hours and don't help localize errors much.  That's probably the way to build up the Windows build case anyhow.
>
> Note: If one is careful about the filepath rewriting business in CygWin, one can execute Windows command-line tools pretty easily, using .bat files as bridges -- .bat files execute properly in CygWin and MSys where I have tried it, and they will work correctly when used directly via cmd.exe.  That is also how one gets environment variables set properly, etc.  (One needs to get around a couple of glitches where CygWin and its cousins treat the environment as case sensitive but the Windows SDK tools do not.)
>
> And then there's [unit] testing to consider.

There are already unit tests that run in Eclipse.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

RE: Putting Windows First ( was RE: null)

["Dennis E. Hamilton" <de...@acm.org>]

> -----Original Message-----
> From: Patricia Shanahan [mailto:pats@acm.org]
> Sent: Wednesday, August 31, 2016 14:20
> To: dev@openoffice.apache.org
> Subject: Re: Putting Windows First ( was RE: null)
> 
> On 8/31/2016 10:25 AM, Dennis E. Hamilton wrote:
> >
> >
> >> -----Original Message----- From: Patricia Shanahan
> >> [mailto:pats@acm.org] Sent: Wednesday, July 13, 2016 12:57 To:
> >> dev@openoffice.apache.org Subject: Re: Putting Windows First ( was
> >> RE: null)
> >>
> > [ ... ] [orcmid]
> >> I would like to suggest a way of squeezing out from between the
> >> rock and hard place, and getting more developers:
> >>
> >> Separate out the Windows build process. Pick one of the common
> >> IDE's, and create a project file that sets all environment
> >> variables for Windows. Get as close as possible to the step-by-step
> >> build instructions for Windows being:
> >>
> >> Check out the source from SVN.
> >>
> >> Open the project file in $IDE$.
> > [orcmid]
> >
> > I don't think it is necessary to have an IDE commitment.
> >
> > Everything needed to do a build on Windows can be done with
> > command-line tools that are part of the Windows SDK.  Other externals
> > needed for builds can be obtained in Windows versions.  It is how
> > Visual Studio works -- it spawns command-line operations.
> 
> To me, direct use of command line tools feels like an awkward half-way
> step between the punch cards I used when I started programming, and the
> IDE's I use for most of my programming now.
[orcmid] 

The advantage is that the command-line operation is agnostic about choice of IDE so long as one can use a chosen IDE successfully.  

You can also build make projects in Visual Studio.  You're likely to find Git integration built in and have to do more work for SVN, but it is not a lot more work.  

I haven't tried Visual Code, but that might be a likely candidate too, without any of the heavyweight qualities of Visual Studio.  It's integration is rather lightweight but I don't know how well it works with C++.

Probably the biggest integration points (apart from source control) are line matching of compiler error messages and also build messages to a window in the IDE.  I assume that anything that uses the Windows SDK and command-line compiler will handle that.

I am not opposed to IDE integration, so long as it is on top of the Working check-out.  When we end up making a choice of IDE in the SVN and the delivered buildable source releases, I think that won't fly.  We will be forcing someone to operate with multiple tool sets and not their chosen one.

Let me put it this way.  We want to be able to do quality Windows builds of Windows binaries.  The fall-line case is to use a freely-available native Windows toolchain.

At the moment there are no IDE dependencies in the Apache OpenOffice system, and having folks be able to use IDEs is an orthogonal (but interacting) consideration.  We need to enable that without imposing one, it seems to me.

In any case, we are a long way from any solution to this.

 - Dennis


> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Putting Windows First ( was RE: null)

[Patricia Shanahan <pa...@acm.org>]

On 8/31/2016 10:25 AM, Dennis E. Hamilton wrote:
>
>
>> -----Original Message----- From: Patricia Shanahan
>> [mailto:pats@acm.org] Sent: Wednesday, July 13, 2016 12:57 To:
>> dev@openoffice.apache.org Subject: Re: Putting Windows First ( was
>> RE: null)
>>
> [ ... ] [orcmid]
>> I would like to suggest a way of squeezing out from between the
>> rock and hard place, and getting more developers:
>>
>> Separate out the Windows build process. Pick one of the common
>> IDE's, and create a project file that sets all environment
>> variables for Windows. Get as close as possible to the step-by-step
>> build instructions for Windows being:
>>
>> Check out the source from SVN.
>>
>> Open the project file in $IDE$.
> [orcmid]
>
> I don't think it is necessary to have an IDE commitment.
>
> Everything needed to do a build on Windows can be done with
> command-line tools that are part of the Windows SDK.  Other externals
> needed for builds can be obtained in Windows versions.  It is how
> Visual Studio works -- it spawns command-line operations.

To me, direct use of command line tools feels like an awkward half-way
step between the punch cards I used when I started programming, and the
IDE's I use for most of my programming now.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org