Óscar Fuentes wrote:> Albert Graef <Dr.Graef at t-online.de> writes: >> Here are some points worth considering: >> http://www.remlab.net/op/cmake.shtml (Some of these may already be >> addressed in newer cmake versions, I haven't checked recently.) > > [...] > > Please, some LLVM release manager (Tanya?), read Albert's web page and > evaluate how much impact have the issues he raises on your work.Note that the URL I referred to is not mine. I merely wanted to point out that there are some possible issues to consider before throwing the existing build system out of the window. Which might affect LLVM users for whom the current build system works fine, like me. :) -- 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 <Dr.Graef at t-online.de> writes:> Note that the URL I referred to is not mine. I merely wanted to point > out that there are some possible issues to consider before throwing > the existing build system out of the window. Which might affect LLVM > users for whom the current build system works fine, like me. :)I'm not proposing throwing away the existing build system. My main intention is to provide a common build system to all VC++ users. As the tool employed supposedly brings support to other systems with no much more effort, I plan to extend my goal to cover all LLVM users. This build system can coexist with what we have now with no more problems than the current VC++ support produces. -- Oscar
Albert Graef wrote:> Óscar Fuentes wrote: > >> Albert Graef <Dr.Graef at t-online.de> writes: >> >>> Here are some points worth considering: >>> http://www.remlab.net/op/cmake.shtml (Some of these may already be >>> addressed in newer cmake versions, I haven't checked recently.) >>> >> [...] >> >> Please, some LLVM release manager (Tanya?), read Albert's web page and >> evaluate how much impact have the issues he raises on your work. >> > > Note that the URL I referred to is not mine. I merely wanted to point > out that there are some possible issues to consider before throwing the > existing build system out of the window. Which might affect LLVM users > for whom the current build system works fine, like me. :) >Especially where CMake is known *not* to work. (CMake 2.6.0 cannot be used to build itself on my configuration: it refuses to generate MinGW makefiles because bash is on my path as \bin\sh.exe, and generates broken MSYS files because it insists on using Cygwin filepaths rather than MingW32 filepaths.) I don't mind CMake as yet another configuration framework (especially if it brings up MSVC and other non-UNIXy targets), but tossing the autoconf framework (which does work, with very minor adjustments) will lock out native MingW32 builds. Kenneth
"Tanya M. Lattner" <tonic at nondot.org> writes:> I don't use the make dist/distcheck stuff when I do releases, so not > having that isn't a big deal to me right now.Okay.> I'm more concerned on impact to the test infrastructure (Dejagnu). Any > change to that has support all the features that we have currently and > not break the nightly tester. But that seems like a separate issue > from the build system stuff.. just happened to be brought up in the > same thread.That's my impression as well. Thanks, Tanya. -- Oscar
> Óscar Fuentes wrote: >> Albert Graef <Dr.Graef at t-online.de> writes: >>> Here are some points worth considering: >>> http://www.remlab.net/op/cmake.shtml (Some of these may already be >>> addressed in newer cmake versions, I haven't checked recently.) >> >> [...] >> >> Please, some LLVM release manager (Tanya?), read Albert's web page and >> evaluate how much impact have the issues he raises on your work.I don't use the make dist/distcheck stuff when I do releases, so not having that isn't a big deal to me right now. I'm more concerned on impact to the test infrastructure (Dejagnu). Any change to that has support all the features that we have currently and not break the nightly tester. But that seems like a separate issue from the build system stuff.. just happened to be brought up in the same thread. -Tanya> > Note that the URL I referred to is not mine. I merely wanted to point > out that there are some possible issues to consider before throwing the > existing build system out of the window. Which might affect LLVM users > for whom the current build system works fine, like me. :) > >