Re: Thoughts on a new build system for AOO

[Damjan Jovanovic]

On Fri, Feb 5, 2016 at 9:38 PM, Pedro Giffuni  wrote:

> Hi Damjan and others;
>
> Indeed a new build system is very desirable but it is difficult to
> choose one. I agree that choosing one which we already have a need
> for in dependencies is wise.
>
> FWIW, I looked into some of the options myself:
>
> - Google's Bazel looked very promising:
> http://bazel.io/
> But it lacks support for Windows at this time.
>
>
It does look promising. All these next-generation build systems are
similar. Bazel, SCons and gbuild are all based on the idea of globally
visible dependencies between individual files. Bazel and SCons both use MD5
sums instead of timestamps to detect changes, and can do heavy caching
(like ccache for C/C++, but for all files). However the lack of Windows
support for Bazel is a showstopper.


> - CMake has been chosen by LLVM, and by a bunch of projects that need
> to be built cross platform. There was an aborted attempt for OOo:
> https://wiki.openoffice.org/wiki/OpenOffice_CMake_Integration
> CMake, I understand, has been evolving a lot though.
>
>
CMake could be useful because it can cross-compile, but it implements
building by delegating to native tools on each platform, such as GNU make
on *nix, so it still suffers from the recursive make problem, and always
will (
https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F).
The recursive make problem is the reason we have unstable builds and poor
parallelization. They say their Ninja backend doesn't suffer from it though.

Also guess what gbuild's horrible syntax is based on? CMake's syntax! CMake
is slightly easier to read though.


> - FreeBSD and NetBSD share a powerful bsd make utility. FreeBSD
> is still in the adoption process, and I can't say at this time
> how it compares with gbuild:
> http://www.bsdcan.org/2014/schedule/events/460.en.html
>
>
AFAIK all make utilities suffer from the recursive make problem, the only
way gbuild didn't is by using the eval feature in GNU make, and it still
left a lot to be desired.


> I haven't looked at scons and I am not objecting to it. Certainly
> anything is better than Dmake. My only comments, referring to
> Python, are:
>
> - We have somewhat of a chicken and egg problem now with Python as
> the build system is making it difficult to update our copy to
> something like 2.7.11 that supports newer Windows compilers.
>
>
Please elaborate.


> - One thing I would like to see at some stage is the possibility of
> using native windows tools like IronPython and Strawberry Perl
> instead of the cygwin stuff.
>
> Pedro.
>
>
Damjan

Re: Building on Windows

[Regina Henschel]

Hi Patricia,

Patricia Shanahan schrieb:

My build finished!

The next problem is to run it. I have hit two problems, one minor. The
minor problem is that
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7
has incorrect paths using "OpenOffice" rather than "Apache_OpenOffice".

The more serious problem is that there does not seem to be a zip file
for running without actually installing.


You are right, there is only the folder en-US (or your preferred 
language) in instset-native/wntmsci12/Apache_OpenOffice. You can use the 
setup or the msi-file to make an administrative installation.


When you have got the installation, then when you made changes, then it 
is enough to drop those files from solver/420/wntmsci12/bin into your 
installation, which have changed. Most times that are only a few dlls.


LibreOffice generates a folder with an immediately executable 
soffice.exe. So there might exist a configure switch for that in Apache 
OpenOffice too, but I don't know.


Kind regards
Regina






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

Re: Building on Windows

[Damjan Jovanovic]

On Fri, Feb 5, 2016 at 4:52 PM, Regina Henschel 
wrote:

> Hi Patricia,
>
> Patricia Shanahan schrieb:
>
>> My build finished!
>>
>> The next problem is to run it. I have hit two problems, one minor. The
>> minor problem is that
>>
>> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7
>> has incorrect paths using "OpenOffice" rather than "Apache_OpenOffice".
>>
>> The more serious problem is that there does not seem to be a zip file
>> for running without actually installing.
>>
>
> You are right, there is only the folder en-US (or your preferred language)
> in instset-native/wntmsci12/Apache_OpenOffice. You can use the setup or the
> msi-file to make an administrative installation.
>
> When you have got the installation, then when you made changes, then it is
> enough to drop those files from solver/420/wntmsci12/bin into your
> installation, which have changed. Most times that are only a few dlls.
>
> LibreOffice generates a folder with an immediately executable soffice.exe.
> So there might exist a configure switch for that in Apache OpenOffice too,
> but I don't know.
>
>
If you mean --with-package-format="installed" to ./configure (IIRC the
default is archive, but you can --with-package-format="archive installed"
to get both) then yes we do have it.


> Kind regards
> Regina
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Thoughts on a new build system for AOO

[Marcus]

Am 02/05/2016 07:32 PM, schrieb Damjan Jovanovic:

Hi

With the recent buildbot saga and Patricia's Windows building nightmare, a
number of serious issues were highlighted which got me thinking about how
our build system could be improved.

The problems with building AOO were researched and documented years ago (
https://wiki.openoffice.org/wiki/Build_Environment_Effort) and a very good
analysis was done in https://wiki.openoffice.org/wiki/Build_System_Analysis
which is worth a read.

Their solution was gbuild: a build system using GNU make's new "eval"
feature to rewrite the makefile from within, which would generate one giant
dependency graph of every file in AOO and produce reliable, stable,
deterministic, and maximally parallelized builds, with minimal rebuilding
on changes. The problem is, the full benefits of gbuild can only be seen
once every module is converted to gbuild, and with only about 10% having
been converted so far, it doesn't even try to build a complete project-wide
dependency graph, but rather gets invoked per-module just like dmake.
Converting dmake modules to gbuild is very difficult: so far I only managed
to convert main/formula, but main/animations was mysteriously segfaulting
AOO...

Besides, LO has completed converting every module to gbuild, guinea pigging
gbuild perfectly for us ;-). How has it gone for them? One of our
committers, jani, evaluated LO's gbuild in April 2013 in a thread here
called "Make x Dmake x Build", where he said how it's "not particulary fast
either", and called mkdir 431 times on a directory that already existed.
And worst of all, gbuild uses its own language with horrible syntax (eg.
LISP-like syntax, spaces around commas not allowed, blank lines sometimes
mandatory and at other times forbidden), is almost completely undocumented,
and very difficult to debug - a maintenance nightmare.

So what other alternatives are there?

There was a comment in
https://wiki.openoffice.org/wiki/Build_Environment_Effort/New_Build_System_Requirements
that got my attention:

"One might consider using Python as a tool for _all_ non-standard build
tasks. Python is easy to distribute and install on all platforms. However,
it is also a very fat dependency and thus it is questionable, if it would
be worth the effort just to get rid of cygwin (or another Unix environment
on windows)."

We already build and use Python, and there is a good build system written
in Python: SCons (http://www.scons.org). It's modern yet well established,
having started in the year 2000, and is used by a number of open source and
commercial projects. It's MIT licensed so we can include it as a
dependency. The build scripts are simple Python scripts and can use the
Python language and libraries, though you don't need to know (much) Python
to use it. It's well documented. It's debuggable and has options to print
dependencies and explain actions taken. It supports all the operating
systems and architectures we support (even unofficially), including Cygwin,
*BSD, Solaris, OS/2. It's "local" package is designed for easy embedding
into a pre-existing project so it runs straight after extraction with no
need to install it system-wide, and is only 445 kB.

It has many features we need or would benefit from:
* It's able to parse included headers from C/C++ files and use them as
dependencies.
* It can generate Visual Studio project files.
* Supports many languages including C, C++, D, Java, Fortran, Yacc, Lex.
* Builds zip and tar archives.
* Just like gbuild, it has a global dependency view and can fully
parallelize building files across module boundaries while maintaining
stability.
* Using Python APIs instead of *nix CLI tools might eventually result in us
being able to ditch Cygwin entirely, not to mention better performance due
to less subprocess spawning.
* Unlike classical make tools which only use mtimes, it determines what to
rebuild using several configurable options, including MD5 checksums of file
contents, meaning changes which don't result in different binaries (eg.
formatting or comment changes) will only recompile changed files and stop
there, because it knows the object files are the same as before, so no
linking or downstream rebuilding needs to be performed.

In other words SCons does most of what gbuild is supposed to be good for,
and more. I see it outperforming LO's pure gbuild, while being more
readable, maintainable, debuggable, and a sight for sore eyes after the
triple whammy of dmake, gbuild and build.pl we've endured for so long.

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 build.pl.

Thoughts?


thanks for your analysis and suggestion.

I'm not a developer in the traditional way. So, I don't know anything 
about 

Thoughts on a new build system for AOO

[Damjan Jovanovic]

Hi

With the recent buildbot saga and Patricia's Windows building nightmare, a
number of serious issues were highlighted which got me thinking about how
our build system could be improved.

The problems with building AOO were researched and documented years ago (
https://wiki.openoffice.org/wiki/Build_Environment_Effort) and a very good
analysis was done in https://wiki.openoffice.org/wiki/Build_System_Analysis
which is worth a read.

Their solution was gbuild: a build system using GNU make's new "eval"
feature to rewrite the makefile from within, which would generate one giant
dependency graph of every file in AOO and produce reliable, stable,
deterministic, and maximally parallelized builds, with minimal rebuilding
on changes. The problem is, the full benefits of gbuild can only be seen
once every module is converted to gbuild, and with only about 10% having
been converted so far, it doesn't even try to build a complete project-wide
dependency graph, but rather gets invoked per-module just like dmake.
Converting dmake modules to gbuild is very difficult: so far I only managed
to convert main/formula, but main/animations was mysteriously segfaulting
AOO...

Besides, LO has completed converting every module to gbuild, guinea pigging
gbuild perfectly for us ;-). How has it gone for them? One of our
committers, jani, evaluated LO's gbuild in April 2013 in a thread here
called "Make x Dmake x Build", where he said how it's "not particulary fast
either", and called mkdir 431 times on a directory that already existed.
And worst of all, gbuild uses its own language with horrible syntax (eg.
LISP-like syntax, spaces around commas not allowed, blank lines sometimes
mandatory and at other times forbidden), is almost completely undocumented,
and very difficult to debug - a maintenance nightmare.

So what other alternatives are there?

There was a comment in
https://wiki.openoffice.org/wiki/Build_Environment_Effort/New_Build_System_Requirements
that got my attention:

"One might consider using Python as a tool for _all_ non-standard build
tasks. Python is easy to distribute and install on all platforms. However,
it is also a very fat dependency and thus it is questionable, if it would
be worth the effort just to get rid of cygwin (or another Unix environment
on windows)."

We already build and use Python, and there is a good build system written
in Python: SCons (http://www.scons.org). It's modern yet well established,
having started in the year 2000, and is used by a number of open source and
commercial projects. It's MIT licensed so we can include it as a
dependency. The build scripts are simple Python scripts and can use the
Python language and libraries, though you don't need to know (much) Python
to use it. It's well documented. It's debuggable and has options to print
dependencies and explain actions taken. It supports all the operating
systems and architectures we support (even unofficially), including Cygwin,
*BSD, Solaris, OS/2. It's "local" package is designed for easy embedding
into a pre-existing project so it runs straight after extraction with no
need to install it system-wide, and is only 445 kB.

It has many features we need or would benefit from:
* It's able to parse included headers from C/C++ files and use them as
dependencies.
* It can generate Visual Studio project files.
* Supports many languages including C, C++, D, Java, Fortran, Yacc, Lex.
* Builds zip and tar archives.
* Just like gbuild, it has a global dependency view and can fully
parallelize building files across module boundaries while maintaining
stability.
* Using Python APIs instead of *nix CLI tools might eventually result in us
being able to ditch Cygwin entirely, not to mention better performance due
to less subprocess spawning.
* Unlike classical make tools which only use mtimes, it determines what to
rebuild using several configurable options, including MD5 checksums of file
contents, meaning changes which don't result in different binaries (eg.
formatting or comment changes) will only recompile changed files and stop
there, because it knows the object files are the same as before, so no
linking or downstream rebuilding needs to be performed.

In other words SCons does most of what gbuild is supposed to be good for,
and more. I see it outperforming LO's pure gbuild, while being more
readable, maintainable, debuggable, and a sight for sore eyes after the
triple whammy of dmake, gbuild and build.pl we've endured for so long.

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 build.pl.

Thoughts?

Damjan

Re: Thoughts on a new build system for AOO

[Patricia Shanahan]

I thought most windows developers were more IDE orientated than command 
line, so we should be considering selecting an IDE for Windows builds, 
and as many others as possible, and putting together the project files 
for it.


Parallelism is far, far lower priority than reliable unattended 
building. It is better to have to let it cook for a few hours without 
needing attention than to have to keep restarting things.


On 2/5/2016 11:38 AM, Pedro Giffuni wrote:

Hi Damjan and others;

Indeed a new build system is very desirable but it is difficult to
choose one. I agree that choosing one which we already have a need
for in dependencies is wise.

FWIW, I looked into some of the options myself:

- Google's Bazel looked very promising:
http://bazel.io/
But it lacks support for Windows at this time.

- CMake has been chosen by LLVM, and by a bunch of projects that need
to be built cross platform. There was an aborted attempt for OOo:
https://wiki.openoffice.org/wiki/OpenOffice_CMake_Integration
CMake, I understand, has been evolving a lot though.

- FreeBSD and NetBSD share a powerful bsd make utility. FreeBSD
is still in the adoption process, and I can't say at this time
how it compares with gbuild:
http://www.bsdcan.org/2014/schedule/events/460.en.html

I haven't looked at scons and I am not objecting to it. Certainly
anything is better than Dmake. My only comments, referring to
Python, are:

- We have somewhat of a chicken and egg problem now with Python as
the build system is making it difficult to update our copy to
something like 2.7.11 that supports newer Windows compilers.

- One thing I would like to see at some stage is the possibility of
using native windows tools like IronPython and Strawberry Perl
instead of the cygwin stuff.

Pedro.



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



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

RE: Thoughts on a new build system for AOO

[Dennis E. Hamilton]

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 [mailto:marcus.m...@wtnet.de]
> Sent: Friday, February 5, 2016 10:55
> To: dev@openoffice.apache.org
> 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 build.pl.
> >
> > 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: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


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

FW: [ApacheCon NA] Client Track

[Dennis E. Hamilton]

It is interesting how Cordova and Flex are different, but are concerned with 
client-facing technologies.

Apache OpenOffice is probably the most heavily-client project that the ASF has, 
and Corinthia, had it endured, would be somewhere between these two kinds of 
client worlds.

I can imagine an AOO-related contribution to a client-side track at ApacheCon 
NA.  For example, one could address the challenges of the changing faces of 
platforms and cloud-supported apps, for example, perhaps even a panel 
discussion.

There is always the question of how AOO could pivot to this new world of 
ecosystems, app stores, and distributed operation.  It raises the question of 
whether and how it should provide tooling and reference implementations but not 
deliver integrated solutions, leaving that to downstream consumers, while 
sustaining the desktop-exclusive client pretty much as it is, working from 
standard file formats.

ApacheCon NA (North Americal) is in Vancouver, British Columbia, Canada, on May 
11-13, 2016.

The instructions for submitting talk proposals are at 
.

The deadline for initial proposals is in one week, Friday, February 12.

If a panel discussion format were proposed, all of the panelists need to be 
identified in the proposal.

 - Dennis

> -Original Message-
> From: Alex Harui [mailto:aha...@adobe.com]
> Sent: Friday, February 5, 2016 09:24
> To: d...@community.apache.org
> Subject: [ApacheCon NA] Client Track
> 
> Hi,
> 
> What is the appropriate list for discussing possible tracks for
> ApacheCon?
> 
> Some Apache projects, like Flex and Cordova, are more oriented to
> clients,
> applications and front-ends than server-side, backend code.  For this
> year's ApacheCon in Vancouver, Flex and Cordova want to propose a track
> for client-oriented talks.  Are other projects interested?  If so,
> please
> propose a talk for
> the client track and let us know to look for it.
> 
> Thanks,
> -Alex
> Apache Flex
> 
> 
> 



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

Re: Building on Windows

[Patricia Shanahan]

My build finished!

The next problem is to run it. I have hit two problems, one minor. The 
minor problem is that 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7 
has incorrect paths using "OpenOffice" rather than "Apache_OpenOffice".


The more serious problem is that there does not seem to be a zip file 
for running without actually installing.


Patricia

The last few messages were:

**
... creating download installation set ...
**
Redundant argument in sprintf at 
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at 
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at 
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at 
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at 
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at 
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at 
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
... created NSIS file 
C:/OpenOfficeDev/Trunk/main/instsetoo_native/wntmsci12.pro/Apache_OpenOffice_SDK/msi/nsis/en-US/downloadtemplate.nsi 
...

... starting C:/PROGRA~2/NSIS/makensis.exe ...
... checking log file 
C:/OpenOfficeDev/Trunk/main/instsetoo_native/wntmsci12.pro/Apache_OpenOffice_SDK/msi/logging/en-US/log_AOO420_en-US.log


***
Successful packaging process!
***
copying log file to 
C:/OpenOfficeDev/Trunk/main/instsetoo_native/wntmsci12.pro/Apache_OpenOffice_SDK/msi/install/log/log_AOO420_en-US.log

stopping log at Fri Feb  5 04:53:25 2016

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

Re: Thoughts on a new build system for AOO

[Pedro Giffuni]

Hi Patricia .. good point about IDE's.

We have a dilemma here:

On one side ~80% of our users are Windows-based so it would certainly
be ideal to use an environment where we keep both our users and our
developers in sync. Unfortunately the majority of our developers are
not Windows based so ideally we should have an environment that people
on Mac and UNIX find acceptable.

We *could* opt for a dual build system: one with the native Windows and 
another for UNIX and then as anyone adds a library, for example, he/she

would have to deal with both build systems,

This said, having a multiplatform build doesn't mean we will lose the 
GIDE on Win/Mac: major IDEs for Apple and Microsoft indeed accommodate 
for external build systems, and still you can use completion and static 
analysis.


About the parallel build: one of the complaints many people have
(raises hand) is the long time required to do builds, there is also
a sad reality of the buildbots that still have concurrency issues
in the current build system. I agree it's not the most important issue
in the build system but if we can solve it, we really should.

I will not object to any new system as long as it builds on my
platform (FreeBSD).

What I am expecting, and what other projects do AFAICT. is to go for
a multiplatform build system: Clang is having huge success with CMake.
Eventually we could move to clang for Windows builds as well.

FWIW, Jan Iversen had also considered a similar approach to yours and
did some work with some students:

http://svn.apache.org/viewvc/openoffice/branches/capstone2013/

I haven't looked at it, but the spent several months on it so it
is probably worth looking into.

Pedro.

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

RE: Thoughts on a new build system for AOO

[Dennis E. Hamilton]

Hmm, have to think about the IDE question.  I'm a yes and no about that.  IDEs 
should be usable.  I'm not so clear that one should be essential to do a plain 
build of the product from source.

I prefer command-line builds on Windows, although I use IDEs to edit and to do 
local builds of things that can be built (for error checking) and, if possible, 
that have small testable components.  Not exactly my picture of the AOO scheme, 
so, philosophically, perhaps inappropriate here despite my druthers.  

My basic motivation for providing command-line builds is that someone be able 
to repeat a build from source with the least-possible requirements for tools, 
with as few needed to be installed as possible and all freely-available if not 
already provided.  In my world, one of the least-possible requirements is 
cmd.exe [;<).

So, I think I am atypical and will recuse myself here.

Meanwhile ...

I dug into SCons a bit.  I am not certain that a build system with a 184-page 
PDF manual is a winner, and it has enough options to scare everybody.  On 
p.176, there is a wonderfully terse section on "Windows: Cygwin Tools and 
Cygwin Python vs. Windows Pythons."  Here is the gem therein.

   In practice, users can sidestep the issue [of mixing native 
   and Cygwin-based Tools and their different pathname conventions
   [not to mention line-ending cruft]] by adopting the following rules:
   When using gcc, use the Cygwin-supplied Python interpreter to
   run SCons, when using Microsoft Visual C/C++ (or some other 
   Windows compiler) use the python.org or ActiveState version of 
   Python to run SCons.

There's more.

 - Dennis



> -Original Message-
> From: Patricia Shanahan [mailto:p...@acm.org]
> Sent: Friday, February 5, 2016 14:30
> To: dev@openoffice.apache.org
> Subject: Re: Thoughts on a new build system for AOO
> 
> I thought most windows developers were more IDE orientated than command
> line, so we should be considering selecting an IDE for Windows builds,
> and as many others as possible, and putting together the project files
> for it.
> 
> Parallelism is far, far lower priority than reliable unattended
> building. It is better to have to let it cook for a few hours without
> needing attention than to have to keep restarting things.
> 
> On 2/5/2016 11:38 AM, Pedro Giffuni wrote:
> > Hi Damjan and others;
> >
> > Indeed a new build system is very desirable but it is difficult to
> > choose one. I agree that choosing one which we already have a need
> > for in dependencies is wise.
> >
> > FWIW, I looked into some of the options myself:
> >
> > - Google's Bazel looked very promising:
> > http://bazel.io/
> > But it lacks support for Windows at this time.
> >
> > - CMake has been chosen by LLVM, and by a bunch of projects that need
> > to be built cross platform. There was an aborted attempt for OOo:
> > https://wiki.openoffice.org/wiki/OpenOffice_CMake_Integration
> > CMake, I understand, has been evolving a lot though.
> >
> > - FreeBSD and NetBSD share a powerful bsd make utility. FreeBSD
> > is still in the adoption process, and I can't say at this time
> > how it compares with gbuild:
> > http://www.bsdcan.org/2014/schedule/events/460.en.html
> >
> > I haven't looked at scons and I am not objecting to it. Certainly
> > anything is better than Dmake. My only comments, referring to
> > Python, are:
> >
> > - We have somewhat of a chicken and egg problem now with Python as
> > the build system is making it difficult to update our copy to
> > something like 2.7.11 that supports newer Windows compilers.
> >
> > - One thing I would like to see at some stage is the possibility of
> > using native windows tools like IronPython and Strawberry Perl
> > instead of the cygwin stuff.
> >
> > Pedro.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


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