Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
From: Jim Jagielski <jim@jaguNET.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: A more sane way to build - SCons, deCygwination and other hopes
Date: Sat, 2 Dec 2017 09:19:08 -0500
References: <CAJm2B-=Kv4yDzub5rVJCt8U0tr2vgPgbVfhZE19cP9RUJ8GBXQ@mail.gmail.com>
To: dev@openoffice.apache.org
In-Reply-To: <CAJm2B-=Kv4yDzub5rVJCt8U0tr2vgPgbVfhZE19cP9RUJ8GBXQ@mail.gmail.com>
Message-Id: <C07C9CB9-DAE1-48B6-975D-990A3B8C3881@jaguNET.com>
archived-at: Sat, 02 Dec 2017 14:19:21 -0000

Playing devils advocate, does it make sense to introduce
Yet Another Build System at this stage?

Also, there are a few projects that I know of that
use SCons. In general, one of the most popular common
threads related to them are "Why the hell are you using SCons?" :)

> On Dec 2, 2017, at 3:05 AM, Damjan Jovanovic <damjan@apache.org> wrote:
> 
> 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