openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kovacs <pe...@apache.org>
Subject Re: A more sane way to build - SCons, deCygwination and other hopes
Date Sat, 02 Dec 2017 08:42:37 GMT
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?

I have some expreience with python, which will come in handy.

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