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 Sat, 06 Feb 2016 19:42:21 GMT
I think there are pathname parsing issues in MingW, although I don't think anything is as contorted
as with cygWin.  These usually arise because of the shell being used, that then leads them
to rewrite command lines when calling a native utility.  It seems that is the top of the slippery

Normally, I think one uses MSYS or MSYS2 (each of which tend to employ MingW) and at least
MSYS2 is more smoothly integrated with the Windows world, although there are some oddities.
 (One quirk: The Windows Environment will hold case-sensitive variables so that, e.g., setting
TEMP and temp can get you two entries -- MSYS and CygWin seem to exploit this in munging the
environment when their shell is fired up -- and it can completely derail a native tools, such
as cl.exe which do case-insensitive searches of the environment settings.  I thought of workarounds
for that but have not tested them.)

I have MingW64 installed and I will check around a little more.  Not immediately.  Have too
much work-in-progress and backlog today.

 -- Dennis

PS: The ability of Windows to run both x86 and x64 apps is a feature we tend to overlook.
 That applies somewhat to tools and how they can communicate, but there might be some limitations
I have not learned about.  I don't know how well the POSIX-alike shells handle all of that.

PPS: Picking an IDE doesn't get us where we want to be for Windows developers.  We need to
let devs pick their IDE.  The question is doing that in a way where the build system works
and IDE projects can also be used in development, not necessarily for production builds. 
Some of this depends on what is outside of source control but on the working developer system,
not unlike what happens now with configuring, etc., but perhaps better organized.
  I notice in the Bradley Nelson notes on GYP (I think) the observation that having makefile
projects in Visual Studio doesn't gain full advantage of the IDE.  Likewise, the git integration
into Visual Studio is not that clean, since VS is looking for VS Project files.  But it can
be taught to make one off-tree using on-repository source files.  I suspect Visual Code is
more ecumenical but haven't checked. 

> -----Original Message-----
> From: Damjan Jovanovic []
> Sent: Saturday, February 6, 2016 01:13
> To: Apache OO <>
> Subject: Re: Thoughts on a new build system for AOO
> I agree that an IDE is important - for development. Building the whole
> of
> AOO in an IDE seems impractical and awkward. Eclipse CDT already works
> well
> as an IDE on all platforms (
> and doesn't
> need
> any special project files generated; with memory limits increased, it
> can
> allegedly even open the entire project instead of just a module. CMake
> and
> SCons can both generate Visual Studio project files for those that
> prefer
> it (I don't know why though - Eclipse CDT was way better than Visual
> Studio
> for C++ development when last I checked).
> You are reading the SCons man page, you should read the user guide.
> GCC's
> and GNU make's man pages are also very long and complicated, yet people
> still use them ;-).
> Regarding SCons and MSVC under Cygwin, that is a good find. That problem
> would affect building the new version of Serf we need to upgrade to also
> then, since it uses SCons and we have to build it on Cygwin. No build
> system will be perfect - gbuild required a lot of development on top of
> make. What could we do about it? We already have a MingW build of AOO in
> SVN - does MingW suffer from the same pathname problem?
> Damjan
[ ... ]

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

View raw message