On Mon, Mar 3, 2008 at 6:13 PM, James Mansion <[EMAIL PROTECTED]> wrote: > Brandon Van Every wrote: > >> Then probably that is because those projects use Ruby AND Python AND Tcl > >> - so I have to have them anyway. Hey, lets all use C89. Everyone has > >> that, right? > >> > > > > What if it is just C/C++ code? And the open source author likes > > Python better than Lua? So he does his build in Python, and now I > > have to have a Python interpreter just to build his C/C++ code. > > > Fine. Don't use his code. I try to avoid automake.
Don't you see the problem as far as fragmenting open source builds in general? In the current day, avoiding automake is not a realistic answer as far as the vast majority of open source developers are concerned. If you are personally converting every single open source package out there from automake to CMake, that's commendable, but it's not a labor we should expect the open source world to habitually undertake. If you are not converting anything at all, and simply avoiding vast tracts of the open source landscape, then you are not taking into account the concerns of a very large audience. CMake cares about that audience and it's part of why the Tower Of Babel approach is deemed unacceptable. Other projects, like SCons, do deem it acceptable; you are certainly free to use those instead. I've reported on a number of alternate tools as of late, and given the state of the competition, I do think that CMake's desire to be 1 standard rather than many standards is reasonable. > > Either CMake bloats with an interpreter for every scripting language > > out there, or the user has to install Python for not much of a good > > purpose. I think the ease of the end user is more important than the > > ease of the developer in this case. > > > The two are not separable. The end user is a customer for *all* of the > developer's product. > If its a real issue, the developer will change. So first I implement my CMake build in TCL. Then people scream at me. I re-implement my build in Ruby. People scream at me again, especially the Python crowd. So I add a Python build and chug with both Python and Ruby for awhile, but I'm noticing it's a headache to bother supporting both. I'm getting really sophisticated with SWIG and every single scripting language out there, so I dump everything and build with Lua, for my own sanity of maintenance. People scream again because it isn't their personal favorite language. By this point, I've spent so much time futzing with the build system, that I haven't really developed a product that people care about. I give up and swear off of the never-ending open source money pit for good. I get a "real job" shoveling Ant. I hate it but I get paid well. That's how I see it going down in the real world. Most open source projects don't have the luxury of change, change, change. You're also making the unwarranted assumption that "the developer" is 1 person. Open source projects are often polyglot. People war over these issues. It causes enormous friction that keeps anything from getting done. > The biggest problem with verbosity is that its not really possible to do > subroutines, Actually it is, even in CMake 2.4.8. The price is you have to write these horribly long global variable names, so that your macro "subroutines" won't collide with higher level macros. I've written half of a general purpose Autoconf + GMake --> CMake translator using nothing more than macro subroutines and regular expressions. Some people call that an extreme abuse of CMake script. I say it worked, and the macros were only 3 layers deep. But that was deep enough to clamor for scope and functions, and we're getting it in CMake 2.6.0. As far as I'm concerned, this kind of verbosity has been addressed. I'm probably on the high end of the absurdity scale for what I've pushed CMake script to do, and I did get through it even with what's available now. I pushed CMake script that hard (1) to get paid to push the limits of CMake script, to find out what really needed to be improved about it in the worst case, and (2) the hope that by providing a large example of CMake script doing something non-trivial, I might help spawn more CMake script gurus. (1) worked, jury's out on (2). > and the keywords-as-functions just look wrong to me. But if you have a reason to write enough of it, you quickly get over it. People often must have forced reasons to deal with something new and different. If your boss says, "I want a pilot build written in CMake 1 week from today. We have to know if it's capable of solving our problems," then you just go do it. If your boss says, "Well what do you think about this-or-that build tool?" you have the wiggle room to complain and carp about whatever you like, and thereby defeat the use of the tool. If you don't have any boss, if you're just trying things out, you have no deadlines at all and you can reject stuff on any basis you like. It all depends on what you want to get done, and what you *have to* get done. This is a marketing problem and it divides the market into several segments. People who think keywords-as-functions are a dealbreaker are inevitably in the "Casual Builder" segment. They're not that serious about reaching a real goal, like supporting Unix and MSVC seamlessly. I've learned not to partner with people like that, and to watch out for projects that aren't serious about cross-platform support. Doesn't matter what the wart is, they'll find an excuse to dump CMake if they're not ideologically committed to GCC + MSVC. I'd like CMake to do things that attract more Casual Builders, as I very much believe in building up volume of users at all levels in order to make a tool popular and lucrative. But I know that Hardcore Builders are the core market, people who really have to get massive cross-platform builds done and can't afford to dicker about minor issues. For the next several years, CMake is going to rise according to how many big profile huge projects it successfully wins. Not how many little guys prefer obj.method(blah) to function(KEYWORD blah) or some such. > The language is a long way removed from any common imperative style But once you get over that prejudice, you realize that command(arg arg KEYWORD arg) is actually not hard. There's only 1 thing to learn. The quotes and escapes are what drive people nuts, not the commands. > and it seems to me like a growing collection of special cases. I view the CMake commands as an API. I think it's laid out reasonably well as APIs go. There are some strange functions sprinkled here in there, too obscure to remember unless you live and breathe CMake all the time. I nominate separate_arguments() for that principal honor. I've never seen an API anywhere for anything that was actually nice and perfect. Generally speaking, I hate everyone else's code, I hate trying to understand other people's APIs, and nowadays I only do it if there's $$$$$$ in it for me. I'm saying that, given my revulsion for APIs in general, CMake's command API is reasonable. Just don't expect me to pore over MSDN anymore, I don't do that, no sireee! > Perhaps its just that the documentation is still poor. That's my take on it. Some docs have improved a lot in the past 2 years, others not so much. I have to swallow new stuff to get anything done in computerdom all the time. Looking up APIs or whatnot is a drill, it's work, but I know how to do it. It's when I *can't* look it up, that I have to learn through the school of hard knocks, that I know something is definitely wrong. I also think docs can minimize the time it takes us to learn new stuff, and I don't think CMake docs fully do that at present. You really have to be pretty motivated. I've met many people who have rejected CMake on 1st brush, there was too much of a perceived learning curve they were going to have to do. It's not just docs, it's also tutorials, and whitepapers explaining what you're really going to need out of a build system wouldn't hurt either. Cheers, Brandon Van Every _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
