Re: [CMake] Re: CMake script vs. Lua
On Dec 14, 2007 8:45 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: On Friday 14 December 2007, Brandon Van Every wrote: On Dec 14, 2007 2:38 PM, Bill Hoffman [EMAIL PROTECTED] wrote: It really boils down to this: There is no way we can ever stop supporting the current cmake language. It would be a huge break in backwards compatibility. Gee I'm getting paid to migrate a huge build system, from ancient You're writing this since quite some time already to this list, still not done ? I hope you're not fiddling around with trying to use cmake as a programming language... I'm not trying, I'm succeeding. A primitive translator is simply a pile of regular expressions. I paved over many of the deficiencies in CMake's regular expressions several months ago, using only CMake script. For instance, I implemented a word negation operator. Once CMake has PCRE, that sort of thing won't be needed. crufty GNU Autoconf / GMake crap to CMake. Writing a translator to go from CMake script to Lua script, both under Kitware's control, would BTW, this doesn't imply the translator would be written in CMake script. It's simply easier to have CMake script, Lua script, and a CMake script -- Lua translator all under one roof, no matter what language the translator is done in. It could be done in Lisp, OCaml, or Haskell if those turned out to be appropriate. Don't try to write a converter from some buildsystem to cmake *in* cmake. Why not? Just because you don't think it can or should be done, doesn't make it so. I had 4 motives to do it that way. (1) I was only planning to use regular expressions to do the translation, nothing more sophisticated than that. CMake script is perfectly adequate in that regard. One regex interface is pretty much as good as another, the real programming work is done with the regex strings themselves. (2) I knew CMake script and C++, not some other scripting language. I don't see C++ as particularly appropriate to the problem, as it has no inherent regex support and compile-debug cycles are slow compared to scripting. (3) A large body of CMake script could serve as a political inroad with the client. They might realize the extent to which they could use CMake to do system things, instead of Perl or Python or Ruby or whatever people think you're supposed to use to solve problems. (4) The choice of language was a throwaway. The most important end product is the new build, not the method used to attain the build. So if CMake script proved to be a really good solution, that's great. If it didn't, no big loss. Of these motives, (3) the political one, was my strongest. Why improve Ruby when I could improve CMake script? While not as fluent as in cmake it took me half an hour to do it, in cmake it would have been more complicated. I've programmed the translator for a few months, not a few hours. If the ruby code you're talking about is what I looked at on the wiki, what I've done is way, way beyond that. Conclusion: use cmake to build programs, not for writing programs You have no idea what I've done. There's no conclusion to draw. I don't think what I wrote is that great from a long term maintenance standpoint. If I were going to refactor it for ever-more-generalized translation, I'd want the PCRE capabilities. I might even want to use a completely different form of pattern matching, and just reuse the overall design rather than the specific components. But I do believe my approach was cost effective, in terms of dollars spent for translations accomplished. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake script vs. Lua
On Dec 14, 2007 10:57 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: Brandon Van Every escreveu: Most of my concerns about nicety of language are strategic, not tactical. Let's not forget that cmake is being used by KDE, I think they wouldn't change again their build system :) By hand, no. But fully automated transformation is a different strategy. I suppose it does require a string of guinea pigs to prove that an automated translation actually accomplishes its miracles. Wouldn't expect KDE to volunteer for the bleeding edge. Actually, it begs a question of who would. Maybe it's better to auto-translate non-CMake builds, develop that core technology, then eventually apply it to legacy CMake builds. There's a whole 'nother tack that one could take about this stuff. That the language is good enough; it's the documentation which lacks. Maybe the documentation is poor because kitware sells the book Mastering CMake? I'm sure it affects what they invest their time in. But the reality is they're not currently selling Mastering CMake, they're sold out. I think Kitware realizes the free docs have to be good enough to keep people interested in CMake when they first try it out. I think we have to go explore the other build systems and find out what they do better. I don't think we've really done that. I don't think that kind of information has been brought to the debate. This discussion made me want to kill the monster that jam (and bjam) became for me. People at boost are very influential and knowledgeable about systems design and implementation, they *might* be right by choosing bjam, but I can't see how. Try to cross compile boost, doing a linux - win32 build... My attempts worked until version 1.33.1, then no more. They're also known to be stubborn about bjam... just try to mention cmake there hehehe... That's odd. I heard a rumor that they were considering CMake. But I never followed up on that with anyone official. Kitware ain't in this for religious zealotry, they're in it because the open source business model works for them. If I thought I could make lotsa money setting up a Mercurial repository, mirroring CMake Alright, the world isn't good as we'd expect, but it doesn't change the fact that the last opinion is theirs, for the bad or the good. Their opinion counts for what they choose to do. What do *you* choose to do? How badly do you want Lua? Is it actually worth money to you? Figuring out what's worth money is an important question. There's tons of open source projects out there with a handful of unpaid guys, with a predictable lack of support. The lofty goals of the project fall behind when the unpaid guys get tired of $0. But if you can figure out where the money is in something, that's different. The problem is that cmake now is being actively used, too late for language change. Nonsense. People write build systems from scratch all the time. Or they translate from legacy systems that aren't CMake. There are far more people who don't use CMake than do. They'll use whatever looks like the best tool for the job. And, even legacy CMake builds are capable of slowly migrating forwards in some instances. My experience is that migration is a question of political will. There are dangers in allowing 2 different build systems, or 2 different build system approaches (i.e. CMake script and Lua script), to exist side by side. People who really didn't have to sacrifice anything for the new build system, will clamor about wanting to retain the old. If you do too good a job of maintaining old and new systems / approaches side-by-side, then people have no incentive to ever really move forwards. Politically, it's far better if you can get people to dump the old system and fully commit to the new one. That's not always possible. But if you can marshal the political will in that direction, you're in much better shape. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake script vs. Lua
http://svn.boost.org/trac/boost/wiki/CMakeConfigAndBuild -- Mike Jackson Senior Research Engineer Innovative Management Technology Services On Dec 15, 2007, at 4:16 AM, Brandon Van Every wrote: This discussion made me want to kill the monster that jam (and bjam) became for me. People at boost are very influential and knowledgeable about systems design and implementation, they *might* be right by choosing bjam, but I can't see how. Try to cross compile boost, doing a linux - win32 build... My attempts worked until version 1.33.1, then no more. They're also known to be stubborn about bjam... just try to mention cmake there hehehe... That's odd. I heard a rumor that they were considering CMake. But I never followed up on that with anyone official. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Ignoring command return code in add_custom_command
Rodolfo Lima wrote: Alexander Neundorf escreveu: On Friday 14 December 2007, Bill Hoffman wrote: That said, an automatic way of running a cmake script at build time as part of a custom_command might be a good feature. See bug report #3604 :-) I think a dig on old bug reports could reveal very interesting things. This one was filled 08-11-06 16:30 and never touched again. There's a lot more where this came from :) Yea, I have been looking over the bugs recently, they do pile up. :) I think it would be a full time job to keep them all closed. Many are feature requests like this one. They are nice to have things, but are not really needed immediately. It is still good to track them and store the ideas in the bug tracker. I really would love to be able to fix all of them, but there really is not the time/funding to do that. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake script vs. Lua
OK, so here are my thoughts on using CMake as a full scripting language. ... I think it is feature/mission creep. When I started CMake, I was trying to make a tool that would make building software with native tools easy for non build system types of developers (mostly researchers). Usually on a team of developers there is one person that knows how to build software, and that person maintains complicated makefiles/autotools stuff, and maybe a windows developer on the team maintains some visual studio project files. CMake is meant to make the build system accessible to all the programmers on the team. The input should and can be simple for many projects. It should be easy to link in external libraries and to create libraries for others to use. I think CMake has meet those goals fairly well. However, I never intended for the language to be used as a general purpose programming tool. There are much better languages out there for that type of thing. When compared to perl/python for text manipulation processing CMake is a poor choice. If on the other hand, you want to build a c/C++ project CMake is a good choice. I don't think it is a worth while effort to try and compete with perl/python. Use the right tool for the right thing. Scope creep is a common pitfall for software projects. Here are some wiki entries about the issue: http://en.wikipedia.org/wiki/Creeping_featurism http://en.wikipedia.org/wiki/Scope_creep Scope creep is a more accurate term for what is going on with trying to make the CMake language a competitor to perl/python. As to why I regret starting this thread, I think it is a waste of my time. Most likely 3 or 4 bugs from the CMake bug tracker were not closed because I have been reading/writing emails on this thread. As someone pointed out there are plenty of bugs in the tracker to fix! From wiki featurism: software which over-emphasizes new features to the detriment of other design goals, such as simplicity, compactness, stability, or bug reduction. Adding a whole new language would not help the build process at all, and would take away from all of the above. It would fork the project if we did not support the CMake language forever. It would be classic CMake, and lua CMake or something like that. Some projects would move over and others would keep using the old stuff. Less of the bugs and build features would get implemented. There are plenty of important build features that need to be added to CMake that have nothing to do with language. Those would get put on the back burner. And, it would all be done for what? So, the language was more elegant? There are some vocal complainers about the language, but I suspect there is a silent majority that really don't care, and are just happy to have the software build correctly the first time they build it. (I could have fixed at least one but instead of writing this email :) ). -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using cmake -E copy to copy files
Alan W. Irwin wrote: Well, it turns out I had to add four different target dependencies to the CMake-based PLplot build system to get rid of the parallel build problems I was having on my Core Duo box. One of them was pretty subtle so I missed it for my first review of the dependencies. Nevertheless, these changes were not as extensive as I thought they would be so there is some hope that I didn't miss anything that will show up as strange parallel build problems for PLplot on other machines. Great, I'm glad you got it working. Is that complete rework actually going to happen for 2.6.x or is it currently just a gleam in the CMake developer's eyes? To what message are you referring? -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake script vs. Lua
BTW it wouldn't offend me personally if you don't want to respond any
more to this *right now*. You seem harried about other work you feel
you need to get done. I do think Lua boosters need to fan out to
other build communities and develop more compelling arguments for why
expressive, standard languages matter.
On Dec 15, 2007 12:41 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
When compared to perl/python for text manipulation
processing CMake is a poor choice.
That's only because CMake has a somewhat backwards regex engine. I
don't know what other magic you think Perl, Python, or Ruby perform.
A modern regex is a modern regex. The addition of PCRE to CMake
script would make it a much more capable text processing language. I
don't believe in weird $_ variables for text processing. Neither does
Python: regexes aren't core syntax, they're a library same as CMake.
Lately I believe in
string(REGEX REPLACE
${regex}
${replace}
output ${input})
because that way, all major concerns of the somewhat complex operation
are on their own line. If I check such a regex into source control,
then later on, I can make changes against specific lines. Like, the
regex was bugged, but the replace was fine. Also, frankly, my regex
and replace strings get so long that they usually need their own
lines. Regular expression programming becomes very dense very
quickly. It's not about having a fancy text processing language,
it's about having a good regex engine. The regex string is the real
program.
http://en.wikipedia.org/wiki/Creeping_featurism
Featuritis, creeping featurism, or the spoonerism feeping creaturism
is a term used to describe software which over-emphasizes new features
to the detriment of other design goals, such as simplicity,
compactness, stability, or bug reduction.
Using a 3rd party language promotes bug reduction, as hordes of other
people are banging on the language to make it bug free. Python, Ruby,
and Lua are all fairly simple languages; that's part of why they're
popular. They're all more stable than CMake script. Having a choice
between CMake script and a 3rd party language would introduce some
instability in CMake for a time, but I see that as transitional. Are
they compact? Lua is, by any definition. Embedding Python or Ruby
does have some bloat issues, but their popularity should be considered
as a tradeoff. I'd look at how Python and Ruby are doing in the
embedded marketplace before passing judgment on bloat issues.
http://en.wikipedia.org/wiki/Scope_creep
Scope creep is a more accurate term for what is going on with trying to
make the CMake language a competitor to perl/python.
Well, Ken already showed us a 90% acceptable Lua implementation, so
it's hard to take budgetary considerations seriously. At least, not
to the extent of gloom and doom, if there are other positive things to
be gained. You want CMake business in general to grow, right? You're
willing to allocate resources towards strategic growth, right? So to
me the question is whether they're lavish or modest layouts. Ken's
work indicates modesty.
As to why I regret starting this thread, I think it is a waste of my
time. Most likely 3 or 4 bugs from the CMake bug tracker were not closed
because I have been reading/writing emails on this thread. As someone
pointed out there are plenty of bugs in the tracker to fix!
Eh, you are also staunchly opposed to moving away from your language
baby. You're the person who would take the most convincing. I'm
impressed that you at least listen and respond to people's arguments
on the matter. It shows that there *might* be an argument that
convinces you, but that we haven't made it yet. You might think that
keeping your head down in the bug tracker is the most important thing
you could possibly be doing for CMake. I don't agree. I think being
responsive to the CMake community, particularly newcomers who are
uncertain *why* they should be saddled with CMake's various quirks, is
equally important. I don't measure value by number of bugs fixed, I
measure it by number of users gained. You may think you're wasting
time, but you are not: you are simply applying your time to a
different aspect of CMake's success. CMake really wouldn't be
anywhere if we all didn't feel the love from you. :-)
Adding a whole new language would not help the build process at all,
That's what you say. We really need the input of other build system
communities. And, I think we Lua boosters have an obligation to
present that input convincingly. We have not so far.
It would fork the project if we
did not support the CMake language forever.
Ok, so you want to ignore the possibility automatic translation.
Sorry, I won't let you. :-) Forever is a strong word. Where will
CMake be in 10 years' time? Will it be the de facto industry standard
build tool? Or will it be an also-ran, eclipsed by other products
that invested in standard languages and automatic migration
[CMake] Waf build tool
On Dec 15, 2007 1:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote: On Dec 15, 2007 12:41 PM, Bill Hoffman [EMAIL PROTECTED] wrote: There are some vocal complainers about the language, but I suspect there is a silent majority that really don't care, CMake is a self-selecting community. Those that really care, leave. I'd like to know where they went, and what competing products they're working on. I've subscribed to the SCons mailing list. The SCons community has people who got fed up with it and started their own RD. It seems that the SCons Python 1.5 limitation is a serious one, as developers generally only know Python = 2.2. Waf is the offering of a fellow who clearly thinks OO is important in a build system for some reason. http://code.google.com/p/waf/ A recent comment of his, regarding KDE's use of CMake: http://thread.gmane.org/gmane.comp.programming.tools.scons.user/15656/focus=15659 * Cmake scripts are easily readable from IDEs (kdevelop); in reality parsing-writing Cmake scripts from ides is much more difficult than using object-oriented apis and mapping to xml when needed Without evaluating the veracity of his claim, or even evaluating Waf at all, this says something important to me. It says that not everybody believes in a make paradigm for a build system. I think the generational logic is understandable. In college I did makefiles; after college I learned IMake and Autoconf. That's what people did in the early 1990s. This is now the late 2000s. I've completely ignored the XML universe. Something about all those angle brackets just gives me a rash. But let's say I was just getting out of college right now, and everything was new and squeaky clean to me. Would I be trying to do everything with XML? Would I see OO as fundamental, of course! it's easier to do a build system that way? Would I see Make as fundamentally old fashioned? Would I have little experience with declarative systems? Little incentive to work with build tools based on old-fangled paradigms? Most importantly: would my prejudices cause me to use, or even develop, OO build tools that actually get real work done? Whether coupled to an OO IDE or not. The proof is in the pudding. If there are OO build systems that are having any success, we should pay attention to why. We should be wary of generational biases of what a build system should or shouldn't look like. Do we really know better than everybody else? Does our extensive engineering experience make us more efficient, productive, and competitive? Or does it (also) make us blind to the technology around the corner? I've seen new generations sweep old generations away. As one young buck put it in that thread: http://thread.gmane.org/gmane.comp.programming.tools.scons.user/15656/focus=15659 I dunno the particular situation, but for me using CMake sounds like they didn't make the step out of the last decade :-) Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using cmake -E copy to copy files
On 2007-12-15 12:57-0500 Brad King wrote: Alan W. Irwin wrote: Well, it turns out I had to add four different target dependencies to the CMake-based PLplot build system to get rid of the parallel build problems I was having on my Core Duo box. One of them was pretty subtle so I missed it for my first review of the dependencies. Nevertheless, these changes were not as extensive as I thought they would be so there is some hope that I didn't miss anything that will show up as strange parallel build problems for PLplot on other machines. Great, I'm glad you got it working. Well, I thought so, but my previous test was without the (docbook) documentation build. Now, that I have included that, the parallel build errors out. For the last few hours I have been going through the complicated dependencies in our documentation build, but I just cannot see what is causing the trouble. Perhaps if I sleep on it, it will become obvious tomorrow. Is that complete rework actually going to happen for 2.6.x or is it currently just a gleam in the CMake developer's eyes? To what message are you referring? I was sure I remembered a discussion of reworking the CMake depends system on this list in the past year, but I have been unable to find it so perhaps I was misremembering (or perhaps my searching skills are not good enough). So let me rephrase the question. Are the CMake developers happy with the present state of the dependencies system or are you considering some major changes there because of such issues as the difficulties in getting parallel builds to work properly for projects like PLplot which (necessarily) have complicated chains of dependencies? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Parallel builds do not work correctly when using cmake -E copy to copy files
Alan W. Irwin wrote: So let me rephrase the question. Are the CMake developers happy with the present state of the dependencies system or are you considering some major changes there because of such issues as the difficulties in getting parallel builds to work properly for projects like PLplot which (necessarily) have complicated chains of dependencies? I personally don't have any problems with the current state. I do parallel builds of big projects all the time. There will be no major changes. If you want to submit a feature request to the bug tracker you're welcome to do so. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Waf build tool
On Saturday 15 December 2007, Brandon Van Every wrote: On Dec 15, 2007 1:55 PM, Brandon Van Every [EMAIL PROTECTED] wrote: On Dec 15, 2007 12:41 PM, Bill Hoffman [EMAIL PROTECTED] wrote: There are some vocal complainers about the language, but I suspect there is a silent majority that really don't care, CMake is a self-selecting community. Those that really care, leave. I'd like to know where they went, and what competing products they're working on. I've subscribed to the SCons mailing list. The SCons community has people who got fed up with it and started their own RD. It seems that the SCons Python 1.5 limitation is a serious one, as developers generally only know Python = 2.2. Waf is the offering of a fellow who clearly thinks OO is important in a build system for some reason. http://code.google.com/p/waf/ When KDE tried to switch to scons, many changes had to be made to scons, and this modified version is waf. A recent comment of his, regarding KDE's use of CMake: http://thread.gmane.org/gmane.comp.programming.tools.scons.user/15656/focus =15659 * Cmake scripts are easily readable from IDEs (kdevelop); in reality parsing-writing Cmake scripts Parsing/writing cmake scripts should not be done by IDEs, except for syntax highlighting and autocompletion. I don't see a problem there. ... Most importantly: would my prejudices cause me to use, or even develop, OO build tools that actually get real work done? Whether coupled to an OO IDE or not. The proof is in the pudding. If there are OO build systems that are having any success, we should pay attention to why. We should be wary of generational biases of what a build system should or shouldn't look like. Do we really know better than everybody else? Does our extensive engineering experience make us more efficient, productive, and competitive? Or does it (also) make us blind to the technology around the corner? I've seen new generations sweep old generations away. With the property stuff cmake is already becoming more OO. As one young buck put it in that thread: http://thread.gmane.org/gmane.comp.programming.tools.scons.user/15656/focus =15659 I dunno the particular situation, but for me using CMake sounds like they didn't make the step out of the last decade :-) Feel free to write an ant or whatever generator for cmake :-) Alex P.S. if you would take 50% of the time you use to post here to write patches for cmake instead, much of what you would like to have could already be implemented ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMake script vs. Lua
Bill Hoffman escreveu: However, I never intended for the language to be used as a general purpose programming tool. There are much better languages out there for that type of thing. I couldn't agree more. As to why I regret starting this thread, I think it is a waste of my time. Most likely 3 or 4 bugs from the CMake bug tracker were not closed because I have been reading/writing emails on this thread. As someone pointed out there are plenty of bugs in the tracker to fix! Hehe, look at the monster I've created! But it's been a healthy discussion, at least I'm convinced that CMake shouldn't use Lua. I still think it would be better, but it's not feasible in its current state and wouldn't add nothing fundamental regarding build systems. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] cmake cvs documentation Errors
Using CVS from Dec 15, 2007: 540:[EMAIL PROTECTED]:Build]$ bin/cmake --help-variable CMAKE_LANG_LINK_EXECUTABLEcmake version 2.5-20071215 Argument CMAKE_LANG_LINK_EXECUTABLE to --help-variable is not a defined variable. Use --help-variable-list to see all defined variables. but if I do a bin/cmake --help-variable-list that variable DOES appear in the list at around line 111. Thanks -- Mike Jackson imikejackson gmail * com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] too many kinds of FALSE
CMake defines FALSE as a string that's empty, 0, N, NO, OFF, FALSE,
NOTFOUND, or variable-NOTFOUND. I just realized that my regexes are
not safe with respect to capturing the letter n.
set(sillystring The rain in spain)
string(REGEX MATCH
.$
thematch ${sillystring})
if(thematch)
message(regex works)
else(thematch)
message(regex doesn't work)
endif(thematch)
C:\devel\src\cbugs\trueorfalsecmake -P trueorfalse.cmake
n is false
regex doesn't work
What's so great about n and no ? I've never used them. Do we
really need to be polluting the interpretation of strings with these
values? What current or legacy code is using them heavily?
ON and OFF are used in the Options, but why can't these just be TRUE
and FALSE, so that there's less variety of how we specify TRUE and
FALSE? Alternately, how about defining a boolean storage type to hold
options?
How about a numerical storage type, so that 0 and 0 aren't the same
thing? And so that we don't have to type MATH(EXPR var ${var} - 1),
we could just type var = var - 1. The problem with assuming that 0
means FALSE, is it assumes I got my 0 by counting with a MATH
expression. What if I got my 0 by matching with a regex, like a
digit of a library version?
-NOTFOUND doesn't trouble me so much, as it's unlikely to be
accidentally matched in a regex.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
