On Fri, Feb 5, 2016 at 9:38 PM, Pedro Giffuni <p...@apache.org> 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
