openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <dam...@apache.org>
Subject Re: A more sane way to build - SCons, deCygwination and other hopes
Date Thu, 07 Dec 2017 02:10:12 GMT
On Sat, Dec 2, 2017 at 10:42 AM, Peter Kovacs <petko@apache.org> wrote:

> sounds great from what you write. Lets try SCons build system.
> Where can I find your changes so I can help? Have you checked them into
> trunk?
>
>
Please find a patch with my current SCons changes attached.

Currently only main/fileaccess builds, on Windows and FreeBSD, and doesn't
even build completely as I haven't done the "ComponentTarget" yet. You run
"scons" in main/ or "scons -u" in main/fileaccess. AOO has to already be
built.



> I have some expreience with python, which will come in handy.
>
>
That's great to hear. Please let me know what you think about the
structure, classes, should we use globals and soenv and SCon's Environment,
etc. There is no easier time to make changes than at the beginning.

Should we make a separate branch for SCons or develop in trunk? It doesn't
alter any existing files so it shouldn't interfere with our existing build.


> Meanwhile I read Scons Documentation.
>
> Am Samstag, den 02.12.2017, 10:05 +0200 schrieb Damjan Jovanovic:
> > Hi
> >
> > After days of failing to add a few new simple features to gbuild,
> > I've now
> > reached my limits, and have begun experimenting with the SCons build
> > system
> > instead.
> >
> > It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk
> > and
> > platform/freebsd.mk to SCons, as well as a module's local gbuild
> > files, I
> > can now compile files and (badly) link them into libraries, and clean
> > the
> > build.
> >
> > SCons is an advanced next-generation build system like gbuild, with
> > high
> > level declarative syntax in Python, support for multiple modules that
> > build
> > in parallel, header dependencies, file change detection through MD5
> > sums of
> > contents instead of timestamps so rebuilds are faster, etc. It builds
> > C,
> > C++, Objective C, Java, Fortran, D, the sorely necessary Flex and
> > Yacc that
> > gbuild doesn't support. It supports tons of platforms and compilers,
> > including OS/2. It's maintainable and usable, can print debugging
> > info such
> > as dependency trees, and is generally pleasant to work with. We've
> > discussed it before on this list, but I never got to trying it until
> > now.
> >
> > Virtually everything gbuild does, is already done by SCons, and often
> > done
> > much better. The syntax for SCons files is similar/related to
> > gbuild's
> > syntax, so an automated conversion from gbuild to SCons might even be
> > possible.
> >
> > So far, I have defines, includes and C[XX]FLAGS working. I've
> > structured it
> > a bit better, with platform-specific files in classes that only
> > provide
> > variables to slot in higher up, instead of one giant set of globally
> > mutable global variables like in gbuild. Linking still needs a bit of
> > work.
> > Windows is next on the list, as Cygwin will be the ultimate test of
> > whether
> > we can use it.
> >
> > I am very hopeful. SCons has a long history and is used by other
> > projects,
> > while only OO.o derivatives use gbuild. It's well documented. It
> > supports
> > features we need which gbuild doesn't, like library version names and
> > flex/yacc. It's supposed to work on Windows, both inside and outside
> > of
> > Cygwin and could help us build without Cygwin some day. It supports
> > many
> > versions of Visual Studio and could help us in upgrading to a new
> > one. We
> > will need to add custom builders to SCons for our custom file formats
> > like
> > IDL, but it's just Python, not my favorite language but infinitely
> > better
> > than GNU make.
> >
> > It would help if someone could review my changes, as I am not very
> > familiar
> > with Python and there might be better ways to write some of the code.
> > I'll
> > post a patch for review after some further development.
> >
> > Thank you
> > Damjan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Mime
View raw message