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 slope.
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 [mailto:dam...@apache.org] > Sent: Saturday, February 6, 2016 01:13 > To: Apache OO <dev@openoffice.apache.org> > 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 ( > https://wiki.openoffice.org/wiki/OpenOffice_and_Eclipse) 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 > GNU > 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: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
