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//prj/makefile.mk with a gbuild copy of that file
(which is the same in all gbuild modules), and if their gbuild
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
On Sat, Dec 2, 2017 at 10:42 AM, Peter Kovacs wrote:
> sounds great from what you write. Lets try SCons build system.
> Where can I find your changes so I can help? Have you checked them into
> trunk?
>
>
Please find a patch with my current SCons changes attached.
Currently
On 12/02/2017 03:05 AM, Damjan Jovanovic 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
On 2 Dec, Damjan Jovanovic wrote:
> * 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...
I figured out that problem and discovered that when using precompiled
headers with Visual
Hello all,
I am also nominating for chair in 2017.
Maybe some small Information about myself. I have joined the Apache
OpenOffice Project in Sept 2016 after in german Mainstream IT Newspage
an article has been printed that OpenOffice has not enough devs and may
close. I decided that this is
On Sunday, December 3, 2017, Don Lewis wrote:
> On 2 Dec, Damjan Jovanovic wrote:
> > On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski wrote:
> >
> >> Playing devils advocate, does it make sense to introduce
> >> Yet Another Build System at this stage?
> >>