[cfe-dev] [LLVMdev] RFC: Upcoming Build System Changes
daniel at zuster.org
Fri Oct 28 10:27:32 PDT 2011
On Fri, Oct 28, 2011 at 9:56 AM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> Reid Kleckner <reid.kleckner at gmail.com> writes:
>> While eliminating duplication is one of the goals I see in this build system
>> change, I think the more important ones are a) simplifying the build files
>> and b) making the build faster.
> The "build files" are the Makefiles, right? And Dan's proposal will not
> make the cmake build any faster. So those goals are orthogonal to the
> cmake build.
>> Adding CMake code (I agree it's a terrible scripting language) to parse
>> Makefiles will make the build slower and more complicated.
> Wrong! :-) Adding that feature is a few lines of code (orders of
> magnitude less than the system proposed by Dan) which are executed only
> at generation-time, i.e. when cmake has to regenerate the
> makefiles/project-files because a file was added/removed, etc. It adds
> nothing at build time and you will need a stopwatch to notice the
> difference at generation time.
This is not what Reid was talking about (as I understood him). He was
referring to what we would need to do if we wanted to keep the
existing Makefiles working, but centralize the information inside
>> I'm not really a stakeholder, but I agree with Chandler, it's worth
>> investigating simplifying LLVM's CMake files before making Yet Another build
>> system generator if you haven't already. That may not solve the problems
>> associated with the bad XCode project generation, though.
> You guys are mixing several things on the discussion. What Dan proposed
> makes no difference for Xcode. If it speeds up the Makefile-based build
> (something I doubt) that's good, but it is unnecessary for that system
> to fiddle with the cmake build as long as cmake can deal with the
> changes on its own.
> Keep in mind that, if Dan goes ahead his plans, tinkering on any build
> system would require knowledge of both of them plus the python
> scripts. That's adding complexity, quite a lot.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
More information about the cfe-dev