Re: A more sane way to build - SCons, deCygwination and other hopes

[Pe...@apache.org]

Hi all,

I am currently playing around with bazel. I like their concept and the 
tooling they provide. (I think i get a 32 bit Windows 8.1 sdk working too.)

It is probably for the bin, but it is fun to try. I hope at least to 
test out some concepts i have in mind.

Maybe Damjan can you share the current SCon Version?

Did you try to play with paralell builds? Because i learned now that 
python is not realy good at working in paralell.

Just wanted to say that i am currently doing something not coordinated...

all the best

peter


Am 06.12.2017 um 20:13 schrieb Damjan Jovanovic:
> On Sunday, December 3, 2017, Don Lewis <tr...@apache.org> wrote:
>
>> On  2 Dec, Damjan Jovanovic wrote:
>>> On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>
>>>> Playing devils advocate, does it make sense to introduce
>>>> Yet Another Build System at this stage?
>>>>
>>>>
>>> I anticipated this question.
>>>
>>> Firstly, we don't only have dmake and gbuild as our build systems. We
>> also
>>> use Ant, meta-build tools like build.pl and co, Microsoft's nmake for
>>> main/icu on Windows, and probably more. The existing number of tools
>>> doesn't negatively affect development, so why should 1 more?
>>>
>>> Secondly SCons can replace ./configure, so in all all-SCons world we
>> would
>>> eliminate 3 tools, not just 2.
>>>
>>> As for "sense . .. at this stage", we've hit several walls with gbuild at
>>> this stage:
>>> * It can't version libraries in the form of reg3.dll vs reg.so linking to
>>> reg.so.3 on *nix. Most of gbuild was written with the assumption
>> libraries
>>> on *nix always end with .so. Even when we dangerously weaken those
>>> assumptions, and badly hack it, it doesn't deliver the link...
>> Other than for the benefit of extensions, I don't see much point in
>> versioning the libraries because they are otherwise private.  If add
>> versioning so that it is more obvious that an old extension won't work
>> with a new version of AOO, are we disiplined enough to do the
>> appropriate version bumps?
>>
>>> * It already broke certain mixtures of build settings, eg. I think you
>>> can't both debug build and use precompiled headers on Windows, CFLAGS
>> gets
>>> lost somewhere...
>> That should be fixable, but ...
>>
>>> * 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?
>>
>>
> I am currently doing it by installing Python natively in Windows,
> installing SCons there through pip, and then calling that scons.bat from
> Cygwin.
>
> And, beyond my wildest expectations, SCons in this setup successfully
> compiled and linked a module, both inside Cygwin AND OUTSIDE IT!!! :) :)
>
>
>> And a more recent question near and dear to my heart, how easy is it to
>> do per-target optimization flag overrides?
>>
>>
> C[XX]FLAGS are specified to SCons like all other settings, as arrays of
> strings. You can specify common settings in the environment object and can
> add to those or replace them on individual SharedObjects.
>
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
> Damjan
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org