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 <p...@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-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
