Chris Lattner <clattner at apple.com> writes:> Forgive me, but I've lost track of how any of this has to do with > Daniel's proposal. Recursive make vs not, make vs cmake all don't > actually matter to his proposal.One of the problems with Daniel's proposal is that besides addressing the duplicity issue, it has no applications to back it up. The things mentioned so far are either extremely vague, or offer dubious gains (i.e. removing recursivity from the Makefiles) or trivially done without his system (i.e. walking the source files, etc.) So when it is explained that the duplicity can be addressed without his system, those other hypothetical advantages are mentioned and then the discussion inevitably drifts.> His proposal is basically "cmake isn't going to replace make any time > soon. We'd like to improve the make system (e.g. by eliminating > autoconf) and the first step is to factor redundancy that exists > between cmake and make".Does that make sense at all? How is autoconf related with duplicity in cmake? If he thinks that cmake and autoconf platform tests are duplicated, he will be disappointed when he discovers that cmake depends on those tests not only for configuring the LLVM headers, but for doing lots of stuff. Re-implementing autoconf is a daunting task (if that's what he wants to do). Shifting to his system all the decisions that depends on those tests is going quite a stretch further.> While you might *want* cmake to replace make in the near term,No, I don't want that. Somebody suggested that having two build systems is a problem, so I retorted that if one of them must stay, is the cmake system, for obvious reasons.> it just isn't going to happen. I don't see how his proposal actually > makes our system cmake worse, and all of your arguments seem to trying > to convince everyone that cmake is better than make. What is going on > here?I'll repeat again: Daniel's proposal means adding a lot of complexity to the build(s), reinventing the wheel and putting a burden on the maintainers. It is absolutely unnecessary for removing the duplicity: you can put the info on some file or in the Makefiles themselves and cmake will read it without problem. For the cmake maintainer, Daniel's proposal would change his work from having to know the cmake build, to having to know the cmake build plus the make build plus Python plus Daniel's own system. It is a way of restricting the set of eligible maintainers to those who know all that. I'm absolutely sure that the amount of required changes to the cmake build for supporting his proposal is much more complex and harder to maintain than the necessary changes from reading the info from the common description file with cmake's own devices. With all due respect to Daniel: I'm convinced that he is doing this because he loves to program Python and considers CMake "horrible" (that's the word he used) but he's not doing a favor to LLVM with this contribution. That's not the case of *replacing* a dinosaur like DejaGNU with something more convenient (as he did.) He is *adding* a lot of stuff. He is proposing a cruise missile as a means to kill a mosquito. Related to this, I'll reiterate my opinion about the explicit library dependency issue. What you want is to force the user to know and approve the dependency changes his modifications to the source code causes. That's orthogonal to maintaining the dependency info up to date. The cmake build used to contain a system for warning the developer about his changes to the library dependencies just after he builds and before he commits. At the same time, the dependencies were automatically maintained in optimal shape. That system is very easy to implement on the `make' build. We begin with a suboptimal decision (forcing the users to manually edit files for declaring the dependencies instead of exploiting the automatic system for implementing the new requirement) and this creates the duplicity problem, which in turn prompts Daniel's proposal, which adds even more complexity for addressing a problem that shouldn't be there to begin with. Happens too often in engineering projects that lots of effort is devoted to solving the problems the engineers themselves created, but let's try to avoid doing that on this case.
On Nov 2, 2011, at 5:30 PM, Óscar Fuentes wrote:> Chris Lattner <clattner at apple.com> writes: > >> Forgive me, but I've lost track of how any of this has to do with >> Daniel's proposal. Recursive make vs not, make vs cmake all don't >> actually matter to his proposal. > > One of the problems with Daniel's proposal is that besides addressing > the duplicity issue, it has no applications to back it up. The things > mentioned so far are either extremely vague, or offer dubious gains > (i.e. removing recursivity from the Makefiles) or trivially done without > his system (i.e. walking the source files, etc.)I don't think this is fair. You never asked what the plan is, you just adamantly criticized the first micro step. Fortunately, things are about to get a lot more concrete :)>> His proposal is basically "cmake isn't going to replace make any time >> soon. We'd like to improve the make system (e.g. by eliminating >> autoconf) and the first step is to factor redundancy that exists >> between cmake and make". > > Does that make sense at all? How is autoconf related with duplicity in > cmake? If he thinks that cmake and autoconf platform tests are > duplicated, he will be disappointed when he discovers that cmake depends > on those tests not only for configuring the LLVM headers, but for doing > lots of stuff. Re-implementing autoconf is a daunting task (if that's > what he wants to do). Shifting to his system all the decisions that > depends on those tests is going quite a stretch further.A big part of the problem not solved by either current cmake or makefile system is that we don't have a good way to decompose LLVM into smaller parts. We have a notion of reusable components, but these are not exposed in a useful way in the build system.>> While you might *want* cmake to replace make in the near term, > > No, I don't want that. Somebody suggested that having two build systems > is a problem, so I retorted that if one of them must stay, is the cmake > system, for obvious reasons.Ok, glad we're on the same page then.>> it just isn't going to happen. I don't see how his proposal actually >> makes our system cmake worse, and all of your arguments seem to trying >> to convince everyone that cmake is better than make. What is going on >> here? > > I'll repeat again: Daniel's proposal means adding a lot of complexity to > the build(s),How do you make this assessment? You haven't seen the code? It seems to me that you're jumping to a lot of conclusions based on your assumptions that may or may not be real.> With all due respect to Daniel: I'm convinced that he is doing this > because he loves to program Python and considers CMake "horrible" > (that's the word he used) but he's not doing a favor to LLVM with this > contribution. That's not the case of *replacing* a dinosaur like DejaGNU > with something more convenient (as he did.) He is *adding* a lot of > stuff. He is proposing a cruise missile as a means to kill a mosquito.This is also the first step of a bigger plan. Daniel is willing and available to improve the build system in a number of ways, are you opposed to all future improvements?> Related to this, I'll reiterate my opinion about the explicit library > dependency issue. What you want is to force the user to know and approve > the dependency changes his modifications to the source code > causes. That's orthogonal to maintaining the dependency info up to > date.I don't see how this is relevant to the discussion.> We begin with a suboptimal decision (forcing the users to manually edit > files for declaring the dependencies instead of exploiting the automatic > system for implementing the new requirement) and this creates the > duplicity problem, which in turn prompts Daniel's proposal, which adds > even more complexity for addressing a problem that shouldn't be there to > begin with. Happens too often in engineering projects that lots of > effort is devoted to solving the problems the engineers themselves > created, but let's try to avoid doing that on this case.This seems like an extreme conclusion, I'm not sure what assumptions you're drawing on to get to this place. -Chris
Chris Lattner <clattner at apple.com> writes:>> One of the problems with Daniel's proposal is that besides addressing >> the duplicity issue, it has no applications to back it up. The things >> mentioned so far are either extremely vague, or offer dubious gains >> (i.e. removing recursivity from the Makefiles) or trivially done without >> his system (i.e. walking the source files, etc.) > > I don't think this is fair. You never asked what the plan is,I asked thrice, and got vague responses about bizarre use cases (walking the set of source code files, organizations creating their own build systems for LLVM based on exotic tools, and so on.) At the end, Daniel posted some description and I argue on top of what he published.> you > just adamantly criticized the first micro step. Fortunately, things > are about to get a lot more concrete :)[snip]> A big part of the problem not solved by either current cmake or > makefile system is that we don't have a good way to decompose LLVM > into smaller parts. We have a notion of reusable components, but > these are not exposed in a useful way in the build system.Well, dictate a set of requirements then. Detaching Clang from LLVM (so Clang can build standalone using LLVM as an external dependency) was done as soon as someone asked for the feature. I'm confident that the same would apply to what you have in mind, if you describe it. (That's rhetoric speech, of course, because it seems that a different route was already taken and because I'm no longer the maintainer of the cmake build. All this doesn't diminish the truth that it contains, though) [snip]>> I'll repeat again: Daniel's proposal means adding a lot of complexity to >> the build(s), > > How do you make this assessment? You haven't seen the code? It seems > to me that you're jumping to a lot of conclusions based on your > assumptions that may or may not be real.I'm using the knowledge about his system that was made available so far and my experience as the author of one of the two LLVM build systems. Getting the library dependencies (and EH/RTTI settings if you wish, plus other information contained or containable in the Makefiles) from cmake is a piece of cake: maybe 20 or 30 lines. And I'll venture that implementing your "component-aware" build would take no more than half-day. As his system has to interface with make and cmake, I'm pretty *sure* that that alone requires modifications to the cmake and make code that dwarfs the features I mentioned. And then there is the Python code.> This is also the first step of a bigger plan. Daniel is willing and > available to improve the build system in a number of ways, are you > opposed to all future improvements?I'm not on a position to oppose anything. I'm just a concerned user. I'll like to think that if some day I run the build on VC++ and it fails, I'll be able to fix it with a reasonable effort. And, to be honest, I'll admit that the programmer in me suffers when he sees how people makes a bad implementation of their own stated requirements.>> Related to this, I'll reiterate my opinion about the explicit library >> dependency issue. What you want is to force the user to know and approve >> the dependency changes his modifications to the source code >> causes. That's orthogonal to maintaining the dependency info up to >> date. > > I don't see how this is relevant to the discussion.Manual maintenance of library dependencies on both builds -> duplicate effort -> Daniel's system for removing it. [snip]