openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <>
Subject Re: Putting Windows First ( was RE: null)
Date Sun, 17 Jul 2016 17:25:57 GMT
On 7/17/2016 9:38 AM, Damjan Jovanovic wrote:
> Windows lacks many of the external libraries present on *nix (jpeg, zlib,
> curl, etc.),  meaning we have to build them internally. They build using
> GNU autotools, which need a *nix shell like Cygwin. In other words, it
> isn't even only AOO that needs Cygwin, it's our dependencies as well.

I'll have to think about that aspect. It may be the case that we need
two stages to the build process, one that every Windows developer can
do, and another that is done by specialists with *nix shell experience.

Most work on AOO is not going to require changes to those libraries, so
a C++ programmer could do useful work using prepared copies of them
rather than building them from scratch.

> Also we need a portable build system, which any Visual Studio based
> solution isn't.

Why do we need a portable build system?

Whether the build system is portable or not makes no difference at all
to end users. It is not part of the AOO functionality. It is merely a
tool that may save costs by avoiding duplication of effort compared to
having separate build systems for different target environments.

In this case I suspect that the total cost of the portable build system
is far higher than the total cost of having separate build systems for
Windows and for the *nix derived operating systems. That total cost
includes every Windows C++ programmer who is a user of AOO, and has been
scared off contributing to AOO by the arcane and fragile build process.

> Damjan
> On Wed, Jul 13, 2016 at 11:52 PM, Kay Schenk <> wrote:
>> On 07/13/2016 12:56 PM, Patricia Shanahan wrote:
>>> On 7/13/2016 10:38 AM, Dennis E. Hamilton wrote:
>>>>> -----Original Message----- From: Damjan Jovanovic
>>>>> []
>>> ..
>>>>> By the way, AOO code and build process are very *nix-centric,
>>>>> leading to Windows being such a pain to develop for, that we would
>>>>> gain more by dropping Windows support, than by dropping all other
>>>>> platforms ;-).
>>>> [orcmid]
>>>> Yes.  I already made the point that, from the perspective of
>>>> developers, development of Windows is very contorted and development
>>>> for Linux is a pleasure.  It was done that way for the convenience of
>>>> Linux-oriented developers.  It creates an awful on-ramp for
>>>> cultivation of new developers.
>>>> The question: How does ceasing support for Windows serve the 87% of
>>>> our current user base?  The technical act is within the power of the
>>>> PMC to determine, and release managers could force the outcome. In my
>>>> estimation, the consequences would be quite terrible.
>>>> We may be "stuck between a rock and a hard place."
>>>>> Damjan
>>> 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$.
>>> 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.
>> Patricia --
>> I think this approach was actually started as a Capstone Project in
>> 2013. You might want to have a look at the information in:
>> --
>> --------------------------------------------
>> MzK
>> "Time spent with cats is never wasted."
>>                    -- Sigmund Freud
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message