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 04:03:54 GMT
Globally, removing SCons should only entail:
rm -rf site_scons SConstruct */SConscript

Modules that get ported from gbuild to SCons would also require replacement
of their main/<module>/prj/makefile.mk with a gbuild copy of that file
(which is the same in all gbuild modules), and if their gbuild makefiles
were deleted, they need to be restored.

Modules that get ported from dmake to SCons have extensive precompiled
header changes and symbol visibility changes in source code
(SAL_DLLPUBLIC_EXPORT), so "svn revert" is probably the only option for
them.

Be more optimistic though. SCons works better than expected. And I've even
made a preliminary parser/converter for gbuild's module makefiles, that can
convert them into SCons build files, so a fast accurate automated
conversion might be possible 😉, as least for some modules.

On Thu, Dec 7, 2017 at 5:32 AM, Patricia Shanahan <pats@acm.org> wrote:

> If it turns out to only make things even more complicated, adding yet
> another build tool, how hard would it be to remove it from trunk?
>
> On 12/6/2017 6:10 PM, Damjan Jovanovic wrote:
> ...
>
>> 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.
>>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message