openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <dam...@apache.org>
Subject Re: Thoughts on a new build system for AOO
Date Sat, 06 Feb 2016 09:12:46 GMT
I agree that an IDE is important - for development. Building the whole of
AOO in an IDE seems impractical and awkward. Eclipse CDT already works well
as an IDE on all platforms (
https://wiki.openoffice.org/wiki/OpenOffice_and_Eclipse) and doesn't need
any special project files generated; with memory limits increased, it can
allegedly even open the entire project instead of just a module. CMake and
SCons can both generate Visual Studio project files for those that prefer
it (I don't know why though - Eclipse CDT was way better than Visual Studio
for C++ development when last I checked).

You are reading the SCons man page, you should read the user guide. GCC's
and GNU make's man pages are also very long and complicated, yet people
still use them ;-).

Regarding SCons and MSVC under Cygwin, that is a good find. That problem
would affect building the new version of Serf we need to upgrade to also
then, since it uses SCons and we have to build it on Cygwin. No build
system will be perfect - gbuild required a lot of development on top of GNU
make. What could we do about it? We already have a MingW build of AOO in
SVN - does MingW suffer from the same pathname problem?

Damjan

On Sat, Feb 6, 2016 at 8:04 AM, Dennis E. Hamilton <dennis.hamilton@acm.org>
wrote:

> 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 python.org or ActiveState version of
>    Python to run SCons.
>
> There's more.
>
>  - Dennis
>
>
>
> > -----Original Message-----
> > From: Patricia Shanahan [mailto:pats@acm.org]
> > Sent: Friday, February 5, 2016 14:30
> > To: dev@openoffice.apache.org
> > 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:
> > > http://bazel.io/
> > > 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:
> > > https://wiki.openoffice.org/wiki/OpenOffice_CMake_Integration
> > > 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:
> > > http://www.bsdcan.org/2014/schedule/events/460.en.html
> > >
> > > 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: 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message