openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Putting Windows First ( was RE: null)
Date Wed, 31 Aug 2016 17:25:46 GMT

> -----Original Message-----
> From: Patricia Shanahan []
> Sent: Wednesday, July 13, 2016 12:57
> To:
> Subject: Re: Putting Windows First ( was RE: null)
[ ... ]
> 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$.

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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message