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 <kay.sch...@gmail.com> 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
[mailto:dam...@apache.org]
..
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:

http://svn.apache.org/viewvc/openoffice/branches/capstone2013/


--
--------------------------------------------
MzK

"Time spent with cats is never wasted."
                   -- Sigmund Freud


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




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

Reply via email to