Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 08 Dec 2017 10:53:08 +0100
From: Peter Kovacs <petko@apache.org>
To: dev@openoffice.apache.org
Cc: Damjan Jovanovic <damjan@apache.org>
Subject: Re: A more sane way to build - SCons, deCygwination and other hopes
Organization: Apache OpenOffice
In-Reply-To: <CAJm2B-=zEsezfYrDyAr+SQ9Wk-umg2vcHdfWRUhYSFQrD07EBQ@mail.gmail.com>
References: <CAJm2B-=Kv4yDzub5rVJCt8U0tr2vgPgbVfhZE19cP9RUJ8GBXQ@mail.gmail.com>
 <1512204157.993.12.camel@apache.org>
 <CAJm2B-=zEsezfYrDyAr+SQ9Wk-umg2vcHdfWRUhYSFQrD07EBQ@mail.gmail.com>
Message-ID: <ee3cb87afde6007ce520d31f360a1df6@posteo.de>
User-Agent: Posteo Webmail
archived-at: Fri, 08 Dec 2017 09:53:21 -0000

Hi Damjan,

Do you have any reason not to use the environment class [2]? I think it 
does the same as the Plattformclass you created.
On this overview ocument [1] you see in section 3.1 you see the 
architecture of Scons.
I think we should try to use as much preconfigs as possble and minimize 
customization as much as possible.

All the best
Peter

[1] http://scons.org/doc/production/PDF/scons-design.pdf
[2] 
http://scons.org/doc/production/HTML/scons-user.html#chap-environments

Am 07.12.2017 03:10 schrieb Damjan Jovanovic:
> On Sat, Dec 2, 2017 at 10:42 AM, Peter Kovacs <petko@apache.org>
> 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 only main/fileaccess builds, on Windows and FreeBSD, and
> doesn't even build completely as I haven't done the "ComponentTarget"
> yet. You run "scons" in main/ or "scons -u" in main/fileaccess. AOO
> has to already be built.
> 
>> I have some expreience with python, which will come in handy.
> 
> That's great to hear. Please let me know what you think about the
> structure, classes, should we use globals and soenv and SCon's
> Environment, etc. There is no easier time to make changes than at the
> beginning.
> 
> 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.
> 
>> Meanwhile I read Scons Documentation.
>> 
>> Am Samstag, den 02.12.2017, 10:05 +0200 schrieb Damjan Jovanovic:
>>> 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 [1],
>> LinkTarget.mk
>>> and
>>> platform/freebsd.mk [2] to SCons, as well as a module's local
>> gbuild
>>> files, I
>>> can now compile files and (badly) link them into libraries, and
>> clean
>>> the
>>> build.
>>> 
>>> SCons is an advanced next-generation build system like gbuild,
>> with
>>> high
>>> level declarative syntax in Python, support for multiple modules
>> that
>>> build
>>> in parallel, header dependencies, file change detection through
>> MD5
>>> sums of
>>> contents instead of timestamps so rebuilds are faster, etc. It
>> builds
>>> C,
>>> C++, Objective C, Java, Fortran, D, the sorely necessary Flex and
>>> Yacc that
>>> gbuild doesn't support. It supports tons of platforms and
>> compilers,
>>> including OS/2. It's maintainable and usable, can print debugging
>>> info such
>>> as dependency trees, and is generally pleasant to work with.
>> We've
>>> discussed it before on this list, but I never got to trying it
>> until
>>> now.
>>> 
>>> Virtually everything gbuild does, is already done by SCons, and
>> often
>>> done
>>> much better. The syntax for SCons files is similar/related to
>>> gbuild's
>>> syntax, so an automated conversion from gbuild to SCons might
>> even be
>>> possible.
>>> 
>>> So far, I have defines, includes and C[XX]FLAGS working. I've
>>> structured it
>>> a bit better, with platform-specific files in classes that only
>>> provide
>>> variables to slot in higher up, instead of one giant set of
>> globally
>>> mutable global variables like in gbuild. Linking still needs a
>> bit of
>>> work.
>>> Windows is next on the list, as Cygwin will be the ultimate test
>> of
>>> whether
>>> we can use it.
>>> 
>>> I am very hopeful. SCons has a long history and is used by other
>>> projects,
>>> while only OO.o derivatives use gbuild. It's well documented. It
>>> supports
>>> features we need which gbuild doesn't, like library version names
>> and
>>> flex/yacc. It's supposed to work on Windows, both inside and
>> outside
>>> of
>>> Cygwin and could help us build without Cygwin some day. It
>> supports
>>> many
>>> versions of Visual Studio and could help us in upgrading to a new
>>> one. We
>>> will need to add custom builders to SCons for our custom file
>> formats
>>> like
>>> IDL, but it's just Python, not my favorite language but
>> infinitely
>>> better
>>> than GNU make.
>>> 
>>> It would help if someone could review my changes, as I am not
>> very
>>> familiar
>>> with Python and there might be better ways to write some of the
>> code.
>>> I'll
>>> post a patch for review after some further development.
>>> 
>>> Thank you
>>> Damjan
>> 
>> 
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
> 
> 
> 
> Links:
> ------
> [1] http://gbuild.mk
> [2] http://freebsd.mk
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org

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