openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Thoughts on a new build system for AOO
Date Sat, 06 Feb 2016 06:04:02 GMT
Hmm, have to think about the IDE question.  I'm a yes and no about that.  IDEs should be usable.
 I'm not so clear that one should be essential to do a plain build of the product from source.

I prefer command-line builds on Windows, although I use IDEs to edit and to do local builds
of things that can be built (for error checking) and, if possible, that have small testable
components.  Not exactly my picture of the AOO scheme, so, philosophically, perhaps inappropriate
here despite my druthers.  

My basic motivation for providing command-line builds is that someone be able to repeat a
build from source with the least-possible requirements for tools, with as few needed to be
installed as possible and all freely-available if not already provided.  In my world, one
of the least-possible requirements is cmd.exe [;<).

So, I think I am atypical and will recuse myself here.

Meanwhile ...

I dug into SCons a bit.  I am not certain that a build system with a 184-page PDF manual is
a winner, and it has enough options to scare everybody.  On p.176, there is a wonderfully
terse section on "Windows: Cygwin Tools and Cygwin Python vs. Windows Pythons."  Here is the
gem therein.

   In practice, users can sidestep the issue [of mixing native 
   and Cygwin-based Tools and their different pathname conventions
   [not to mention line-ending cruft]] by adopting the following rules:
   When using gcc, use the Cygwin-supplied Python interpreter to
   run SCons, when using Microsoft Visual C/C++ (or some other 
   Windows compiler) use the or ActiveState version of 
   Python to run SCons.

There's more.

 - Dennis

> -----Original Message-----
> From: Patricia Shanahan []
> Sent: Friday, February 5, 2016 14:30
> To:
> Subject: Re: Thoughts on a new build system for AOO
> I thought most windows developers were more IDE orientated than command
> line, so we should be considering selecting an IDE for Windows builds,
> and as many others as possible, and putting together the project files
> for it.
> Parallelism is far, far lower priority than reliable unattended
> building. It is better to have to let it cook for a few hours without
> needing attention than to have to keep restarting things.
> On 2/5/2016 11:38 AM, Pedro Giffuni wrote:
> > Hi Damjan and others;
> >
> > Indeed a new build system is very desirable but it is difficult to
> > choose one. I agree that choosing one which we already have a need
> > for in dependencies is wise.
> >
> > FWIW, I looked into some of the options myself:
> >
> > - Google's Bazel looked very promising:
> >
> > But it lacks support for Windows at this time.
> >
> > - CMake has been chosen by LLVM, and by a bunch of projects that need
> > to be built cross platform. There was an aborted attempt for OOo:
> >
> > CMake, I understand, has been evolving a lot though.
> >
> > - FreeBSD and NetBSD share a powerful bsd make utility. FreeBSD
> > is still in the adoption process, and I can't say at this time
> > how it compares with gbuild:
> >
> >
> > I haven't looked at scons and I am not objecting to it. Certainly
> > anything is better than Dmake. My only comments, referring to
> > Python, are:
> >
> > - We have somewhat of a chicken and egg problem now with Python as
> > the build system is making it difficult to update our copy to
> > something like 2.7.11 that supports newer Windows compilers.
> >
> > - One thing I would like to see at some stage is the possibility of
> > using native windows tools like IronPython and Strawberry Perl
> > instead of the cygwin stuff.
> >
> > Pedro.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message