openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: Thoughts on a new build system for AOO
Date Fri, 05 Feb 2016 22:46:53 GMT
I think Marcus raises important points about capacity and how we could bootstrap through this.

Some musings:

There are also some related activities that need to follow in some manner, such as changing
deployment for Windows and probably for OSX too, both for similar reasons.  Getting into the
respective stores with authentic binaries is to be yearned for.

With regard to Pedro's comments about Python, there is no reason to use IronPython, which
is a .NET system, similarly with how Jython operate in and for Java. 

However, native (Windows) Python is now quite well integrated into Microsoft Visual Studio
and usable from Microsoft Visual Code (and used in its implementation).  Also, so long as
we are talking about command-line running and not any need for GUI libraries, using a stock
Python would preserve great cross-platform consistency.

Some folks kvetch that Python 3.x is still not widely used for this kind of purpose.  I don't
think that is something to worry about.

I would love for cygWin to disappear on Windows, most of all.  The clash of system models
is just too brittle and inscrutable.  

Finally: This is not a tiny effort.  There is exquisite need to work confined changes, confirmation,
and QA for a pro-longed, sustainable period.  I think it is critical that if the effort is
abandoned or goes dormant for any reason, the project survives in no worse shape.  There is
a serious "do no harm" imperative.

Having said that, and respecting the quality of the first-level analysis that Damjan has provided,
I am eager to know more on how this could be evolved toward.

 - Dennis


> -----Original Message-----
> From: Marcus []
> Sent: Friday, February 5, 2016 10:55
> To:
> Subject: Re: Thoughts on a new build system for AOO
> Am 02/05/2016 07:32 PM, schrieb Damjan Jovanovic:
[ ... ]
> > If people are happy, I'd suggest a migration plan where first scons is
> > added as a dependency, then the new version of serf is built with it
> (see
> > i126312), then gbuild modules are ported to scons until gbuild is
> > eliminated, then dmake modules are ported to scons until dmake is
> > eliminated, and finally scons replaces
> >
> > Thoughts?
> thanks for your analysis and suggestion.
> I'm not a developer in the traditional way. So, I don't know anything
> about build systems and I've to believe your points - especially about
> the dis-/advantages for gbuild and scons.
> To migrate the gbuild-using modules first is clever as it would be a
> nightmare to have a growing mix of dmake, gbuild and scons together.
> Eliminating the cygwin stuff on Windows could be another big advantage
> for developers on Windows.
> Last but not least the famous question about participation. If you would
> volunteer to start/do the migration then it would be great. But in
> parallel it could also become a life time task. ;-P.
> But, yes, using scons sounds a good idea and doing a test with some
> modules that are working with gbuild could be a good start.
> Marcus
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message