openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kovacs <>
Subject Re: A more sane way to build - SCons, deCygwination and other hopes
Date Sun, 03 Dec 2017 10:04:38 GMT

On 03.12.2017 01:57, Don Lewis wrote:
> On  2 Dec, Damjan Jovanovic wrote:
>> * Nobody knows gbuild. The syntax is atrocious. It uses obscure features of
>> GNU make. We can't debug it. It takes days of work to investigate/fix any
>> problem with it, work that could be better spent on a this vast project
>> with few development resources.
> Agreed 1000% here.
> If you are doing a build with bundled python, how do you bootstrap?  If
> you are on Windows and don't have python, how do you run the SCons
> equivalent of configure and then use SCons to build python?
Today you need perl. So we replace one language with another.
I think the benefit is that Scons is a generic Buildsystem that is 
maintained by a team.
So creating a valid build environment may be much simpler then the 
version we have today.
But this depends how we use the tool.

Configure and bootstrap is up to us. We could stick with the current 
process. (Replace only the build command)
We could include the current process within Scons. Or we could integrate 
both into Scons using Scons provided tools.
While I am not sure how to do the last step.
What I have seen if we integrate it into Scon, we can define our own 
Flags to control the behaviour. (Switch Bootstrap on, or not)
> And a more recent question near and dear to my heart, how easy is it to
> do per-target optimization flag overrides?
Scons thinks in build Environments, which are Enviroment Objects. Each 
Environment contains build flags.

An Enviroment could Fetch Values from another enviroment, but we can 
also expand values, replace values or clone them. There are also ways to 
AppendĀ  and to Prepend values (with the option do do this unique).
An Environment can be created having default values.
We can define Issue handling on environment level. If we know 
combinations do not work or something is missing.

We can also define multiple Enviroments. However a build config can only 
be associated with one build environment.

I hope this gives an Idea what posilities we have with Scons. How we 
design our build process is up to us.
I would think that we have one global environment that feeds from 
Templates like Debug and release. Each Module has then a specific own 
Environment which feeds from the global ones.


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

View raw message