llvm dev - Jul 2008 - [LLVMdev] Is there room for another build system?

Ó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