Re: [CMake] VMWare on SCons' future
On Tue, Mar 4, 2008 at 2:30 AM, Jesper Eskilson [EMAIL PROTECTED] wrote: Brandon Van Every wrote: On Mon, Mar 3, 2008 at 6:06 PM, Brandon Van Every [EMAIL PROTECTED] wrote: http://www.nabble.com/SCons-Future-Directions-and-Thoughts-td15176258.html you can learn tons about SCons from that thread. And there's one *really* spectacular public flame, if you need a motive to stay awake reading through it. Care to elaborate for those of use too lazy to read through the whole thing? No, not really. I want you to feel a sense of anticipation and reward for working all the way through it. :-) Trust me though, you don't get fireworks like that from a core contributor every day. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Lua in a nutshell
On Tue, Mar 4, 2008 at 7:52 AM, Fernando Cacciola [EMAIL PROTECTED] wrote: Nutshell: is it strategically a good idea to implement Lua support for CMake? - CMake script must be maintained indefinitely for a small percentage of users no matter what the migration strategy BTW, this point is intended to mean that CMake script must always be supported, even under the most wildly optimistic migration strategy. One can debate how many CMake script users will have to be supported indefinitely in practice, but there will always be some. We can add languages, but we can't really take them away, not without a fork of the CMake code and community. OK, time to see what Lua is... Or maybe see what Python is. Just because SCons uses Python 1.5 and Waf uses Python 2.3, doesn't mean CMake couldn't use it. The Python license is fine, it's just slower and not as easy to embed as Lua. What if Python finally speeds up and Jython goes somewhere? An article that appeared today: Sun hires Python pros in dynamic languages push http://www.news.com/8301-10784_3-9884267-7.html?tag=head - too much programmability may cause people to treat CMake as more of a library or build component, rather than a standard end user tool People always find the way to shoot themselves in the foot. I say don't worry about that and trust the programmer. If I had a reason to be confident that multiple languages could be used seamlessly with equal engineering quality, maybe it wouldn't be so insane. Last night I thought about what the OO version of CMake would look like, for marketing not technical reasons. Why not target.add_dep(dep1 dep2 dep3 ...) ? The swizzle of transforming command(object ...) to object.command(...) is straightforward. Mainstream programmers probably would be more comfortable with object.keyword(...) to set some state. A lot of the CMake command set is well defined, field proven, and stable. I don't think anyone would have a problem mentally translating back and forth, the commands of the CMake interface that are actually crystal clear. It's things like separate_arguments() that need to be put to death, with type safety and so forth. I suppose that's a liability of language choice: not all languages are equally type safe. Still, all of this suggests a Virtual Machine approach to CMake. The open source universe certainly clamors for it, so if it could be done to a high level of engineering quality, maybe it is not so stupid. On the other hand, maybe typed, named arguments are sexy. Sexier than KEYWORD. Another thing to consider is, getting more people under your tent is not necessarily a bad thing. It doesn't work for SCons because there doesn't seem to be that much of a business model over there. I don't know how much money is locked up in SCons, they do have some noteworthy commercial users like VMWare, but SCons seems to be a well-meaning volunteer outfit. Hard to move aggressively on $0. Meanwhile, Kitware is much more mature as a business. What if at the logical extreme you had someone as large as Sun dumping money into CMake development? At the macroeconomic scale, CMake script is too parochial and not what the marketplace wants as The One True Build Language. In fact the marketplace may not want The One True Build Language at all; they might be amenable to the one true build engine. Someone like Sun could dump money into making a lot of options work well together. That's what these big companies love to do: go to war with competing Virtual Machines. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake community site
On Tue, Mar 4, 2008 at 10:08 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Mike Jackson wrote: Also, what happens when you stop being a student with lots of time to keep the site going? That's easy. If he did a good job, he gets hired by Kitware :) Does he? If it's Kitware's priority to spend money on such things, then why does the site look like it does now? I think it is because they do not see the wiki as a key part of their business model, i.e. no revenue stream. Or perhaps they only spend the money they currently think is warranted. What wiki improvement would cause Kitware to see it as a profit center? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Raven, Antwrap, Buildr
On Mon, Mar 3, 2008 at 9:13 AM, Gonzalo Garramuño
[EMAIL PROTECTED] wrote:
It is not the ruby syntax that is horrendous but the rake one. I'm a
true fan of ruby but not of rake. Raven is just a wrapper built on top
of rake to add java functionality
Ok, good to know. I'm tempted to say that if it's easy to redefine
the syntax of a general purpose scripting language, that's
disadvantageous for a build system. Although perhaps it's the same
level of concern as operator overloading in C++. Yes you can do goofy
operator overloads, but they're actually useful if you're just trying
to do vector math instead of scalar math, or some kind of IO. I
suppose operator overloads have to be weighed against the verbosity of
some_function_call(blah blah). Perhaps a syntax can be well designed,
but the Rake author didn't happen to design it so well. I do wonder
at programming cultures of redefining syntax though. It might be
valid to say it's too easy in Ruby, or Lua. There are certainly a lot
of language tweakers in the Lua community.
I imagine someone else will argue that redefining syntax is the killer
app that we're all needing for our large scale builds. If only we
could customize to the way we personally think about a build.
Customization vs. standards, yep. Maybe there's a whitepaper in that
somewhere, about why standards are better.
The advantage is for OO. Consider this:
task :myexe { |t|
t.link_libs = asdasd
t.so_version = 1.0
t.call_func
}
With that, you'd basically have an OO approach to setting cmake
properties (and not just properties, you can also run a function defined
in whatever class t is).
Ok, an OO syntax that looks queer to a C++ programmer. Not sure
that's a great marketing pitch, but maybe they'd come to love it
because it's OO. It's worth noting that Lua isn't OO. My jury is
still out on the technical merit of OO for builds. I don't think the
Raven, Buildr universe proves anything, they don't seem to have any
projects big enough to warrant OO. Onward to SCons.
- how, in any universe, could this possibly be preferable to
add_dependencies(target dep1 dep2 dep3...) ?
An api (say swig wrapped) that would be identical to cmake would look like;
add_dependency :target, :dep1, :dep2, :dep3
BTW I'm glad to see I'm not the only one who can't ever remember
whether it's singular or plural. :-)
Only Ruby people are going to see this syntax as an advantage. It's
worth remembering that Ruby got popular not because of the language,
No, ruby got popular with the language and is highly respected for it.
Rails made it popular for the web.
Perhaps we differ on notions of cause and effect. IMO Python, Ruby,
and PHP all got popular because of the web. Scripting languages get
tried when the code is throwaway and any scripting language would do.
A lot of web jobs were / are of that nature. Haven't thought much
about why scripting languages are retained. In Ruby's case, it
clearly has some advantages over Perl and is often described as an
OO-ified Perl. In contrast, languages like Lisp and Scheme are never
retained, even though plenty of scripted versions exist. Scheme could
be dismissed as too non-standard; even now the Scheme world is split
between RSR5, RSR6, and everyone's personal variant. Common Lisp,
they claim it's all about historical prejudice due to the AI Winter,
but how long can that chestnut remain true when a new generation of
programmers doesn't even know what the AI winter was? Maybe it's
their inability to define a standard C FFI. Well, TIOBE would seem to
say that Common Lisp is more popular than Lua, so indeed maybe old
prejudices are fading.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
P.S. BTW, rake is something like a 200 line script only, so it is
extremely bare-bones.
Hm. A reputation disproportionate to its size. How does a language
or tool manage that? Early niches filled?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] repeating conditional clauses
On Mon, Mar 3, 2008 at 4:55 AM, Sylvain Benner [EMAIL PROTECTED] wrote: I don't buy the do it with comments approach. Something changes, then the comments are wrong. It's a fact that the code must be self explanatory as much as possible but it will never be as powerful as good and up to date comments. Comments don't get updated. They're correct for awhile, then they rot. I don't buy the duplication of code approach. It makes lots of sense when you have to scroll an entire screen to see the next clause of the conditional. Part of what trips people up though, is that else really means else_not. And what does endif refer to, the if or the else_not ? if(blah_is_true) yadda(yadda) else_not(blah_is_true) badabim(badabang) endif(blah_is_huh???) # should be blah_was_used I think it's easy to get used to this, if you write a lot of CMake script. But clearly, it is paradigmatic of CMake, and weird to anyone else. It's not great marketing material. It leaves the newbie or casual user cold, i.e. someone who only does periodic maintenance and doesn't try to be a CMake expert. Maybe we could just ask our program text editor to magically insert an appropriate comment, based on the if(clause). It would be a form of pretty printing. It would comment any conditionals that are more than 20 lines apart or whatever. if(blah) yadda(yadda) else #(NOT blah) badabim(badabang) endif # see blah Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Add lots of commands
On Mon, Mar 3, 2008 at 11:24 AM, Robert Bielik [EMAIL PROTECTED] wrote:
In ADD_CUSTOM_COMMAND(TARGET POST_BUILD
COMMAND cmd1 args1
[COMMAND cmd2 args2]
)
I'd need to be able to add as many commands as are in a list, sort of like:
In ADD_CUSTOM_COMMAND(TARGET POST_BUILD
FOREACH(entry)
COMMAND ${entry}
ENDFOREACH(entry)
)
Is it possible to achieve this is some way?
Not in any nice way. You've hit the dis-unity of add_custom_command
with other things. You could write all your commands out to a file,
and then execute that file as a CMake script. But you can only use
FOREACH at configuration time, so if for some odd reason you're trying
to construct commands at build time after CMake is gone, that won't
work. Assuming you are getting all your commands at configuration
time and that their configuration is static, you could do:
# make a chain of dependent targets, each executing 1 command
add_custom_command(TARGET mytargetname)
set(chain_num 0)
set(prevchain_name mytargetname)
foreach(entry ${some_command_list})
set(thischain_name chain${chain_num})
add_custom_command(TARGET ${thischain_name}
COMMAND ${entry})
add_dependencies(${prevchain_name} ${thischain_name})
math(EXPR chain_num ${chain_num} + 1)
set(prevchain_name ${thischain_name})
endforeach(entry)
I have used this kind of dependency chaining approach to automagically
disambiguate conditionals in Autoconf Makefile.in's. Autoconf allows
conditionals inside of makefile targets and CMake does not. If you
happen to be worrying about that kind of problem, and you have lots of
Makefile.in's to worry about, I'd strongly suggest you look at the
code I did for Mozilla. There's a chance it might just parse your
conditionals into sanity, breaking them into appropriate dependent
chains. Of course I wrote that code for Mozilla, not the rest of the
world, so no guarantees. I'm willing to advise on what must be done
for anyone's specific purposes though. The code is available under
Mozilla's usual tri-license.
https://bugzilla.mozilla.org/show_bug.cgi?id=416982
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] VMWare on SCons' future
VMWare is a large commercial project. http://www.vmware.com/ They have been using SCons for about a year now, and they say they're relatively happy with it. They've made a recent post to the SCons mailing list that has engendered a lot of discussion (131 replies). http://www.nabble.com/SCons-Future-Directions-and-Thoughts-td15176258.html I'm going to pick through the post and see if SCons demonstrates anything conclusive about scripting languages. I think I've now surveyed all the other open source tools out there, and they just don't have a history of projects large enough to say anything. I don't think there are any competing proprietary tools? If I've overlooked something please let me know. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: VMWare on SCons' future
On Mon, Mar 3, 2008 at 2:11 PM, Brandon Van Every [EMAIL PROTECTED] wrote: VMWare is a large commercial project. http://www.nabble.com/SCons-Future-Directions-and-Thoughts-td15176258.html My impression so far is that SCons appeals to a company that wants to program a customized build system, rather than have one off-the-shelf that already works. A customized build system requires dedicated manpower and exotic needs. VMWare has those needs; it has been pointed out that many other companies do not have such needs, nor dedicated full-time in-house build guru expertise. Also, when the build system is programmable, people seem to start treating it as a library rather than an end user tool. There's talk of refining SCons into different engines and layers and so forth. These could all be strategic reasons to avoid offering general programmability. Perhaps most of the customers really don't want it. What Would Microsoft Do? They'd wait for someone else to do the RD, then clone it. Perhaps it's better to let companies customize to their hearts' content in SCons, figure out the build feature they really need (like a programmable dependency graph in the case of VMWare), then provide some feature in CMake that answers that specific need. I am starting to wonder if the whole Lua thing is indeed a red herring, and what CMake really needs is the best possible website to document, tutorialize, and market CMake. In other words, what we've got is fine; go sell it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake community site
On Mon, Mar 3, 2008 at 3:34 PM, Matt Williams [EMAIL PROTECTED] wrote: So, what do you guys think? Is this sort of site wanted/needed? Yes it is. Is this list and wiki enough No they aren't. and should our efforts be focused on them? The inevitable problem is labor. The mailing list works fine, there's plenty of labor available for answering people's questions. I can't say the same about the wiki. The documentation issues I've cared about, and that I think a lot of developers care about, are improving at a glacial pace. I won't point fingers as I've been just as lazy as anyone else. I make contributions from time to time but it's very boring and I find other things to do. Other aspects of a website, like marketing and general slickness, aren't being addressed much at all. Bill came up with a page of Really Cool CMake Features, and that's a really cool thing to have on the wiki. But it is also merely a prototype / stand-in for something that, by corporate standards, should be a lot slicker bulleted list of columns and tables comparo type of thing. I'm talking website production values. The frontal presence of CMake is ok if not exemplary. But the farther one pushes back into the wiki, the more it reeks of amateurism. People who have a long memory for the various open source communities I have offended, will remember that I went around the block with this in Python days. I'll never forget Guido chewing out his best web designer, the one who had done all the free professional quality work for him. Back in the day, the Python Software Foundation wasn't willing to buy into anyone's website vision or logo proposal. Rather, they reserved the right to dismiss and decline anything the open source community might bring to them, and wouldn't bless or work with anyone in particular. This situation was never solved. Despite the abundant talent of webmasters, amateur logo artists, and CEOs of major companies working to drive the project forwards, slick logos and Python website redesign never happened. The CEOs just folded up their tents and went back to working on their own corporate websites, not Python's. Eventually Guido went to work for Google and adult things were made to happen. The Python website you see today, could have easily happened 2 years earlier. Kitware, thankfully, is a much more functional partner to be working with on such matters than the PSF. The lesson of history, however, is that the controlling company's perspective and buy-in is critical. If they're not contributing a chunk of direction and labor to such an enterprise, then it probably won't get any better than it is now. Another lesson may have been that there simply wasn't enough money in website slickness for Python to compete at the pro level? Macroeconomically, perhaps Python inevitably had to be championed by a company as large as Google to really get things done. I don't know if any Pythonistas are in the house to comment on this; perhaps they can shed light on how Google has helped steward the Python community in recent years. I would like to think that once upon a time, before Google, there were a lot of well-meaning amateurs capable of great things who simply got blocked from doing them. If that is true, then all we have to do is be willing to do it. Python also had a major strategic advantage for getting this sort of thing done: lotsa web developers. Who's good at that sort of thing 'round here? I'm not. I think I'll learn how to make my own slick website before worrying about how to do it for CMake. I've always disliked web technology, as it's so godawful slow compared to 3D graphics and assembly code, but the web is definitely the key to modern techie marketing. So grudgingly, I'll see if I can stand to learn some NVU. http://www.nvu.com/ I had a website a long time ago that I used FrontPage 2000 for. That was no fun, and it never amounted to anything resembling professional production values. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Lua in a nutshell
On Mon, Mar 3, 2008 at 5:11 PM, Fernando Cacciola [EMAIL PROTECTED] wrote: Brandon wrote: I am starting to wonder if the whole Lua thing is indeed a red herring, and what CMake really needs is the best possible website to document, tutorialize, and market CMake. In other words, what we've got is fine; go sell it. I have the feelling that I'd like to get into *this* discussion (not that SCon's related one), but I'm a newcomer much too late to the party, so: what's the whole Lua thing in a nutshell? Nutshell: is it strategically a good idea to implement Lua support for CMake? In my opinion: Pros: - higher quality 3rd party documentation that the CMake community needn't maintain. - CMake gets a popularity boost from Lua, as it's a mainstream accepted language. - Lua's corner cases are more ironed out than CMake script. 3rd party continues to iron them out. - proof of concept has already been demonstrated and was relatively easy to implement Cons: - although doable, it's extra work to support 2 languages - without a comprehensive migration strategy, it would split the CMake community - CMake script must be maintained indefinitely for a small percentage of users no matter what the migration strategy - too much programmability may cause people to treat CMake as more of a library or build component, rather than a standard end user tool Undecided: - Do advanced programming constructs really matter? OO? A fool's game / fad / waste of time? Or is it a killer feature that will make or break products in the future? If it has something to do with the CMake scripting language, well, I for one would love to drop it and use something else, like (don't get me started on the wrong tail) The archives contain abundant ink on this subject. Well, bytes, whatever. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VMWare on SCons' future
On Mon, Mar 3, 2008 at 3:07 PM, Brandon Van Every [EMAIL PROTECTED] wrote: On Mon, Mar 3, 2008 at 2:11 PM, Brandon Van Every [EMAIL PROTECTED] wrote: VMWare is a large commercial project. http://www.nabble.com/SCons-Future-Directions-and-Thoughts-td15176258.html My impression so far is that SCons appeals to a company that wants to program a customized build system, rather than have one off-the-shelf that already works. Here's an exemplar: http://www.nabble.com/SCons-Future-Directions-and-Thoughts-td15176258i60.html I don't think we'll ever be able to define a model for how tools should look, or how command lines should be generically specified, that will satisfy everyone. It's just not possible. After I wrote my original email, I got a lot of feedback (some through the list, some outside the list) from people who use the tools exactly in the way that we at VMware do. That is, we don't use them. We wrote our own generic command lines, and our own module loading mechanism. The part of scons we reuse is the machinery to convert the environment variables into actual command lines, but we don't use any of the built in variable schema at all. We write our own scanners, and our own builders. CMake should not seek to emulate this business model. Let the SCons guys have it, and let them flounder in it. For pete's sake they're arguing in committee bazaar fashion about how to deploy a stable release cycle. They're way behind CMake in some areas. I'm open to Python, Ruby, or Lua demonstrating something important about scripting languages and build systems, but the SCons crowd seems so dominated by other problems that it doesn't seem all that relevant. They're not proving anything about Python; in fact, they're proving that Python 1.5 is a serious liability over the long haul. It's slow and hard to modify the SCons core. That's another tidbit somewhere in that thread, you can learn tons about SCons from that thread. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
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
Re: [CMake] CMake and Lua
, Lua would seem to be the best fit in terms of its own dependencies and the cleanliness of the language itself. Careful, you may get what you wish for! I've advocated Lua primarily for marketing and documentation reasons. I know, as you do, that lots of people look at CMake script and say, this sucks. One research item I haven't undertaken, is how many people say Lua sucks? Are there things about Lua that drive some users batty enough to jump ship for something else? Is Lua wart-free? Do programmers just like to complain endlessly no matter what the language? Are technical solutions the answer to that problem, or is marketing and documentation a better answer? I think these are questions of degree. I think any of the mainstream scripting languages will be more accepted than CMake script. I caution, however, that if we build it and expect people to come, these sorts of issues may not go away. They may have to be handled by marketing and political means. That's an avenue that the CMake community has put very little effort into. I'm not going to point fingers, as I precipitated the cmake-promote mailing list once upon a time and have done very little since then. Too busy coding like most programmers are. I'm just trying to make a pitch for humanistic rather than technical solutions to some of these problems. Techies tend to overlook anything that isn't tech. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake and Lua = DSL!?
On Sun, Mar 2, 2008 at 2:30 PM, Reinhold [EMAIL PROTECTED] wrote: Hello everyone, Sorry for the quick interruption, but somehow I have the feeling this discussion will start again and again and again, if it has ever appeared to end. Here are my two cents... IMHO there might be a misunderstanding concerning Kitware's CMake strategy: It is a domain specific language (DSL) for -- as this might indicate -- one specific purpose and therefore, by intention, not a general purpose (scripting) language; thus it concentrates correctly on its (single powerful) core task/challenge. An estimated set of 7% of CMake's language commands covers about 97% of the usual cases. (Note that I have not even thought about thinking about this numbers.) Please accept this as an almost completely serious feed to a never ending (?) discussion, When I say the technical merit of Python, Ruby, or Lua over CMake script has not been demonstrated, it is speaking to this very point. Perhaps general purpose scripting *is* provably better for a large scale build, but I would like to see a large scale project that proves that, rather than assuming it. From a marketing and documentation standpoint, standard scripting languages are provably better than DSLs. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Raven, Antwrap, Buildr
http://raven.rubyforge.org/ O'Reilly OnJava.com has a recent article introducing Raven, a JRuby based build tool for Java. http://www.onjava.com/pub/a/onjava/2007/12/05/introducing-raven-an-elegant-build-for-java.html The article is very intro. It doesn't demonstrate any payoffs for using Ruby as opposed to other scripting languages like CMake script. Raven is gaining notoriety in the Java world, however, because it is offering scriptability for the build system where Ant and Maven do not. The end of the article briefly mentions 2 other Ruby-based build tools that are trying to solve Java build problems, with different approaches than Raven. http://antwrap.rubyforge.org/ http://incubator.apache.org/buildr/ I intend to find out if any of these tools have been used for large projects, and if they exist, whether Ruby has demonstrated any remarkable advantages. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Raven, Antwrap, Buildr
On Sun, Mar 2, 2008 at 7:29 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
http://www.onjava.com/pub/a/onjava/2007/12/05/introducing-raven-an-elegant-build-for-java.html
The comments following this article are interesting. For instance, on syntax:
This is just stupid. The Ruby syntax is horrendous. I'd rather use
Groovy than Ruby if I was ever going to use a scripting language. I've
never been stuck using Ant either, it does everything I need.
I've just having a look to Raven and Buildr, Raven seems to be a
little bit hard to read for a Raven /Ruby noob (too many think like
[{' not very undestable when who want to quicly know : what this
project produced, on what it depends on ...).
Sound familiar? Earlier I mused that moving CMake to Ruby would be
more strategic than Lua, if it were only about language sales.
Probably premature! I do recall that Python vs. Ruby is a big split
as far as language taste and philosophy.
What do I have to install to run Ant or Maven vs what do I have to
install to use Raven? - Same old same old about people being too
lazy to download stuff.
Maven tries to manage the build strategy and lifecycle for you. This
leads to the problem of the tool trying to be too clever:
About Maven major drawback, you have often to rethink your process
(deploy,deliver)... because these are not suited to Maven Plugins.
You can create our own but you have to maintain it and I think, this
is bug-prone as Ant...
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Raven, Antwrap, Buildr
On Sun, Mar 2, 2008 at 7:46 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
On Sun, Mar 2, 2008 at 7:29 PM, Brandon Van Every [EMAIL PROTECTED] wrote:
http://www.onjava.com/pub/a/onjava/2007/12/05/introducing-raven-an-elegant-build-for-java.html
The comments following this article are interesting. For instance, on
syntax:
This is just stupid. The Ruby syntax is horrendous. I'd rather use
Groovy than Ruby if I was ever going to use a scripting language. I've
never been stuck using Ant either, it does everything I need.
Another review and tutorial of basic Raven:
http://danielroop.com/blog/2007/08/08/quoth-the-raven-nevermore/
I have to admit, this code snippet pinged my objectionable-syntax-o-meter:
dependency :compile_dep do |task|
task.deps [{'Log4J' = '1.0'}, {'jdom' = '0.9'}]
task.libs Dir.glob('../lib/**/*.jar')
end
I'm a good hacker. I routinely swim through things by monkey-see,
monkey-doo methods if necessary. I don't have to necessarily know
what's going on to use something. But I find myself asking:
- is a :colon in front of something a great idea? From other context
I read, it seems to be a decorator for a symbol. So I guess if you
forgot the decorator, you'd be in trouble. I hope that always throws
an intelligible error.
- why do I have to type |bars| around something?
- why put both [square brackets] and {curly braces} around something?
Is that so we can be terse about minimum versions?
- how, in any universe, could this possibly be preferable to
add_dependencies(target dep1 dep2 dep3...) ?
Only Ruby people are going to see this syntax as an advantage. It's
worth remembering that Ruby got popular not because of the language,
but because of the killer app Rails. This kind of objection, head
scratching, and explanation is noted in the Java universe.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Raven, Antwrap, Buildr
On Sun, Mar 2, 2008 at 9:22 PM, Brandon Van Every [EMAIL PROTECTED] wrote: On Sun, Mar 2, 2008 at 7:29 PM, Brandon Van Every [EMAIL PROTECTED] wrote: http://incubator.apache.org/buildr/ A review of Buildr http://danielroop.com/blog/2007/08/25/buildr-review/#more-50 Says that Buildr is implementing a DSL for builds, it's not straight Ruby. Buildr is an Apache Incubator project. http://wiki.apache.org/incubator/BuildrProposal It is intended to be a drop-in replacement for Maven. It is best to see it as a possible future of the Maven build culture, emphasizing full lifecycle management. It probably rises or falls with Maven, not with its choice of language. At this time, penetration of Ruby within Apache is limited. Buildr is being used to build Apache ODE. http://ode.apache.org/ The sources come in a 4MB .zip file; in short, it's a medium sized project. I don't think Buildr will prove anything about advanced general purpose scripting languages. It could prove something about the wisdom of full lifecycle management in the Maven style, if augmented with a scripting language. The Raven author is listed as a contributor to Buildr. Given the quietness of the Raven community, I wonder if he's bowing to the way the wind is blowing? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake and Lua
On Sat, Mar 1, 2008 at 1:44 PM, Enrico Scholz
[EMAIL PROTECTED] wrote:
Bill Hoffman [EMAIL PROTECTED]
writes:
I find that the CMake script language seems designed to make COBOL
coders feel they don't actually have the worst job in the world.
So what exactly about the CMake language gives you this feel?
* the mix of case-sensitive and case-insensitve language elements
Afair, HTML in 1992 was the last (non-educational) language with
case-insensitive keywords ;)
I'm happy that commands don't need to be ALL_CAPS anymore. It saves
typing and looks better. I don't mind too much that KEYWORDS and
RESERVED_VARIABLES are still ALL_CAPS. Having SYSTEM_CONSTANTS be all
caps is pretty common in other languages, and that's how the
RESERVED_VARIABLES are being used for the most part. I guess that
just leaves KEYWORDS. I see below that you take issue with those,
caps or not.
* no well defined syntax:
- missing datatypes; all seems to be a string. Mastering ';' and
spaces is trial-and-error game :(
Totally agree on this point. It needs documentation. My suggestion
on the matter is http://cmake.org/Bug/view.php?id=6295 Document core
syntax in a chapter format. Feel free to add your comments there.
Perhaps if enough people comment on it, it'll happen. I'd like to
think that comprehensive documentation would alleviate the problem. I
think people could still regard it as warty and type unsafe, no matter
how much it is documented. I would indeed like to have a type safe
list operator. It's easy to use lists in CMake if you know what
you're doing and you're not pushing things too hard; I think that's
likeable despite the liabilities.
parameters
are not delimited e.g. by ',' but start with a keyword understood by
actual macro only.
Is that necessarily bad? If you delimit with commas instead of
keyword tags, then you can mess up the order of the arguments because
you don't remember what order the comma arguments are supposed to be
in. Some languages have named arguments, is that the right
technical term? Anyways I don't think that keywords are particularly
difficult to use in practice. I've probably typed string(REGEX
REPLACE ..) more than any human should though.
- function/macro calls are ambiguous; everything is a string,
E.g. why will
| EXEC_PROGRAM(foo ARGS ARGS foo)
| EXEC_PROGRAM(bar HERE ARGS bar)
| EXEC_PROGRAM(baz ARGS HERE baz)
execute
| running foo foo 21
| running cd HERE bar bar 21
| running baz HERE baz 21
?
Hm. I haven't run into this kind of corner case in my own work, but
that does indeed look troublesome. Perhaps you should file a bug
report on it. I've filed reports for things like, why not have TRUE
and FALSE be actual constants.
* inconsistent behavior across the subsystems (build, install, test);
e.g.
| ADD_CUSTOM_TARGET(test COMMAND echo A=\${A})
| INSTALL(CODE MESSAGE(\A=\${A}\))
| $ make A=a test
| A=a
| $ make A=a install
| A=
There are definitely string argument evaluation level bugs. I
resorted to passing variables rather than strings, so that the strings
can't be mangled. It's definitely uncool, and one learns it from the
school of hard knocks. Again though I think filing bugs about these
things can be helpful. If enough people file the bugs, then the
pattern will become clear, and I imagine things will be addressed.
Either by fixing them or migrating to Lua.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake and Lua
On Fri, Feb 29, 2008 at 12:59 AM, Sebastien BARRE [EMAIL PROTECTED] wrote: Brandon wrote: I'm willing to give Bill some time to think about the undoability of CMake -- Lua translation Great. And by some time you mean someday, therefore 2 years, right. Your style of communication is counter-productive. Here is where a notion of 2 years fits into a sequence of events: 1) Kitware contemplates the wisdom of adding Lua support. 2) Kitware commits to Lua support. 3) Kitware officially releases Lua support, proving their commitment is real. 4) Brandon and/or others attempt to build CMake -- Lua translators. 5) Brandon succeeds in writing a perfect CMake -- Lua translator and contributes the source. 6) Kitware officially releases and supports the translator 7) 2 years later, Kitware adopts you must translate to Lua as official policy. We're still at (1). I'm willing to drop discussion of CMake -- Lua translators for 3 months, to give Bill time to think. *If* I don't hear defeatism on the subject. For instance, the mood a few months ago was Kitware can't support 2 languages. At that time, I proposed automatic language translation because that way, you don't have to support 2 languages indefinitely. I'm pleased that nowadays, Bill thinks that Kitware can in fact support 2 languages indefinitely. I just see it as unnecessary. Especially in open source, I think it is reasonable to make developers do trivial amounts of work to move on, at some point, if the migration tools have been thoroughly tested and proven in the field. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Sat, Mar 1, 2008 at 7:08 PM, Brandon Van Every [EMAIL PROTECTED] wrote: Especially in open source, I think it is reasonable to make developers do trivial amounts of work to move on, at some point, if the migration tools have been thoroughly tested and proven in the field. I did just realize one gotcha however that I hadn't previously considered. *Which* version of CMake would be translated? Writing a translator for 1 or even a few recent versions of CMake is one thing. Trying to be bug-for-bug compatible over the entire history of CMake's development is quite another. There would have to be some cutoff point, where if you want compatibility with a really ancient version of CMake, you have to just use an old version of CMake, and not expect new features or ongoing development. Then again, if translation was proven for CMake 2.4.x forwards, for a goodly number of years, and officially supported, then it could pave the way for translation efforts even farther back into CMake's history. Say, for instance, 80% of the builds out there are translatable because they're sufficiently modern. 20% aren't, and it takes a much longer time to make them translatable. So, it may still be possible, but 2 years wouldn't be long enough to force migrations. More like 5..10 years. On that timescale, it's not that different from supporting 2 languages indefinitely. Even if the support can indeed be terminated in 10 years, it's a lot of time to be splitting the community with 2 languages. It really all depends on how far back the CMake compatibility has to go. A far more likely scenario is, CMake -- Lua translators are used to get 99% of the CMake community onto Lua. The remaining 1% contract with Kitware for their special needs. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake and Lua
On Fri, Feb 29, 2008 at 9:55 AM, Philip Lowman [EMAIL PROTECTED] wrote:
On Fri, Feb 29, 2008 at 8:57 AM, Rodolfo Schulz de Lima
[EMAIL PROTECTED] wrote:
Bill Hoffman escreveu:
So what exactly about the CMake language gives you this feel?
Hi, let me just add my opinion on this one. I really think that in a if
clause, having to repeat the condition in the else, elseif and endif is
a little too much verbose for my taste. The following snippet
illustrates this issue
IF(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR})
set(outofbuild true)
ELSE(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR})
set(outofbuild false)
endif(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR}
I know that we can disable this *feature*, but it isn't default. I know
you did this to help programmers know which 'if' an 'endif' is related,
but this kind of thing is normally done with comments. And in my example
above since each branch has one line, the verbosity is unnecessary.
I wholeheartedly agree. I don't think people realize how unreadable,
unmaintainable, and confusing this feature really is.
It's unreadable because you have to read the same crap over and over again
(occupying at least 3 lines, sometimes 6 depending on how complex the
conditional is).
The problem is, there's an impedance mismatch between short and long
contexts. The repetition is *very* readable and helpful when the
branch is long enough that you have to scan through 20 lines of code
to see what's going on. Would it be a sin to require that if..else
statements more than 20 lines apart have matching clauses? I suppose
that could end up being a PITA for macros expanding within macros, as
the line lengths could easily change. But it's tempting to have one's
cake and eat it too. I don't buy the do it with comments approach.
Something changes, then the comments are wrong. That's why CMake
throws an error when you change a clause and they don't match.
I grudgingly admit that in terms of marketing prejudice, most
newcomers will hate the repetition. I think that's blind prejudice on
their part and that the repetition has technical merit. But I agree
it doesn't have marketing merit.
It's unmaintainable because every time you make the slightest modification
to your original IF() statement you have to modify both ELSE() and ENDIF().
That's not unmaintainable, that's forced maintenance. Compilers give
warnings and throw errors, it's no different.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE by default
On Fri, Feb 29, 2008 at 10:40 AM, Ken Martin [EMAIL PROTECTED] wrote: Will Kitware consider making CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS default to on starting with 2.6.0 and doing away with this annoying construct? Bill is looking into making this implicit. .e.g. if you do not specify the matching arguments then you are using LOOSE_LOOP_CONSTRUCTS by default. So folks who want it will get it, folks who do not will not get it, effectively automatically on a construct by construct basis. I agree that from a marketing standpoint, this makes sense. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Thu, Feb 28, 2008 at 4:08 PM, Bill Hoffman [EMAIL PROTECTED] wrote: I think it is an enormous effort to write a translator. I think translators don't work. It is one thing to convert a word document from one version to another. It is a totally different thing to translate a human written computer language from one to another and have it work. CMake script, by design, is a trivial language. If you actually do implement Lua at some point, then I'll look at CMake -- Lua translation, if it makes business sense for me to do so. I believe other people in the Lua community will also. There are a lot of language translator and metaprogrammer guys over there. They abound in the Lua community because Lua was intended to be an embeddable basis for Domain Specific Languages. Their perspective, and mine, is that CMake -- Lua translation is a pretty easy problem. I mean, the entire syntax of CMake is command(arg arg KEYWORD arg arg ...), what's the big deal? You are missing my point. I think we should respect the people that have picked CMake to build there project, and part of that respect includes not obsoleting there hard work. We are disagreeing on this point because of the first point. You believe that a good enough translator is possible. I do not. I believe an *almost perfect* translator is possible. As perfect as open source software ever is. In fact, given CMake's trivial syntax, I can't think of any reason why it wouldn't be. Can you give me one concrete example of something that would actually be hard? I gave you the only one I could think of: metaprogramming. Almost nobody metaprograms CMake. It's not a corner case worth worrying about. Give me an example of something that people do in the real world with CMake script that would be hard to translate to Lua. Just suppose I am correct and it is not possible to write a good enough translator. Would you then still advocate dropping the cmake language? Of course not. That's why I said the translator would have to prove itself for 2 years. I am not coming up with excuses here, I really really do believe that the translator idea is nonsense. How many times do I need to type it for you to understand that is what I believe? Ok, at this point, I intellectually understand what you believe. You haven't provided much evidence for your belief so far. You've commented that general purpose language translation, such as Fortran to C, is exceedingly difficult. That is true, but we're talking about converting CMake script, a trivial language. You haven't provided an example of something that would be difficult to translate. You agreed that nobody metaprograms CMake script, that that's crazy talk. You are not willing to accept that I have a different point of view. A good enough translator is not possible. You have provided no firm evidence for your point of view, so I will continue to challenge it. That is my position. I am not talking about corner cases here. I am thinking of real world projects like KDE/ParaView/SecondLife/VTK. The thought of translating these large projects with a translator is not one I would appreciate being driven into by the CMake developers. Estimating conservatively, I got 1/2 of the way there with Mozilla. Autoconf + GMake -- CMake is a much more difficult translation problem than CMake -- Lua. I know what is possible. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Thu, Feb 28, 2008 at 5:54 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Just suppose I am correct and it is not possible to write a good enough translator. Would you then still advocate dropping the cmake language? Of course not. That's why I said the translator would have to prove itself for 2 years. So, I guess I will wait until then, and you can prove me wrong... Until then, can you give it a break? Sure. Long as you realize that not everybody shares your pessimism about translators, and that if you do implement Lua support, people will attempt it. Actually I pointed out that you did metaprogram in CMake (in a sarcastic way). Actually, if metaprogramming means generating CMake script dynamically and then executing it, I didn't do that. I just used CMake script as the implementation language for my translator. It could be translated to Lua no problemo. It would still only be an Autoconf + GMake -- CMake translator. I just don't have the time to think about it. I've had 6 months of active work to think about it. Here is one case you have not considered. There exist some IDE projects that generate CMake code like KDevelop. The translator would not help them at all as the CMake code is embedded in C++ or java. There exist cmake code generators. I guess you would say generate, then translate? Sounds like a mess. If CMake went to Lua, presumably these IDEs would want to do the same things in Lua. If not, if the IDE developers don't have energy to bother, then that's an example of 2 languages splitting the community. That's why I think it's important to establish Lua as the primary language, if it is to be done at all. Automatic translation is essential to making Lua primary, otherwise people simply won't do it. You are not willing to accept that I have a different point of view. A good enough translator is not possible. You have provided no firm evidence for your point of view, so I will continue to challenge it. You have provided no evidence that such a thing is possible. Other than you claim that it will be simple. I've written 1/2 of a translator for a much harder problem. There's no conceptual barrier to completing the work, it's only a matter of people's will. Mozilla was just too big a guinea pig for me to finish within the bounds of the contract. No I haven't provided strict evidence of CMake -- Lua translatability, but I've proven the viability of large scale translation in general, even using extremely crude methods. The primary barriers I see to actually realizing a translator are (1) what technical basis should it have? regexes are not ideal. Some in the Lua crowd talk about Lua PEGs. (2) Show me the money. It's a lot of work to provide a 100% translator. I have never seen a perfect translation from one language to another. Can you give me an example of one that exists? I will put it on the backburner as something to inquire about. BTW, You have no idea if you were 1/2 there or not, because you quit. I did not quit. Rather, the contract terminated. I have a pretty solid idea of how much more work needed to be done. You might only be 10% of the way there. The last 10% often takes 90% of the time with software projects. Unless you finish the mozilla translator and build mozilla we will never know. CMake script -- Lua is merely a mapping of syntax. Nothing more. When the contract ended, I had a 95% translation of Mozilla's huge monolithic configure.in to CMakeLists.txt syntax. Semantics are another matter. In the case of Mozilla, a lot more semantic work remained to be done. Autoconf + GMake do not have exactly the same semantic model as CMake. So yes, I cannot be certain how much longer the Mozilla translation really would have taken, but conservatively I estimated I was 1/2 there. I actually believe I was 2/3 there, but as you say, unless someone else picks up the work or decides to pay me to continue, we'll never know. This is irrelevant to the simple problem of translating CMake script syntax to Lua syntax. I don't think you can show me any irreconcilable semantic difference between CMake script and Lua. Given that, in principle, perfect translation is possible. In practice, someone has to do it and it's a lot of work. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Thu, Feb 28, 2008 at 11:41 PM, Sebastien BARRE [EMAIL PROTECTED] wrote: At 2/28/2008 09:06 PM, Brandon Van Every wrote: So, I guess I will wait until then, and you can prove me wrong... Until then, can you give it a break? Sure. Long as you realize that not everybody shares your pessimism about translators, and that if you do implement Lua support, people will attempt it. You've got a deal. I'll make sure to swing by Bill's office tomorrow and remind him about his realization. Let me write that down. On a post-it or something. 2 years break, that's a bargain Bill. On that note, be sure to include actually implementing Lua. If CMake went to Lua, presumably these IDEs would want to do the same things in Lua. That's indeed obvious, these IDEs would absolutely switch to LUA too. Do they have a mailing list? My gut feeling is that they would want to hear about it. Like now. If you are pro-Lua then you can certainly make them aware. I've written 1/2 of a translator for a much harder problem. [...] but I've proven the viability of large scale translation in general, even using extremely crude methods. And by proving it you mean it was never adopted or even finished, and it is actually not translating anything that can build Mozilla. Because if that's the case, I prove it too. It's made of air. I stock it in a jar, but it's at the bottom of a river at the moment. It's one thing to throw stones. It's another thing to actually attempt it, and get pretty far to making it work. Finish schminish. I finished Chicken Scheme's build, to a professional level, and it got thrown out anyways. People either want to make something happen or they don't. There is no technical barrier to this, only a labor barrier. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Fri, Feb 29, 2008 at 12:11 AM, Sebastien BARRE [EMAIL PROTECTED] wrote: At 2/29/2008 12:03 AM, Brandon Van Every wrote: You've got a deal. I'll make sure to swing by Bill's office tomorrow and remind him about his realization. Let me write that down. On a post-it or something. 2 years break, that's a bargain Bill. On that note, be sure to include actually implementing Lua. Again: *deal*. February 29th, 2010 *precisely*. Special CMake/Lua day, the 29th. Or No Deal. 2 years is a number you've inappropriately reused from an unrelated context. I'm willing to give Bill some time to think about the undoability of CMake -- Lua translation. Over time, his position has moderated on Lua itself, so perhaps the same will happen with regards to translation. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Removing cmake as a dependancy
On Thu, Feb 28, 2008 at 11:54 PM, Kevin Tucker [EMAIL PROTECTED] wrote: Is there an option in cmake for it to leave itself out of the projects/makefiles that it generates? There is, but I don't know how much tire kicking it gets, nor have I ever used it. Someone who knows better can answer this one. CMake is definitely not designed around this case use, it's designed around being part of the build. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Wed, Feb 27, 2008 at 4:34 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Also, backwards compatibility is something we take very seriously. If someone picks CMake as a build tool, we have to respect that choice and try our best not to break that project. There are very large projects that have many lines of CMake code in them. People have put a great deal of effort into creating those files. If they don't have the time to re-write in a new language, I don't blame them. This is why I think an automated translation tool, say from CMake script -- Lua, is essential to a migration strategy. I also won't try to force them to do it, by obsoleting the current language. I think if the automated translation tool had proven itself for a couple of years, it would be perfectly reasonable to force people to move on. So there is still that 2 year window of supporting 2 languages. So, we might have two official languages someday, but no more than that. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Python installation files on linux
On Wed, Feb 27, 2008 at 1:32 PM, Cedric Pinson [EMAIL PROTECTED] wrote: Hi, i am new to cmake and i would like to use it to make a python module, but i don't know how to get the version of python installed on the system, Such questions are specific to whatever tool you're trying to determine the version of. Sometimes you can get the version of a tool by running a command on the command line. In that case you execute_process with whatever the tool requires and deal with the output however you like. You might, for instance, do a string(REGEX REPLACE ...) on the output. Sometimes the version of a tool is contained in a .h file. In that case you'd use try_compile and write some C preprocessor commands to capture the output. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Wed, Feb 27, 2008 at 5:37 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Brandon Van Every wrote: I think if the automated translation tool had proven itself for a couple of years, it would be perfectly reasonable to force people to move on. So there is still that 2 year window of supporting 2 languages. I have yet to see a auto-translate tool that works 100%. I do not believe that they exist. I guess there is f2c, but I am sure there are corner cases that fails on. That's 2 cantankerous languages and a rather general problem domain. CMake script is a rather limited language. Not that hard to map it to Lua. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Wed, Feb 27, 2008 at 8:58 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Brandon Van Every wrote: That's 2 cantankerous languages and a rather general problem domain. CMake script is a rather limited language. Not that hard to map it to Lua. I don't know, I have heard about people using CMake for a general purpose language :) I don't think I have any idea what every single project using CMake is doing with the language. Only thing problematic I could see, is if someone's getting clever and using CMake script to generate CMake script. I think it would be reasonable to make such people untangle their metaprogramming. It would be much safer and easier to continue to support it in the core of CMake. It's 2x work to support CMake script and Lua indefinitely. I just don't believe that translation can work, and the fun part is that it can't even be proved that the translator works 100% of the time... That's not a realistic concern though. You will either decide to move on to Lua or you won't. Any amount of excuses can be invented if you aren't willing. That's how I lost the Chicken Scheme project BTW. Lotsa excuses about how the CMake build wasn't ready or was buggy for some reason, even though it proved itself in the field for 6 months without any real problems. Certainly no more problems than anyone has with a near-perfect build maintained in any language over the same time period. The Chicken Scheme author simply didn't want to get his hands dirty with CMake. He also tended to call every other piece of open source software buggy, except for Chicken Scheme of course. If I learned nothing else from that project, I learned about political will. There are technology problems and there are political problems. I can't solve those here. I can only agitate in a certain direction, point out what is possible, and knock down perceived barriers. I hope that in coming years you will consider the various technical merits and demerits of Lua. Perhaps someday, it will become your idea. Then you'll be more interested in automatic translation. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Re: IF( ${VAR} ) behaviour
On Mon, Feb 25, 2008 at 10:16 AM, Mehdi Rabah [EMAIL PROTECTED] wrote:
Hi,
Me and a work friend ran into the same problem a few days ago. May I suggest
to the admins to add a little note in the IF doc about this common mistake ?
Generally best to file such suggestions in the bug tracker as
{document, text} bugs, along with the exact words you think should be
used.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Feb 25, 2008 at 2:06 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: After having seen some presentations at FOSDEM, I'm even more convinced that having only limited programming functionality available in build files is a good thing. What in particular confirmed this opinion of yours? I did not attend, but I read the schedule and noticed there were presentations for both CMake and SCons. Was it something the lecturers said? Audience questions? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Feb 25, 2008 at 2:22 PM, Peter Kümmel [EMAIL PROTECTED] wrote: Then it is only possible to provide a C++ interface so that all the module stuff works behind the scene (behind the interface), using one scripting language only. And if a new module should go upstream it must use this language. But all official-shipped modules could be made accessible through the C++ interface, so that one still could call the generator functions from a other language. So, anyone who doesn't like the official CMake language, would have no incentive to contribute features to standard CMake. This is a form of community fragmentation. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake and Lua
On Mon, Feb 25, 2008 at 2:50 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote: Alexander Neundorf escreveu: The build system should provide what you need without requiring that you actually need to program something. I think this statement is true regarding the most common building use cases. But the build system should not limit what you can do in more elaborate building situations, or turning it into a difficult and verbose task. Using a more powerful script language doesn't imply that the build script will be more complex. It can be quite the opposite, IMHO. I'd like to see practical examples of such complexity requirements, that get solved by more powerful scripting languages. It seems this kind of proposition is usually made in a vacuum, out of a theoretical fear. I've made some effort to get out there and try to understand other build systems, but I'm too lazy to really really keep searching for this. I do know that every time I've asked so far, nobody's offered it. I hope I can goad someone into delivering the goods. I'd like to see a tangible demonstration of why the scripting technology matters. I've also concluded that for small to medium sized projects, of 100K lines of code or less, the build system technology is irrelevant. There's not enough of a build to worry about far-flung complexity requirements. Case in point: Chicken Scheme was a 70K LOC project. It had complexity disproportionate to its size because it was a bootstrapping compiler, with lotsa Scheme stuff driven by add_custom_command. Once the Chicken author got tired of having to learn anything about CMake, and once I got tired of his attitude, what did he do? Dumped MSVC support, dumped CMake, dumped Autoconf, and went back to handwritten Makefiles. Pretty reasonable approach if you don't care about MSVC. From a complexity standpoint, I don't take the opinions of small-to-medium sized projects seriously anymore. They have a perceived need to do anything imaginable, because they don't actually know enough about build systems to know what's really required. Small-to-medium sized projects are a documentation and marketing problem, not a technical problem. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Feb 25, 2008 at 3:14 PM, Peter Kümmel [EMAIL PROTECTED] wrote: Pau Garcia i Quiles wrote: One Language to rule them all, One Language to find them, One Language to bring them all and in the compiler bind them. Nice, but wasn't the One destroyed? ;) Actually, all of the rings lost their power at that time. Analogously, we'd forget about build systems and go into the West. We could speculate about who's the Dark Lord. By my demeanor I am surely an Uruk-hai captain. -) Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Feb 25, 2008 at 5:14 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: On Monday 25 February 2008, Ken Martin wrote: ... OMG flame war Bring it! :) How about: everybody should use Ruby, because all other languages suck ! ;-) Ruby's license sucks. The price of Ruby's nice language features is that it's slow. Anyways, if someone could explain to me why Rake matters, I'd listen. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Mon, Feb 25, 2008 at 5:15 PM, klaas.holwerda [EMAIL PROTECTED] wrote: Ken Martin wrote: Which is why CMake has include, macro, foreach etc. which are all staples of a programming language. Right, much better to spend time on something else, and use Lua for all these things. Historically, that would have been true, at CMake's beginning. I don't see why it is true now. The Kitware team is experienced with the CMake codebase and hasn't shown much evidence of employee turnover. I don't get the impression that they've spent tons of energy adding the recent scoping and function support. Seems like their approach is cost-effective as compared to ripping everything up to stick Lua in there. Add wxLua , and the graphical interface becomes easy too. I thought CMake had a wx frontend at some point. If it didn't go anywhere, it's from somebody's lack of follow-through, not a language barrier. Lotsa people do wx from C++. CMakeSetup is nice, but i can't organize options the way i want. Customizing the GUI for your purposes doesn't benefit the off-the-shelf CMake community. If we try to teach everyone how to use the standard GUI and you've done something completely different, then depending on how different you made it, it might not be worth calling it CMakeSetup. On the other hand, if you are wishing for modest customizations, put your specific ideas on the mailing list, see if others agree, make a feature request, etc. Such features do tend to get done, if there's a clear case for how they benefit people and they're doable. So would it be possible to make some hybrid kind of Cmake, which makes it possible to slowly migrate. Sure. You personally could make it right now. Getting Kitware to agree to some kind of future path and halfway house is a whole 'nother matter. I don't think such a migration can be slow. The slower it is, the longer everyone is overburdened with supporting 2 scripting languages. I think a migration needs a language translator, so that builds can be migrated quickly to the new, preferred, standard language. CMake script -- Lua translation is certainly doable, but someone would have to do it, and it would be real work. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Tue, Feb 26, 2008 at 2:12 AM, James Mansion [EMAIL PROTECTED] wrote: Ken Martin wrote: other's variables out of the box. But with the Modules directory we either have to have a copy of each module for every possible scripting language, on the fly converters between any two scripting languages, or something like that to make it work. Trying to figure out how to manage the mixed Surely the idea is that modules should be self contained: they expose data by registering it into the CMake core (possibly with callbacks) and interface to other modules through the core. Modules can be in different languages without the issue you indicate (or, the modularity is poor and the binding too tight). Seems like an invitation to polyglot development. I regularly have to read the contents of modules to find out what they do. I suppose for me personally, it wouldn't be a dealbreaker to have to read the raw code of FindXXX in 7 different languages. However, it would make it a PITA to install and build CMake, with all the different languages that would have to be present to facilitate it. Not all systems are Linux, it isn't a given that all the languages are packaged and nicely pre-deployed. I also suspect that the majority of developers would be less forgiving about the scattered, haphazard quality of the documentation that would inevitably result. Mr. Miyagi from The Karate Kid said something like, better to know 1 kick well. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Sun, Feb 24, 2008 at 8:03 AM, E. Wing [EMAIL PROTECTED] wrote: Apple introduced a second completely independent framework called Carbon, but they told people they should use Cocoa to get first-class looking applications. Kitware + the CMake community do not have the resources of Apple. Cocoa is by far the superior framework, but many developers unfamiliar with NeXTSTEP or new to OS X refused to touch Cocoa because they didn't want to learn Objective-C. Lua is significantly more popular than Objective-C even today. http://www.tiobe.com/index.html?tiobe_index Find me evidence of people who refuse to touch Lua. Trying to please everyone by technical means will result in marginal gains in popularity. A marketing campaign would get a lot more bang for the buck. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Sun, Feb 24, 2008 at 12:36 PM, E. Wing [EMAIL PROTECTED] wrote: Again, you missed the point entirely. This isn't about Obj-C vs Lua or any other languge. The point was that by providing a language bridge, the whole language wars argument gets thrown out the window. So are you going to write this framework for us, that makes all the work of supporting multiple languages magically go away? People who want to use CMake (the project generator) should be able to decide for themselves what language they want to write in. No they shouldn't. They can pay for that kind of support. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Sun, Feb 24, 2008 at 12:56 PM, E. Wing [EMAIL PROTECTED] wrote: On 2/24/08, Brandon Van Every [EMAIL PROTECTED] wrote: So are you going to write this framework for us, that makes all the work of supporting multiple languages magically go away? If you bothered actually reading my comments, you might have noticed the paragraph where I said it's not immediately obvious how to refactor these things. But by finishing the Lua integration, I believe there is a chance this will become more clear, and one of two things will happen. 1) It becomes obvious how to refactor things so people can write their own language bridges. 2) It becomes obvious refactoring is not so easy, and the way to bridge is directly through the Lua runtime, similar to how Obj-C/Cocoa is bridged. It's lotsa extra work to support lotsa extra languages. We've all got things to do, we're not made of time and money. Selling people on a Lua migration is difficult enough as it is. Why don't you concentrate on *that* agenda, before bothering with even loftier stuff? People who want to use CMake (the project generator) should be able to decide for themselves what language they want to write in. No they shouldn't. They can pay for that kind of support. That's a nonsensical statement to me. The point is, they can either implement the multi-language support themselves, or pay people to implement it for them. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
Hopefully other people will spend time debating the merits / demerits of this, as people have gotten sick of hearing me talk about CMake and Lua as of late. I'm happy that my irritance has caused people to continue to discuss the possibilities, however. I will make one point: On Sat, Feb 23, 2008 at 6:20 AM, Peter Kümmel [EMAIL PROTECTED] wrote: If only this is done, nothing is won. But with this layout, it would be much easer to use other scripting languages. With this architecture you don't have to definitely exclude all other scripting languages when choosing Lua as additional new language. I am not seeing the merit of trying to support multiple scripting languages. This fragments CMake into many sub-language communities. Who would handle all the inevitable bugs? It's many times the work of maintaining a quality implementation with 1 scripting language. It wouldn't get handled, so CMake's reputation would suffer because the Python implementation isn't so good or whatever. How do I advise someone who's using a different language? I can't just show them working code, I can't just tell them to file a bug report with a trivial reproducer. I have to understand their language, or tell them how to abstractly solve the problem, or just punt. Not all scripting languages have nice licenses. For instance, Ruby has a somewhat onerous Artistic License, compared to CMake's BSD license. Most of the languages other than Lua are somewhat bloated, both in terms of execution size and speed. In short, I do not see value in trying to be all things to all people. That's an expensive way to do business. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Get the drive from a path
On Thu, Feb 21, 2008 at 6:51 PM, Neal Meyer [EMAIL PROTECTED] wrote: On windows I need a way to get a drive letter from a path. Does anybody have any tricks for doing this? Not a trick: string(REGEX MATCH ...) Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] FindXXX, XXXConfig and UseXXX
On Feb 18, 2008 3:34 PM, Fernando Cacciola [EMAIL PROTECTED] wrote:
XXXConfig.cmake should ...
FindXXX.cmake shoud ...
UseXXX.cmake should set include directories, libraries, compiler and linker
flags, etc, based on the settings defined in a XXXConfig.cmake that must has
been processed already.
I've yet to use any of the current UseXXX modules. I looked at the
source for one of them. All they're doing aside from the usual
FindXXX stuff is defining some macros, which you can choose to call or
not call. I don't see a point in breaking all this functionality up
into 3 different include files. 1 is fine; you choose to call
whatever macros you want to call.
XXX users would load XXX in their own programs via:
find_package(XXX)
if ( XXX_FOUND )
include( ${XXX_USE_FILE} )
endif()
What's wrong with:
include(findXXX)
if(XXX_FOUND)
someXXX_macro(whatever)
endif(XXX_FOUND)
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: function and raise_scope commands (+ unset bug)
On Feb 16, 2008 3:48 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: Any opinion whether RAISE_SCOPE/PARENT_SCOPE should propagate to the parent directory if it's used outside a function ? What if I do want a variable to propagate up through nested functions functions, but I don't want any such functions to be passing info up to a parent directory? Function scopes and directory scopes strike me as being orthogonal concepts. I think it's a very bad idea to be overloading orthogonal concepts. It creates corner cases that frustrate users, and it's not very much like what C/C++ programmers are used to. I want scope in CMake, but I don't want it introduced in such a way that it causes people to hate and curse the language. PARENT_DIR would be an appropriate keyword if you want to assign values that the parent directory picks up. It's much more self-documenting. It could be a keyword in addition to PARENT_SCOPE. I have to admit, PARENT_SCOPE nomenclature bugs me. I don't know of any mainstream programming language that explicitly asks me to think about scope when setting a variable. It has an extremely clunky feeling to it. Even if it turns out to be practical, CMake script does have an image problem. Keywords that don't exacerbate it would be better. I can't quite think of what PARENT_SCOPE really means to do, if parent directories are taken out of the equation. Maybe because it's almost 5 am. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: function and raise_scope commands (+ unset bug)
On Feb 17, 2008 6:01 AM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote: As a reminder, here comes the nomenclature in Ruby: Scope Prefix Example - -- --- global variable $$global instance variable @@instance local variable lowercase or _ local constantuppercaseConstant class variable @@ @@class_var Could be viable. Notice that none of your descriptions use the word 'scope', nor do they talk about parents. Well when I'm more awake I'll think about the wordsmithing. I keep wanting to work the word 'call' or 'caller' in somehow. If you're altering the caller's variables, why not talk about the caller? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] add docbook support for cmake documentation
On Feb 17, 2008 2:13 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: attached you can find a patch against current cmake cvs which adds support for generating the documentation as docbook file. Interesting. I started going up a learning curve recently about technical documentation formats, thinking about what would allow for incremental documentation of CMake in the real world. I found a nice chart of different formats available. http://en.wikipedia.org/wiki/Comparison_of_document_markup_languages The main competition to docbook seems to be Darwin Information Typing Architecture (DITA). They're the new kid on the block, which probably has advantages and disadvantages. They're interested in modular reuse of documenation, but I'm not sure yet if that translates to easier incremental development for open source communities. There seems to be a whole industry of massaging industrial documents, i.e. people make money at this. Indeed there's some moaning from the docbook side about DITA consultants selling new bells and whistles and whatnot. :-) Anyways, the consultant talk does make me realize that there are cultural problems with getting people to write docs, even when people are paid to write docs (unlike here). Here's a semi-illuminating article on docbook vs. DITA. http://norman.walsh.name/2006/03/24/dita2006 If nothing else you should read it just to understand what docbook thinks it's on about. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] can't build CMake CVS
Windows Vista, with the free VC8 compiler, using CMake 2.4.8 as the build tool, trying to build CMake CVS I get: error LNK2019: unresolved external symbol wchar_t * __stdcall _com_util::ConvertStringToBSTR(char const *) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) referenced in function public: __thiscall _bstr_t::Data_t::Data_t(char const *) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z) CMakeLib.lib Windows Vista, with the free VC8 compiler, using CMake 2.4.8 as the build tool, building CMake 2.4.8 works fine. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Feature list
On Fri, Feb 15, 2008 at 10:36 AM, Sylvain Benner [EMAIL PROTECTED] wrote: I am sure I have left stuff out. Please edit the wiki or send me an email with any cool features that you think are missing from the list. The script ability of CMake may be worth to be added to the list of cool features. Something like complete scripting language. It's a feature I'm using a lot to do some additional stuffs based on the bunch of information provided by the CMakeLists.txt. Guys, guys, read the list and add it yourselves! It's a wiki. We don't need discussion here. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] can't build CMake CVS
On Fri, Feb 15, 2008 at 11:04 AM, David Cole [EMAIL PROTECTED] wrote: If you comment out (or remove) the line: #define HAVE_COMDEF_H ...from the top of CMake/Source/cmCallVisualStudioMacro.cxx, does the problem go away? Yes, that cured it. Is this a Vista-specific issue? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] can't build CMake CVS
On Fri, Feb 15, 2008 at 12:02 PM, David Cole [EMAIL PROTECTED] wrote: No. It could be a free VC8 without the Windows SDK issue, though. I have a Windows SDK... hm, wait! On Vista I have *two* SDKs, the current one and an older one for Windows Server 2003 R2. I was using the latter to build Mozilla, it doesn't build with the current SDK. Well, that project is over, so I suppose I should realign my system to sanity. Have you built anything else that would require linking in the Windows SDK libraries? CMake 2.4.8 builds CMake 2.4.8 just fine. Is comutil.h new to CMake CVS? If so, I bet it won't build with a Windows Server 2003 R2 SDK and free VC8. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Feature list
On Fri, Feb 15, 2008 at 12:32 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Brandon Van Every wrote: On Fri, Feb 15, 2008 at 9:59 AM, Bill Hoffman [EMAIL PROTECTED] wrote: http://www.cmake.org/Wiki/Really_Cool_CMake_Features I think the feature list is already adequate as a pitch. It can be improved, but by putting it front and center in people's minds, it is likely to improve faster. Actually, I made it a bit obscure because I was hoping to flesh it out before putting it at the top of the wiki. I guess the list is OK as is. It is, considering the quality of the rest of the wiki. The problem is there are so many little things that cmake does automatically that actually have lots of work behind them that people don't realize. I do agree that getting people to focus on what the *build tool* does, rather than all the bitching and moaning about syntax corner cases, is a good strategy. The syntax corner cases are a real problem, and they do need good documentation to resolve the problem. But people shopping for build tools focus on them way too much. They know languages and they don't know build systems. They don't have that much of an idea what they're gonna need out of a build tool, or how far ahead CMake is compared to other tools. Eventually, I will move the list or parts of it from the wiki to the main web page. Better to just keep the list where it is, and copy the best points to the main web page. On a main web page, you have limited time to make your pitch. The pitch shouldn't be everything and the kitchen sink. Or if you are going to do a kitchen sink feature comparo, it should be in a professional looking table of columns with bullets and checkboxes and nice managerial looking stuff. Another presentation format is author's top 10 cool features, such as in this VS .NET article: http://msdn.microsoft.com/msdnmag/issues/02/10/NETTopTen/default.aspx But that would imply an ecology of people writing articles about CMake on a regular basis. Another reason we might not want it at the top yet is that I am listing CVS features as well as 2.4 stuff. Be a good marketer. List them anyways. You're pretty close to CMake 2.6, you're not exactly fleecing people to be doing so. How are they gonna know? Let 'em download it and do an eval. If they come up short and squawk on the mailing list, that's perfect, you can jump to their rescue. If they come up short and never touch the mailing list, that's a different problem. One that I don't think is solved by any number of feature lists. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake Feature list
On Fri, Feb 15, 2008 at 9:59 AM, Bill Hoffman [EMAIL PROTECTED] wrote: http://www.cmake.org/Wiki/Really_Cool_CMake_Features This is really important (good idea Bill) so I linked it as the 1st item under Primary Resources. In other words, almost the very 1st thing you'd look at on the wiki. I figure, rather than expecting people to just download CMake and start playing with it, it would be a good idea to give them a feature list, so that they become interested and actually download. I also redrafted the introductory statement to sound more confident and professional. It would be good to sort the list as time goes on. An unsorted list will do for now, but we don't need to be calling attention to the fact that it's unsorted, that sounds amateurish. I think the feature list is already adequate as a pitch. It can be improved, but by putting it front and center in people's minds, it is likely to improve faster. The intro now explicitly directs people to extend the list. I hope you all can live up to the standard of enumerating features that make CMake a joy to program with. :-) That word joy is certainly a two-edged sword, but I suggest we keep it for now and see it as the mission statement. Can we craft a feature list that actually justifies and validates the use of the word joy? That appears professional and not a pile of self-inflated malarky? Even if some cantankerous yet well-informed soul takes issue with the word in the sense of, Oh JOY (not), the feedback can only stimulate the CMake community and increase CMake's notoriety. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] @MY_VAR@ are replaced by empty string !
2008/2/13 Martin Lütken [EMAIL PROTECTED]: SHORT: It's seems impossible to contruct a string containing something like this: @MY_VAR@. The whole thing gets replaced by an empty string regardless whether the MY_VAR variable is set or not. Well, I'm not sure I've resolved your bug, but I found a bug. If a cmake -P myscript contains a configure_file and attempts to execute it, it dies with a bizarre error about CMake not being built correctly. The cmake -P docs do say that a script executed in this manner does not have any configuration step or cache. However, it's not reasonable for it to die with the error it's giving. I've filed bug http://cmake.org/Bug/view.php?id=6337 cmake -P crashes on configure_file. Are you using cmake -P or a CMakeLists.txt? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] ADD_CUSTOM_COMMAND Bug
2008/2/13 Malhotra, Anupam [EMAIL PROTECTED]: Please notice that $(IntDir) is automatically changed to $(IntDir) in the actual post build setup. Can anyone please tell me if this is a bug in cmake? Looks like a bug to me. File it. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Quoting, spaces in include paths, CMake input files generation, life, the universe and everything.
On Feb 12, 2008 11:25 AM, Nicolas Tisserand [EMAIL PROTECTED] wrote:
According to:
http://www.cmake.org/Wiki/index.php?title=CMake_FAQ#How_can_I_get_quoting_and_escapes_to_work_properly.3F
Yeah, my lousy stub of a FAQ entry. Well, I've filed bug
http://cmake.org/Bug/view.php?id=6295 Document core syntax in a
chapter format. I suggested the idea of reusing info from the
current edition of Mastering CMake, but that suggestion has not been
favorably received.
I first tried to be creative and played around various levels of
quoting, before or after the Use*.cmake file configurations, without
success.
I also tried the ESCAPE_QUOTES option of the CONFIGURE_FILE function.
No luck either.
I now need some world class CMake guru wisdom...
Any thoughts?
I hypothesize that when configure_file is performed, the single
backslashes that escape the whitespace are lost. \ turns into .
If you were to string(REPLACE \\ out ${in}) for all your
paths before performing the configure_file, I think you would solve
the problem.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Mozilla and automatic Autoconf + GMake translation
Mozilla has made public the code I worked on for them. https://bugzilla.mozilla.org/show_bug.cgi?id=416982 It is an incomplete Autoconf + GMake -- CMake translator. It was designed to translate the stuff that appears in Mozilla's 400MB source code tree. It hasn't been tested against their entire tree, only the against the largest, worst files in their tree. It is possible that the translator may work on non-Mozilla code. I'm willing to advise anyone who wants to try to get the code working for their own purposes. Bear in mind, Mozilla holds copyright on this work, not me, as it was a Work For Hire. Mozilla has not put a license on the code, they just made it publicly available. So if you do choose to use it, be advised that Mozilla may exert a license other than public domain for it. I do not know if Mozilla is still interested in migrating to a CMake build system. I was unable to complete it for them. Volunteer open source developers could probably complete it, however. The translator is a big step in the right direction for tackling such a large build tree. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem in ADD_CUSTOM_COMMAND
On Feb 8, 2008 6:35 AM, Sylvain Benner [EMAIL PROTECTED] wrote:
SET(CMAKE_COMMAND copy \${vpcl_path}\ \${PROJECT_SOURCE_DIR}\)
ADD_CUSTOM_COMMAND(TARGET vpcl POST_BUILD COMMAND ${CMAKE_COMMAND}
VERBATIM)
I think you have forgot the ARGS argument
ARGS is old school. Not necessary anymore.
I think someone forgot to convert the paths to native Windows paths.
Use file(TO_NATIVE_PATH path result)
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Wee question about CMake developer etiquette
On Feb 10, 2008 3:05 AM, Sebastien BARRE [EMAIL PROTECTED] wrote: If, as I suspect, somebody is posing as a CMake developer and acting in an unprofessional manner, then you should point out the problem (and culprit) to us. It was me. Can't say I've ever ticked people off on a mailing list, been called to account by 1 person in private, resolved that with a degree of politeness, let the thread die, and then had that person follow me around the internet to other venues. Kien-Hong Man, I don't speak for CMake, I speak for myself. If I ever used the word we, I meant the CMake community. In context it was probably appropriate. You are showing an unwillingness to agree to disagree, and you are forgetting your own statement that I mean well. Do you mean well? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Wee question about CMake developer etiquette
I apologized on the Lua list. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Wee question about CMake developer etiquette
On Feb 10, 2008 10:54 PM, KHMan [EMAIL PROTECTED] wrote: Brandon's postings certainly gave me the impression that he was partly in charge in some manner. As I said previously, I do not speak for CMake. I understand why you had the impression: I speak forcefully, I currently value CMake over Lua, I spend too much time arguing the merits and demerits of build systems rather than discussing Lua, I'm capable of zealously, and I used the word we at least once to indicate that I am a part of the CMake community. I apologized for my zealousy, particularly with respect to hobbyists, whose contributions to Open Source I have undervalued. None of this, however, makes me a Kitware developer, and I have never claimed to be such. You are very protective of your Lua community. You are also aware that I am not the only source of flames in that community. I think you need to accept that in an open source culture, people will debate issues and they will disagree with each other. Sometimes in flaming fashion. Thus, someone who is under the impression that a CMake lead developer did jump into a public mailing list of another project and said the things he did, would be extremely concerned about whether the CMake project is led by good leaders or not. For the record, Bill Hoffman is a political saint. You could never have a man with more diplomatic aplomb. Moreover, CMake is led by a company and is a project of which I have heard a lot of good things about so far, so this episode is even more unusual and shocking in that sense. I do not know what the right strategy is for promoting CMake. I am not skilled at making people feel good about things, and I find discussion of CMake vs. Premake vs. Bou very, very frustrating. Premake and Bou are both Lua-based. They eschew CMake, and they eschew each other! One of the ongoing conundrums of Open Source is the duplication of work. The most famous split is probably GNU Emacs vs. XEmacs, it was very bitter. It is probably premature to condemn Premake and Bou as hopeless cases of Not Invented Here. It is probably better to look at them as experiments. Lately I've been trying to learn about such experiments, to see if they're smarter than we (the CMake community) are. I am encouraged that at least in some Open Source communities, authors of similar tools sometimes do combine efforts to make a better, single tool. This has happened with JRake and Raven, 2 build tools inspired by Ruby's Rake build tool. http://offthelip.org/?p=44 So Brandon explaining his behaviour with the phrase I mean well is immaterial. It was your explanation, not mine. I agreed with your explanation. I think your choice of words is material. You have also sought to explain me as Machiavellian. I acquiesced to that explanation in order to bring peace. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] converting VS projects to CMake
On Feb 9, 2008 6:43 AM, Sylvain Benner [EMAIL PROTECTED] wrote: First of all I want to clarify some points: I talk only about large scaled development projects I think large scale projects are the only ones worth going after. Medium-to-small projects, like 100K LOC or less, don't need enough of a build system to be especially committed to CMake. They'll drop stuff on a whim, due to laziness or a change of project members. Large projects need ongoing stability, it's not easy to replace the build. What do you mean by framework? A framework is all the stuff which is not just a conversion of a project file (vcproj, makefile, or whatever) to a working CMakeLists.txt. This stuff drives all the CMakeLists files which cannot live otherwise. Converting this kind of stuff hiding in a vcproj file is impossible to do. I'm not sure what you mean. Are you talking about stuff that's destined to become an add_custom_command? For big projects with dozens and dozens of project files, the issue is: it will not work 100% for me and I don't want to search for the xx% that does not work. You may not want to, but for any build system conversion, you have to. To me, the goal of a preliminary translation + cost estimation framework, would be to clearly demarcate what does and doesn't work. Probably best to give some stats on that too. X% translated. Also the translation framework has to allow for incremental progress. Like, I've got an 80% translation, and to bring it up to 83%, I add several functions that fire off in a pipeline. My advice for somebody who needs to convert a big scaled project running on MSVC: Focus on CMake, don't cut the learning steps and start with the beginning is a lot more valuable. Eventually use/write/script some basic export tools to help you in your process. Training and mastery is often perceived as taking too long though. I think CMake would be a lot better off if it could say, Hey presto here are some results! Enough to make people realize that their conversion isn't hopeless and imponderable, that all they really have to do is dive in and clean up the translation output. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] converting VS projects to CMake
On Feb 9, 2008 7:32 AM, Sylvain Benner [EMAIL PROTECTED] wrote: Training and mastery is often perceived as taking too long though. I think CMake would be a lot better off if it could say, Hey presto here are some results! Enough to make people realize that their conversion isn't hopeless and imponderable, that all they really have to do is dive in and clean up the translation output. That's a good point, it can be a tool for training and learning CMake but if the converted projects files does not work it can also be unmotivated. And if you do everything by manual labor and you run out of time and budget, that's unmotivated. Enough with the unmotivated. Let's get motivated! CMake's Killer App would be a build conversion evaluator that gives hope to the project, and incrementally leads to a full translation. That is the vision. Do you want to help with that or do you want to leave me to figure it out? Maybe it is better to talk about an export tool instead of a conversion tool. Conversion implies it should work after conversion, if it does not work I probably delete this tool from my system. Expert tool, conversion tool, slick nonsense marketing campaign, brilliant whitepaper, I don't care. Whatever works. I take all preferred technical terms under advisement. Do you understand what I'm getting at? You've been around the block with a ponderous build, surely you've got an inventory of ideas about how these behemoths go, how you could better present the job to the client, and how you could better manage the risk of it succeeding or failing. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] converting VS projects to CMake
On Feb 8, 2008 11:30 AM, Jesper Eskilson [EMAIL PROTECTED] wrote: Brandon Van Every wrote: Someone asked me the other day why CMake doesn't do this. I thought I gave him a reasonable answer, that it would be painful to do, and that CMake -- native is a much easier problem than native -- CMake. But I said I would ask here for other people's opinions on it. I have experience converting a large Autoconf + GMake project to CMake. At the time I used piles upon piles of regular expressions. I can think of more sophisticated ways to do the parsing and translation. But no matter what technology is chosen, it's a lot of work. I'm sure the same would be true for MSVC, plus MSVC changes its format every few years. Does MSVC pose any other special difficulties, other than sheer mind-numbingness of translation? Having written a naive ruby-script which does little more than just extract the source files for you, there a number of difficulties. For example: - Handling post/pre-build commands. - Handling file-specific options/settings. Getting to 95% is probably doable with a lot of (mind-numbing) work, getting to 100% is probably impossible. There is always another pathological case one wouldn't be able to handle. Recently I tried to tame an Autoconf + GMake build that had a 400MB monster of a source tree. I got close. I was able to conquer nearly all syntactic problems for that particular source pool, but I ran out of time to deal with the semantics. For instance, there was a lot of tweaky stuff done on the CC and CXX variables. This is contrary to the CMake model, where the compiler is frozen when you select a generator. There were some other semantic issues; Autoconf, GMake, and CMake have a lot of semantic similarities, but there are some differences that require extra work to redo. I'm sure it's similar with MSVC; in fact I wonder if it's a lot worse with MSVC. I believe that for large projects, the conversion strategy needs to assume that it'll be unable to automagically translate everything. It would be better to present a report of what's converted and what still needs to be converted. This would help greatly in estimating the manual labor of projects. I don't think I'd try to estimate a large conversion project again without such a tool. I have some interest in developing an open source framework for such a tool, maybe call it the BaseParse project or some such. I'm ambivalent about trying to develop fullblown translation tools for free. It's exceedingly labor intensive, which means it's exceedingly expensive, which means I gotta eat and I don't like working for months and months for free. But perhaps a common framework that deals with some really basic capabilities, that all consultants and would-be CMake initiates could start from, would be of value for spreading CMake. It would be very helpful if we could tell the world how easy or difficult their build conversions are likely to be. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] converting VS projects to CMake
On Feb 8, 2008 1:14 PM, Sylvain Benner [EMAIL PROTECTED] wrote: A convertion tool to CMake is not doable for large projects, because large projects need a framework to be viable. So migrating to CMake implies making or migrating to a new framework. A conversion tool could provide you with working CMakeLists.txt but you will lack a framework around them. What do you mean by framework? To me this is just a word. I don't understand what you're saying a big project has to have. The project I worked on was monolithic. Not how I would have done it, but the project evolved historically and that's what it was. Moreover, using a conversion tool means learn to use it which can be a big overhead for big projects since you have to fully understand: -how to use it correctly -what the conversion tool does -why it does it like this -why it does not do what you expect -what you need to do differently to suit your internal restriction -. Big projects are work no matter what. What's your alternative, write everything from scratch so you don't have to learn anything? Makes no sense. I wrote a tool that was potentially capable of translating all the thousands of Makefile.in's in the source tree to CMakeList.txt. Some of them had non-trivial amounts of build targets in them that required elaborate re-chaining of dependencies. So what if they aren't perfect for your needs or you had to learn something about how Autoconf + GMake differs from CMake? You have to learn some CMake no matter what and the tools are doing 95% of the work for you. All this to say that conversion tools for source files or other easy tasks are enough. Ok, so you're on record as having your doubts and thinking this wouldn't work for you. I suppose that's a data point and dealing with skepticism is an issue. Anyone else feel more bullish about this? Otherwise I guess it's not an open source problem. More a case of if I want it done right, I'll have to do it myself. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] converting VS projects to CMake
Someone asked me the other day why CMake doesn't do this. I thought I gave him a reasonable answer, that it would be painful to do, and that CMake -- native is a much easier problem than native -- CMake. But I said I would ask here for other people's opinions on it. I have experience converting a large Autoconf + GMake project to CMake. At the time I used piles upon piles of regular expressions. I can think of more sophisticated ways to do the parsing and translation. But no matter what technology is chosen, it's a lot of work. I'm sure the same would be true for MSVC, plus MSVC changes its format every few years. Does MSVC pose any other special difficulties, other than sheer mind-numbingness of translation? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Multiple toolchains in one CMakeList?
On Feb 5, 2008 2:15 PM, Hendrik Sattler [EMAIL PROTECTED] wrote: Am Dienstag 05 Februar 2008 schrieb Brandon Van Every: On Feb 5, 2008 11:08 AM, Hendrik Sattler [EMAIL PROTECTED] wrote: Quoting Brandon Van Every [EMAIL PROTECTED]: On Feb 5, 2008 10:05 AM, John Spray [EMAIL PROTECTED] wrote: If I were invoking a second CMake, would I be able to make the host CMake aware of the second as a dependency? Sure. add_custom_command, add_custom_target. The subsidiary CMake would have to actually output something. You'd have to know what that output is going to be, and how to invoke the build. Or a new command add_indep_subdirectory() which does automate that by forgetting about most cmake settings but targets. Example: compiling a firmware code with a cross-compiler, then converting that binary into a .c file and including that into a binary: two compiler chains and one add_custom_command. It would restrict to using a separate subdirectory for the different toolchain (else it is probably not complex enough). What's wrong with doing things the usual way? I'm not seeing a reason to hide the standard mechanisms for calling external tools. CMake can be an external tool, there's nothing wrong with that. You don't get the target in the calling cmake environment. You actually loose every feature of cmake regarding the connection between the two instances :-( Or at least it gets freaky complicated to achieve the same features. Aren't you over-dramatizing? You aren't going to get that many CMake features anyways because you're doing non-standard linking. You'll be creating your own configure.h anyways. make mytarget is a trivial custom command. The real source of complication is how to call Visual Studio on the command line. For build tools other than make and VS, who cares? Those 2 tools cover 90% of what people will want to use in the real world. If you want to add Watcom or Borland support or whatever, fine, add if(WATCOM) or whatever when you need to. This is a small amount of work compared to implementing a luxurious fully integrated version in CMake itself. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 4th Edition CMake book now in stock
On Feb 5, 2008 4:28 PM, Alan W. Irwin [EMAIL PROTECTED] wrote: I looked at that site, and there was no mention of an electronic (PDF) version. I far prefer that format since it is friendlier to trees, takes up no space in my office, is much easier to search, and I can adjust the size of the text when my eyes get tired. Here's to dead trees! They rest my eyes, they carry to any physical location I wish. Truth be told, I'm not interested in the book as a reference, but rather to see what to recommend to CMake newbies. If you are concerned with short-term money rather than long-term promotion of CMake and the potential money that might come from that, then you will probably want to distribute an electronic version of your book with reduced user freedom. I think such a restricted version would be acceptable so long as at minimum the user was free to make backup copies for their own use. My opinion is that Kitware doesn't need to provide the entire book in an easily pirated medium. I do think they need to freely give away enough documentation to serve as a basic language syntax and command reference. I have filed http://cmake.org/Bug/view.php?id=6295 on this issue. A CMake newbie needs enough free documentation to become an intermediate user. After that, they can choose to RTFM, grep sources, read mailing list archives, or buy books. I don't think they need to get everything that anyone would ever write about CMake for free. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] 4th Edition CMake book now in stock
On Feb 5, 2008 6:49 PM, Alan W. Irwin [EMAIL PROTECTED] wrote: On 2008-02-05 17:08-0500 Brandon Van Every wrote: On Feb 5, 2008 4:28 PM, Alan W. Irwin [EMAIL PROTECTED] wrote: I looked at that site, and there was no mention of an electronic (PDF) version. I far prefer that format since it is friendlier to trees, takes up no space in my office, is much easier to search, and I can adjust the size of the text when my eyes get tired. Here's to dead trees! They rest my eyes, they carry to any physical location I wish. Brandon, I can visualize you strongly arguing for the quill pen when the first printing presses came out. :-) Absolutely, just as I would today. I usually design things using pen, paper, and an engineering notebook. This is the original laptop, it goes anywhere and allows me to visualize anything with instant feedback. Letter setting would have been *extremely* tedious back in the day by comparison. The advantage of letter setting is economy of scale for reproduction, not ease of initial drafting. It is only fairly recently that I used the computer as any kind of a prototyping tool, mostly for CMake code snippets. I have contemplated using computer diagramming tools for all the mathematical things I devise, but that's only useful if I actually need to evaluate them. Usually when I get bogged down into thinking I need to evaluate some equation, I end up saying, ok, I'm overthinking this, I should either write some code or *assume* there's an answer rather than wearing myself out trying to pin down the exact answer. Then the problem tends to go away because I have some more pressing priority. If I get into the business of making money on math, then I'll reconsider. I also paint and have felt no affinity for digital tools. I think that's because nobody has commodified a tablet computer. My opinion is that Kitware doesn't need to provide the entire book in an easily pirated medium. Please think of what real piracy implies (rape, murder, looting, slavery) before using the term so casually. Piracy is a technical term that everyone in the software industry is familiar with, and that most consumers are now familiar with as well, thanks to their something-for-nothing habits with MP3s, DVDs, and P2Ps. Of course, Hollywood and the RIAA likes to use such overblown terms for use of any of their products in any way they don't like (whether legal or not), Hardly. Those are new kids on the block. People talked about software piracy back in the days of my Atari 800, in 1981. That's why all those Infocom text adventure games had sliding puzzle wheels and look at page 3 of the manual and collectible wizard cards and whatnot. It is far too late for you to reinterpret the commonly accepted term piracy according to some kind of cockamany PC sensibility. And while you're reinterpreting stuff, you might take a historical look at piracy vs. privateering. Where do you think pirates came from? From the Brits deciding they didn't need the privateers anymore, that's where. but that doesn't mean you have to ape their misuse of the language. Throw out the entire computer lexicon while you're at it then. Or rather: don't teach your Grandma how to suck eggs. That said, I think you're older than me, so maybe: [...] your Grandson [...] ? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Running shell scripts...
On Feb 3, 2008 7:16 PM, Benjamen R. Meyer [EMAIL PROTECTED] wrote:
I wrote a bash shell script to get the SVN global revision information
(e-mail me privately if you want a copy) to put into a header file under
POSIX systems. The script is located at ${CMAKE_ROOT}; however, I am
having difficulty getting it to appear in the Makefile. Below is the
syntax from top-most CMakeLists.txt:
IF (WIN32)
# Execute Win32 Specific commands - none yet.
ELSE (WIN32)
# Execute commands for other platforms
ADD_CUSTOM_COMMAND(
OUTPUT SVN_REVISION
COMMAND ${CMAKE_ROOT}/getSVNversion.sh
WORKING_DIRECTORY ${CMAKE_ROOT}
COMMENT Creates/updates header SVN Revision Header
)
ENDIF (WIN32)
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/SVN_REVISION
Otherwise an out of source build fails.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Win32 Executable.
On Feb 1, 2008 8:14 AM, Surya Kiran Gullapalli
[EMAIL PROTECTED] wrote:
Hi all,
I'm building a win32 application, and for that I wanted to build the
application as console application in debug mode and win32 application
in release mode.
ADD_EXECUTABLE takes care of /subsystem:windows or /subsystem:console
flag, depends on whether or not you provide WIN32 flag to
ADD_EXECUTABLE.
I switch between debug and release builds quite often. It is very
inconvenient to modify the add_executable call every now and then. Is
there any way i can specify the appropriate flags at once (like we do
for
TARGET_LINK_LIBRARIES with debug and optimized flags).?
With a little swizzling from the CMake Useful Variables
http://www.cmake.org/Wiki/CMake_Useful_Variables you could do:
# set this early on
set(wingui WIN32)
if(MSVC AND CMAKE_CFG_INTDIR STREQUAL /Debug)
set(wingui)
endif(MSVC AND CMAKE_CFG_INTDIR STREQUAL /Debug)
# use this style for all add_executable calls
add_executable(foo ${wingui} blah.c etc.c)
Cheers,
Brandon Van Every
Surya
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unexpected behavior testing boolean expressions
On Jan 30, 2008 9:53 PM, Alan W. Irwin [EMAIL PROTECTED] wrote: My guess is YES, etc., are being interpreted as (undefined) variable names Yep, that's exactly what's happening. The macro expands to things like if(YES) and the variable YES has not been defined. A month or so ago I made a feature request to define TRUE and FALSE as constants. http://www.cmake.org/Bug/view.php?id=5835 I've now made a note that perhaps YES, NO, ON, and OFF should be defined as constants as well. I don't believe Y and N should be defined as constants. Frankly I think they should be removed as true/false values. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unneeded escaping: how to stop it?
On Jan 30, 2008 10:38 AM, Steven Van Ingelgem [EMAIL PROTECTED] wrote: I just thought that the COMMAND would be executed as is, and that VERBATIM meant there is no escaping... Hence my confusion The docs say, If VERBATIM is given then all the arguments to the commands will be passed exactly as specified no matter the build tool used. Note that one level of escapes is still used by the CMake language processor before ADD_CUSTOM_TARGET even sees the arguments. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem setting CMAKE_BUILD_TYPE and CMAKE_INSTALL_PREFIX
On Jan 29, 2008 12:26 AM, Yogesh Marwaha [EMAIL PROTECTED] wrote: All I want is the ability to change default values for CMAKE_BUILD_TYPE and CMAKE_INSTALL_PREFIX, i.e. if the user configures with only cmake .. If the user want it, these options should be changeable by supplying -DCMAKE_BUILD_TYPE and -DCMAKE_INSTALL_PREFIX to cmake Can you help me now, please. ;) The archives have tons on this. Maybe too much. I do recall that on MSVC the default CMAKE_BUILD_TYPE is Debug and we're stuck with it. Has to do with MSVC innards, many minds threw energy at the problem, there was no known solution. Unless the latest greatest MSVC is doing something different. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] $ENV usage and documentation
On Jan 28, 2008 9:31 PM, Bill Hoffman [EMAIL PROTECTED] wrote: So, a small focused patch for documentation will be addressed much quicker than a large complicated patch. I will also say, documents have been getting fixed lately without patches, if the new text is trivial. Generally I just give the 1..2 sentences necessary, and someone else goes through the bother of getting it into the docs. I think that's as it should be, since for such small changes, constructing and applying patches is useless overhead for all parties. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Including existing make files into cmake
On Jan 29, 2008 8:18 AM, Ali - [EMAIL PROTECTED] wrote: (1) Somewhere in this file the include line for the existing make file is added. (2) Somewhere in the compile command all the flags from the existing make file, stored in one single variable $(EXISTING_MAKE_FLAGS), is added. The above works fine, the only pain is that I have to edit the build.make file every time I re-run the cmake command. The question is, how can this be automated by cmake commands? string(REGEX REPLACE ...) Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unneeded escaping: how to stop it?
On Jan 28, 2008 1:44 AM, Steven Van Ingelgem [EMAIL PROTECTED] wrote: It didn't help very much though :S Now I get: COMMAND if [ ! -e TEST ]; then echo ok echo 2 echo test; fi == if [ ! -e TEST ]; then echo ok echo \test\; /dev/null fi So clearly the first case was better :) Could you please provide a trivial reproducer script using VERBATIM? I can't follow the e-mail threads of what you're actually having a problem with, you've skipped around from command to command to command. By trivial I mean 1 line of mis-translating text, not a dump of whatever project you're working on. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] $ENV usage and documentation
On Jan 28, 2008 12:16 AM, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2008-01-27 22:28-0500 Brandon Van Every wrote:
On Jan 27, 2008 8:34 PM, Alan W. Irwin [EMAIL PROTECTED] wrote:
I would like to be able to read arbitrary environment variables from within
cmake. The 2.4.8 documentation only refers to $ENV once as $ENV{PATH} in
an extremely narrow context (the TO_CMAKE_PATH signature of the FILE
command).
However, when I tried, e.g.,
SET(pc_path $ENV{PKG_CONFIG_PATH})
it seemed to work. Is this usage supported in general?
As far as I know. You can test all these things out with trivial
scripts to prove that they work or don't work.
Yes, that is exactly what I have done, but the question remains is this some
side effect that might be removed later or is the code meant to work that
way, i.e., is it a supported use?
As far as I know or can remember. You could check the mailing list
archives and the CMake sources for verification. Quick grep of ENV in
.cmake files should reveal exactly what's used in practice.
It would be best if you file a (documentation, text) bug report for
this. Preferably with the wordsmithing you think should be used, and
where it should be used, based on what you have determined works
properly. I've been doing this for various documentation
embellishments in recent months, and they are getting acted upon and
closed.
Well, it does sound like you have been successful with that approach so I
may adopt it, but generally I am quite hesitant to go through formal bug
reporting for stuff that can be fixed much faster than the time spent on bug
triage. IOW, I hope CMake developers read this list and when they see small
issues reported they fix it immediately rather than fooling around with bug
reports, assigning somebody to deal with it, etc.
But the more you ask them to do, like ask them to perform the
wordsmithing themselves, the less easy it is to drop what they're
doing and immediately fix the problem. Hence the stickiness of the
bug tracker. Also, isn't it unreasonable to expect them to drop what
they're doing to handle your priorities immediately? The bug tracker
has severity and priority settings; this is at best a severity=minor,
priority=normal issue. I'm sure you can appreciate that people have
lots of other things to do. Like I said, these documentation issues
are actually getting fixed lately when I file them (thanks especially
to Alex), so please respect Kitware's process and work with them.
Finally, there is no
point in me suggesting new documentation wording when questions like the
above are still outstanding.
I would simply assume that all the permutations of $ENV{x} ENV{x} ENV
x that you've seen are supported in their various contexts. Do the
wordsmithing to say, This is what's going on, in the appropriate
contexts. You're talking about ~3 permutations; if 1 of 'em turns out
to be unsupported, so what? It's not that much work on your part or
much text lost. The person who works on the doc changes will take
that into account, and possibly open a new bug to change actual code.
I don't see why you're so against bug triage except for response time.
I've said that response time is acceptable lately, and otherwise,
having a conversation in the bug tracker is like having a conversation
on the mailing list. Only it's sticky, more usable, and isn't
forgotten as easily.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem setting CMAKE_BUILD_TYPE and CMAKE_INSTALL_PREFIX
On Jan 28, 2008 12:31 PM, Yogesh Marwaha [EMAIL PROTECTED] wrote: set (CMAKE_BUILD_TYPE Release) Please see http://www.cmake.org/Wiki/CMake_Useful_Variables for info on this variable. set (CMAKE_INSTALL_PREFIX /usr) I agree with the other poster that you should not set this unless you have an exceptionally good reason to. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] $ENV usage and documentation
On Jan 27, 2008 8:34 PM, Alan W. Irwin [EMAIL PROTECTED] wrote:
I would like to be able to read arbitrary environment variables from within
cmake. The 2.4.8 documentation only refers to $ENV once as $ENV{PATH} in
an extremely narrow context (the TO_CMAKE_PATH signature of the FILE command).
However, when I tried, e.g.,
SET(pc_path $ENV{PKG_CONFIG_PATH})
it seemed to work. Is this usage supported in general?
As far as I know. You can test all these things out with trivial
scripts to prove that they work or don't work.
The current documentation has a number of different references to ENV.
It refers to
$ENV{PATH}
one place (in a narrow context as noted above),
ENV var
several places, but in extremely specific contexts (which I presume could be
replaced by $ENV{var})
and
ENV{PATH}
in one place (an example showing how to use SET to write
the PATH environment variable).
Please document $ENV for reading and ENV for writing arbitrary environment
variables in at least the CVS version. A logical place for this general
documentation might be the SET command since as noted above that already
gives an example for writing the PATH environment variable.
It would be best if you file a (documentation, text) bug report for
this. Preferably with the wordsmithing you think should be used, and
where it should be used, based on what you have determined works
properly. I've been doing this for various documentation
embellishments in recent months, and they are getting acted upon and
closed.
One gotcha about set(ENV{var} blah) is that it only sets the CMake
configuration environment. It doesn't exist in the build environment,
as CMake is gone and we're not running under CMake's choice of shell
anymore. This gotcha should also be noted in the set() docs.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Unneeded escaping: how to stop it?
On Jan 27, 2008 9:20 PM, Steven Van Ingelgem [EMAIL PROTECTED] wrote:
Hi,
I'm working on a SLES10.
I have an add_custom_command with in it's command:
LDFLAGS=-L${PROJECT_SOURCE_DIR}/lib -ldl ./configure ...etc...
Now if I go and check the configure log, I see that the LDFLAGS are
interpreted as -L${PROJECT_SOURCE_DIR}/lib\ -ldl (watch the escaping
of the (space)).
Did you try VERBATIM?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.4.5 errors on code which works fine in 2.4.7
On Jan 24, 2008 2:50 PM, Andreas Pakulat [EMAIL PROTECTED] wrote: Any ideas how to solve this (besides upgrading cmake)? Quotes? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Why SET() not support regular expression ?
On Jan 23, 2008 3:51 PM, pepone. onrez [EMAIL PROTECTED] wrote: Maybe a macro can call cmake for only this part that need to be regenerated, in this way if the macro detects thats a glob has changed it can recreate rules that´s depends upon this GLOB, Only and idea what you think about this? file(GLOB var pattern) simply outputs a variable var. So you are talking about determining arbitrary program execution based on the value of the var. In practice I don't see how you'd cleanly separate that. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VS makefiles
On Jan 23, 2008 4:58 PM, Steven Van Ingelgem [EMAIL PROTECTED] wrote: Hi, I was wondering why there are no VS makefiles? (run like nmake -f project.mak). If you're looking for nmake support, that is there. If you're looking for VS support of Makefiles, VS 6.0 was the last version to support them. Since none of the more recent VS versions understand Makefiles, it makes sense that the capability is not supported for the rather old VS 6.0 generator. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Custom build step
On Jan 21, 2008 6:16 AM, pepone. onrez [EMAIL PROTECTED] wrote:
SET ( COPY_FILE cp -v )
Better: ${CMAKE_COMMAND} -E copy
Type cmake -E for details of OS portable commands.
Your example build fails on Cygwin with the same problem.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Custom build step
On Jan 21, 2008 7:40 AM, Brandon Van Every [EMAIL PROTECTED] wrote:
On Jan 21, 2008 6:16 AM, pepone. onrez [EMAIL PROTECTED] wrote:
SET ( COPY_FILE cp -v )
Better: ${CMAKE_COMMAND} -E copy
Type cmake -E for details of OS portable commands.
Your example build fails on Cygwin with the same problem.
Ok, here's the essence of what your code does. In the future when
providing a trivial reproducer for a problem, it would be best to
strip it down to this level. One very simple CMakeLists.txt, no
subdirectories, no long variable names, no extraneous stuff. To the
degree that you can, of course.
project(copygen)
SET(f0 sample.g)
STRING( REGEX REPLACE \\.g .cpp f1 ${f0} )
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_BINARY_DIR}/${f1}
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_SOURCE_DIR}/${f0} ${CMAKE_BINARY_DIR}/${f0}
DEPENDS ${CMAKE_SOURCE_DIR}/${f0}
COMMENT step 1)
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_BINARY_DIR}/generated/${f1}
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${CMAKE_BINARY_DIR}/${f1} ${CMAKE_BINARY_DIR}/generated/${f1}
DEPENDS ${CMAKE_BINARY_DIR}/${f1}
COMMENT step 2)
add_library (mylib SHARED ${CMAKE_BINARY_DIR}/generated/${f1} )
This fails because add_library only understands target level
dependencies. add_custom_command only generates file level
dependencies. To make a target level dependency, you'd have to wrap
the last add_custom_command with an add_custom_target(blah DEPENDS
${CMAKE_BINARY_DIR}/generated/${f1}), then ADD_DEPENDENCIES(mylib
DEPENDS blah).
add_library would have understood the dependency just fine, if it were
not generated. Question: why couldn't add_library look for generated
files as well as non-generated files?
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Custom build step
On Jan 21, 2008 8:39 AM, Brandon Van Every [EMAIL PROTECTED] wrote: then ADD_DEPENDENCIES(mylib DEPENDS blah). Er, add_dependencies(mylib blah). Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Custom build step
On Jan 19, 2008 11:50 AM, pepone. onrez [EMAIL PROTECTED] wrote: Case 2 - i don`t see that Cmake generated any rule for the second commands. Did you grep all the files in the generated CMake tree? Perhaps they were output to a different file. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Custom build step
I'm going to take a wild guess that one of your variables is emitting extra quotes or open parentheses or something, such that the 2nd ADD_CUSTOM_COMMAND gratuitously disappears. Suggest you message() all your variables to see what they are, and also write a small test case that simulates the behavior you're trying to implement, without all the fancy extra logic. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: add_custom_command dependencies in an auxiliary variable
On Jan 18, 2008 4:59 AM, Rodolfo Lima [EMAIL PROTECTED] wrote: Brandon Van Every escreveu: The dependencies of an add_custom_command are completely under your control anyways. You specify them. Why don't you just re-specify them in your command? It's a bit burdensome when the dependencies exceed the count of 10 or 20. Ok, I could create them in a variable and use it, That's the usual way to do it. but I'd like to mimic the gnu-make behavior. Why? Just because you know it? That's not a good reason to put it into CMake, if CMake can already accomplish the same thing. Commands like $^ are cryptic. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] adding static library when building static library
On Jan 18, 2008 1:50 PM, Brandon Van Every [EMAIL PROTECTED] wrote: Check the FAQ and the mailing list archives for more info on this issue. Sorry, the FAQ doesn't have any clear statement on the static lib inside a static lib issue. It does talk about so-called convenience libraries a bit. Your best resource is the mailing list archive. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom_command as target
On Jan 17, 2008 5:10 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: Is there a way to create an add_custom_target that tracks dependencies? Or an add_custom_command that will act as a target (without needlessly being added to add_executable, etc). To get the effect of that, you wrap your add_custom_command with an add_custom_target. add_custom_command(OUTPUT blah ...) add_custom_target(mytarget DEPENDS blah ...) Admittedly this is inelegant, but it works. I have no idea how much work it would be to remove the distinction between file level and target level dependencies. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom_command as target
On Jan 17, 2008 7:46 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: That feature is, however, undocumented. Neither of the add_custom_* nor the wiki has any mention of this or the possibility of add_custom_target being able to take a custom command. Not true. add_custom_target says, Dependencies listed with the DEPENDS argument may reference files and outputs of custom commands created with ADD_CUSTOM_COMMAND. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] add_custom_command dependencies in an auxiliary variable
On Jan 17, 2008 9:15 PM, Rodolfo Lima [EMAIL PROTECTED] wrote: Hi, I wonder if it's possible to add_custom_command create a temporary variable which contents are all dependencies of the custom command. This could be used if one command shall contain all dependencies in its command line. gnu make does that with $^ (i think). Something similar with the output file name would be good (like $@ in gnu-make). The dependencies of an add_custom_command are completely under your control anyways. You specify them. Why don't you just re-specify them in your command? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008 12:16 PM, Leopold Palomo-Avellaneda [EMAIL PROTECTED] wrote: without any problem. Howeber, when I try to compile the project in OSX, I can compile the libs, one exec but it fails with the first plugin. I have isolated the problem in this: Linking CXX shared library libpluginregistrodeiva.dylib Undefined symbols: I don't have any special consideration with the OSX platform (CMake is wonderfull, isn't it?) but it fails in this. It seems that the compiler, when link the plugin try to find anything that doesn't find (in linux it finds...) I wonder if this is the Apple linker always prefers dynamic libs problem. Search the mailing list archives for that. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] My dammed problem with OSX and Qt
On Jan 16, 2008 12:45 PM, Leopold Palomo-Avellaneda [EMAIL PROTECTED] wrote:
A Dimecres 16 Gener 2008, Brandon Van Every va escriure:
I wonder if this is the Apple linker always prefers dynamic libs
problem. Search the mailing list archives for that.
I have this:
add_library(${plugin} SHARED ${plugin_SRC} ${plugin_MOC_SRCS}
${plugin_UIS_H} ${plugin_SRCS} ${plugin_MOCS})
Well, if you're only using shared libs and no static libs, then I have
guessed wrongly about your problem.
I don't know what are your reffering to search in the mailing list because I
have done some search without any interesting result.
If you do have any static libs in your build, then try the keywords
Apple shared static depreciated.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
On Jan 15, 2008 7:03 AM, Martin Lutken [EMAIL PROTECTED] wrote:
Simple example from my actual codebase. CBS (Common Build System) makefiles
for zlib and libpng, which depends on zlib (install stuff not included):
--- z.cbs ---
TARGET_DEFAULT_VERSION ( 1 2 3 )
ADD_SOURCE_FILE ( adler32.c )
ADD_SOURCE_FILE ( compress.c)
...
ADD_SOURCE_FILE ( inffast.c )
Why do I want ADD_SOURCE_FILE? In CMake I just do:
SET(mysources adler32.c compress.c inffast.c)
ADD_LIBRARY(mysharedlib SHARED ${mysources})
ADD_LIBRARY(mystaticlib STATIC ${mysources})
--- png.cbs ---
TARGET_DEFAULT_VERSION ( 1 2 16 )
ADD_DEPENDS_ON ( z )
Why do I want ADD_DEPENDS_ON? In CMake I just do:
TARGET_LINK_LIBRARIES(mysharedlib z)
TARGET_LINK_LIBRARIES(mystaticlib z)
Note the ADD_DEPENDS_ON ( z ) for png. This single line takes care of all
needed includes, linkdirs/libraries etc. thats neeeded to compile and link
libpng.
From your description, I don't understand what this is doing extra.
In the (in time hopefully rare) cases where you depend on external libraries
you use ADD_LINK_DIR, ADD_LINK_LIBRARY
CMake's TARGET_LINK_LIBRARIES doesn't care if you hand it external
link libraries or internal library target names. It just deals with
them. Why do you need a 2nd command?
In case you need to add defines you can do
ADD_DEFINE or ADD_PUBLIC_DEFINE
CMake has ADD_DEFINITIONS. What would ADD_PUBLIC_DEFINE do?
--- Main configuration file ---
Lastly I should mention some of the cool stuff you can do in the main
configuration file, by this example from (again from my actual codebase):
SET ( z_USE SYSTEM ) # Use system version (currently not Windows)
So you are implementing cross-compiling support? CMake CVS has that.
SET ( png_USE BUILD) # Build from sources in this project
CMake can do this, but it has to be handled by the consumers of the
png library, not the png library itself.
if(use_myzlib)
TARGET_LINK_LIBRARY(mylib myzlib)
else(use_myzlib)
TAGET_LINK_LIBRARY(mylib z)
endif(use_myzlib)
SET ( bz2_USE PREBUILT ) # Prebuilt (with CBS) from othter source tree.
I don't have a lot of experience with using CMake builds that wrap
other CMake builds. CMake does have mechanisms for 3rd party builds.
SET ( z_LINK_TYPE STATIC ) # Build/use zlib static event though current
default for project as a whole is to make shared libs/DLLs.
CMake already has that. ADD_LIBRARY(mylibname [SHARED | STATIC |
MODULE] blah blah blah) where the stuff in [ ] is optional.
Well hope that gave you an impression of what it is.
I'm unclear. What is the strategic purpose of CBS?
Are you trying to do CMake projects, but at what you consider to be a
higher level of abstraction than CMake provides? If so, then it's
probably worth going over each of those features above individually.
Some of them, I think CMake does just fine already. Others, perhaps
you have a more elegant approach. But community buy-in is important
here. Nobody's looking for new things to learn, unless there are
clear benefits. One of the biggest detriments I see in adding new,
supposedly better ways of doing the same thing, is that CMake is
already woefully under-documented as is. So it really should do a
different or clearly better thing, not just a variation on the thing.
It's way easier for CMake developers to function as a community when
they're all speaking the same language.
Are you trying to make it possible to generate CMake projects, or
other build tool projects (SCons? Ant?) using a common build tool?
If so, that's already what CMake is trying to do. We don't want a
common build tool, we think we are the common build tool. We would
want a generator for SCons or Ant or whatever.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Patch to apply! Changing the default nameCMakeLists.txt! Introduction to Common Build System
On Jan 15, 2008 11:46 AM, Andreas Pakulat [EMAIL PROTECTED] wrote: On 15.01.08 11:37:12, Brandon Van Every wrote: I'm unclear. What is the strategic purpose of CBS? If I understood correctly, the purpose is to (at some point) build foobar, including all deps completely with cbs. But is it a higher level CMake variant, or is it a completely new build tool that sees CMake as merely 1 of many possible output targets? To me this totally sounds like Gentoo with cmake files as emerge replacement. I'm reading http://linuxreviews.org/man/emerge/ and I don't understand how CMake could serve as an Emerge replacement. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
