Óscar Fuentes wrote:> Some points you mention on your web page are solved.Which ones? (Just curious.)> Others are not applicable to LLVM.That might be the case now, but the lack of even basic functionality in some areas (in particular, no advanced feature checks, no make dist/distcheck, no make uninstall, lack of useful trace options when something goes wrong during a build, arcane user interface) might well become major roadblocks in the future. The broken mingw support (as pointed out by Stuart) would already be a major showstopper for me (and probably for many others who rely on mingw to ease the creation of native Windows ports). I do understand that you need a solution for MSVC where autoconf et al don't help much and cmake makes things much easier. But throwing out the current build system in favour of cmake is only a viable option if it works (at least) on all platforms supported by LLVM right now, as well as it does right now. That remains to be proven. Otherwise you just pass the buck from MSVC developers to everyone else. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
Albert Graef wrote:> The broken mingw support (as pointed out by Stuart) [...]s/Stuart/Kenneth/ Sorry. -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag
Albert Graef wrote:> Albert Graef wrote: > >> The broken mingw support (as pointed out by Stuart) [...] >> > > s/Stuart/Kenneth/ Sorry. >No problem. Just to be clear, I think bringing up the CMake build system for LLVM is a good idea. It should handle not only the various MSVC's going all the way back to MSVC 6.0, but presumably should cover at least some others, (OpenWatcom, and at least some of the Eclipse and CodeBlocks IDE configurations). CMake and autoconf cover glaring holes in each others' coverage; I'd like to see both build systems maintained in parallel. Incidentally, some versions of the autoconf system are also affected by the filepath convention confusion between Cygwin and MingW32. (E.g., the one generating GMP 4.2.2's makefile. But not LLVM's, or very recent versions of autoconf such the one used for MPFR 2.3.1; GCC 4.3.1's is also unaffected). CMake is designed to be fragile; autoconf is designed to be robust. The autoconf system actually gives me a GNU makefile that I often can repair even when it fails. This particular confusion is a routine fix (just eradicate the CYGPATH_W variable from the makefile). Maybe two extra minutes to work around. If *either* of the MSYS or MinGW CMake options could have been forced to give me a makefile, it is very plausible the makefile would have been routinely repairable. In that case I would have considered CMake usable for building CMake. But with a bad "is gcc working" test, and no clearly documented way to override this test: failure. The other critical design error was using full paths gratuitiously: /C/usr/bin/cmake.exe -E cmake_progress_report /C/MingWin.aux/cmake-2.6.0/Source/CMakeFiles/CMakeTmp/CMakeFiles 1 This would work fine on Cygwin, but (using bash as the command shell) the corresponding full-paths on MingW32 would be c:/usr/bin/cmake.exe -E cmake_progress_report c:/MingWin.aux/cmake-2.6.0/Source/CMakeFiles/CMakeTmp/CMakeFiles 1 I haven't taken a careful look at how to fix this. Kenneth
Albert Graef <Dr.Graef at t-online.de> writes:>> Some points you mention on your web page are solved. > > Which ones? (Just curious.)No cross-compilation. C99 compiler check missing: You can check the compiler support for a flag with just one line. pkg-config support broken. My understanding is that it is fixed.>> Others are not applicable to LLVM. > > That might be the case now,[snip] I'm mainly concerned with solving current problems, such as the VC++ build.> The broken mingw support (as pointed out by Stuart) would already be a > major showstopper for me (and probably for many others who rely on mingw > to ease the creation of native Windows ports).I plan to attack MinGW as soon as VC++ is finished. I found the sh/MSYS problems and think there are workarounds. Anyways, one of the main reasons for choosing CMake is that reportedly developers listen to their users and care about fixing bugs.> I do understand that you need a solution for MSVC where autoconf et al > don't help much and cmake makes things much easier. But throwing out the > current build system in favour of cmake is only a viable option if it > works (at least) on all platforms supported by LLVM right now, as well > as it does right now. That remains to be proven. Otherwise you just pass > the buck from MSVC developers to everyone else.As already mentioned several times, I don't pretend throwing out the current build. I want to improve things for VC++ and try to extend this improvements to the rest of users. You can be assured that your LLVM build will not fall apart overnight. I don't even have commit rights to the svn repository. -- Oscar
Óscar Fuentes wrote:> No cross-compilation. > > C99 compiler check missing: You can check the compiler support for a > flag with just one line. > > pkg-config support broken. My understanding is that it is fixed.Ok, thanks for clarifying. So I conclude that most of the complaints raised on Remi's page are still valid.> As already mentioned several times, I don't pretend throwing out the > current build.No, but you offered this as an option, and Chris said that the LLVM developers only want to support one build system and would be happy to get rid of autoconf et al, which is perfectly understandable. What I said is that cmake also has its shortcomings which need to be taken into consideration before taking such a step, that's all. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de WWW: http://www.musikinformatik.uni-mainz.de/ag