[CMake] build a shared library from static libraries
Hi I am trying to build a shared library from many static libs, so I can divide my compilation in subdirectories. But I don't get how i should do this. I tried to use TARGET_LINK_LIBRARY( first_lib, second_lib, ...) But cmake says : Attempt to add link library first_lib, to target second_lib, which is not built by this project. Is there a better way to di this ? Thanks in advance -- - Always keep in mind that you may be wrong - ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Converting a VS Build to CMake/Problems with Post-Build steps, questions
Philip Lowman schrieb:
How about GET_TARGET_PROPERTY(var MyTarget DEBUG_LOCATION) followed by a
second ADD_CUSTOM_COMMAND() for the debug binary?
Ok, found the solution: Latest CMake (2.5 nightly, tested with the
binary from March 1) supports COMMAND with a normal target in
ADD_CUSTOM_COMMAND, so I can pass MyTarget to it, which gets filled with
the right value.
ADD_EXECUTABLE(Test ${TEST_SOURCES})
SET_TARGET_PROPERTIES(Test PROPERTIES DEBUG_POSTFIX d)
ADD_CUSTOM_COMMAND(
TARGET Test
POST_BUILD
COMMAND Test
)
works fine.
Cheers,
Anteru
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Passing parameters to uic in QT4_WRAP_UI macro
Hi, the QT4_WRAP_UI macro encapsulate the uic command. Howeber I miss a way to pass a parameter to uic. There's som way to do it or may I create my custom QT4_WRAP_UI ? Thanks in advance, Leo signature.asc Description: This is a digitally signed message part. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake and Lua
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. I don't buy the duplication of code approach. --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] re: Compile only, no link
On Wednesday 27 February 2008, jean-daniel.michaud at uk.bnpparibas.com wrote: Hello, I'd like to know if it's possible to create a project, add source files to it, make those sources compile to objects, but do not create any executable or library. Something like: PROJECT(someproject) ADD_SOURCE_FILE(this.cpp that.cpp) # define some c flags here COMPILE_SOURCE And after the make, I would end up with this.o and that.o, but no executable. I can't use custom command, because, I'd like the CMakeFiles to produce some proper IDE project files, with the source files in it. Can't find anything in the mailing list or doc to do this trivial thing. You could build a static library, which is basically just a container for object files. Would that help ? Alex Hi Alex, thx for your answer. Well, It's not what I'am thinking of. We have a project tree like this: project A: generate A.exe (link with sub project lib) project A1: generate somelib.a (link with sub project objects) project A1' : generate toto.o titi.o project A1'' : generate tata.o tutu.o project A2: generate someotherlib.a etc... Ok, this is silly, but this is legacy and we can't/don't want to change that. We are using some crappy IDE now that uses project files that I'am parsing and create a CMakeFile equivalent. The idea is then to have Eclipse project files that emulates the exact project tree we have today. That's why I have projects that produce .o only. So the idea is to separate the definition of what a project is (a group of source files) and what it produces (executable, library or nothing). The problem I have with CMakeFile now is that I don't see how I can define a project without defining what it produces. Thanks. JD This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Do not print this message unless it is necessary, consider the environment. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. N'imprimez ce message que si necessaire, pensez a l'environnement. This communication is confidential, may be privileged and is meant only for the intended recipient. If you are not the intended recipient, please notify the sender by reply and delete this message from your system. Any unauthorised dissemination, distribution or copying hereof is prohibited. BNP Paribas Fund Services UK Limited, BNP Paribas Trust Corporation UK Limited, BNP Paribas UK Limited, BNP Paribas Commodity Futures Ltd and Investment Fund Services Limited are authorised and regulated by the Financial Services Authority. BNP Paribas, BNP Paribas Securities Services and BNP Paribas Private Bank are authorised by the CECEI and AMF. BNP Paribas London Branch, BNP Paribas Securities Services London Branch and BNP Paribas Private Bank London Branch are regulated by the Financial Services Authority for the conduct of their UK business. BNP Paribas Securities Services London Branch is also a member of the London Stock Exchange. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Raven, Antwrap, Buildr
Brandon Van Every wrote:
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.
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.
- is a :colon in front of something a great idea?
It is a pretty good one. It isn't of course as clean as just a simple
string with no quotes, but then again, you otherwise get quickly in
trouble with local vars. CMake basically does not have local vars (all
are globals) and those are always defined/dealt in SET() commands.
- why do I have to type |bars| around something?
This is a ruby convention that is somewhat overused in rake. The do
|iter| ... end or { |iter| ... } defines a block with a local
variable to the block which is usually used for iteration or for
construction.
The local variable is usually filled by the caller (usually providing
you with access to *this or self of the object you built).
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).
That code is somewhat sugar akin to:
t = Rake::Task.new( myexe )
t.link_libs = 'asdasd'
t.so_version = 1.0
t.call_func
The benefit of not using the constructor directly is that the api is
easier to change. Also, at the end of the block (end or end bracket), a
lot of other internal hidden code may run (for example, validating
dependencies or parameters right away)-
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.
If your forget the decorator, it is interpreted as a local variable. As
no such variable would likely exist, you'd get an error.
Obviously this flexibility does allow you do, for example:
#
# 3 targets, each with same dependency.
#
targets = [ :target1, :target2, :target3 ]
targets.each { |name|
task name { |t|
t.dependencies = %w( dep1 dep2 dep3 )
}
}
Here the symbol is replaced with a local variable called 'name' which
changes on each iteration.
- why put both [square brackets] and {curly braces} around something?
[square brackets] is an array, {} is a hash. In the example you
posted, you have an array of hashes, which is as ugly as it can get.
Is that so we can be terse about minimum versions?
No. It is just that the api you posted seems to require an array of
hashes. Pretty ugly api, if you ask me. Having a hash that contains
arrays (or other hashes) is more common.
- 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
Here I am using symbols, but you could also make the api use strings
(which forces to use quotes) or accept both (which is usually the case
with ruby).
add_dependency target, dep1, dep2, dep3
or (if you want to make it more explicit as rake):
add_dependency :target = %w( dep1 dep2 dep3 )
In a more extensible api that would use hashes for values, it would look
like:
add_dependency :target, :dependencies = %w( dep1 dep2 dep3 )
or, like rake does, use an OO approach:
task :target { |t|
t.dependencies = %w( dep1 dep2 dep3 )
}
In ruby it is pretty trivial to provide both types of interfaces (even
with swig for C++ code). Rake only provides an OO api.
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.
Talking about rails, rails uses another form of DSL, which is class based.
Basically, a cmake api based like rails would look more like:
class MyExe CMake::Executable
dependencies %w( dep1 dep2 dep3 )
def compile
# optionally override CMake::Executable compile routine
end
end
A class DSL really does not make that much sense for a build system, but
it is obviously great
Re: [CMake] Passing parameters to uic in QT4_WRAP_UI macro
If you use CMake 2.4.8, you can pass parameters to uic.
QT4_WRAP_UI(UI_SRCS ${UIS} OPTIONS -p)
will pass -p to uic.
Clint
Leopold Palomo-Avellaneda wrote:
Hi,
the QT4_WRAP_UI macro encapsulate the uic command. Howeber I miss a way to
pass a parameter to uic.
There's som way to do it or may I create my custom QT4_WRAP_UI ?
Thanks in advance,
Leo
___
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
[CMake] FindYARP.cmake
YARP - Yet Another Robot Platform I am looking for someone who also uses/ed YARP and has one of those =) FindYARP.cmake Google was not helpfull, unexpectedly. Anyone? Or should i just dig in and make my own? Thank you all, -- Dario Figueira ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] current (2.5) CMakeForceCompiler
Hi, visiting http://www.cmake.org/Wiki/CMake_Cross_Compiling, I discovered a way to tell cmake not to test the C cross-compiler. However the source tree has changed recently and including CMakeForceCompiler will not work anymore. CMake Error: Do not include the CMakeForceCompiler module. It is no longer necessary. Update your toolchain file as follows. I tried updating my Toolchain file as suggested but it ends up testing the compiler which wont work with the project I work on simply because the cross-compiler has to build source code from the project in order to link successfully a simple test program. What's the current way of dealing with this situation ? Thanks, - Y ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CodeBlocks generator issues
Philip, You seem to be right. Changing the build target to the name of my project did the trick. I can now run and debug the program successfully. Thank you, Félix C. Morency On 3/2/08, Philip Lowman [EMAIL PROTECTED] wrote: On Sun, Mar 2, 2008 at 7:06 PM, Félix C. Morency [EMAIL PROTECTED] wrote: Hi, I just discovered that CMake SVN (future 2.6.0) currently supports CodeBlocks project generation. I gave it a try and the result seems promising. I've been able to successfully compile my project under CodeBlocks 8.02. However, running the program (which is a command line program) from CodeBlocks with the Run command doesn't work. The error is: You can't run a commands-only target Another issue is the debugging tool which doesn't start with this error: The selected target is only running pre/post build step commands. Can't debug such a target I guess those issues come from CMake since all those features work with what I call a pure CodeBlocks project. Are those issues already known and if yes, are you planning on fixing them with the release of the 2.6.0version ? Félix, I don't know anything about CodeBlocks but I do know with the Visual Studio generator the default project is ALL_BUILD which you can't debug. In order to Debug with Visual Studio you have to right click on the desired target and choose Debug (or change your default project). Maybe there's a similar issue with CodeBlocks? Be sure to file a bug on this issue in the CMake bug database if you're still having problems. http://www.cmake.org/Bug/main_page.php -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] current (2.5) CMakeForceCompiler
Yannick Cote wrote: Hi, visiting http://www.cmake.org/Wiki/CMake_Cross_Compiling, I discovered a way to tell cmake not to test the C cross-compiler. However the source tree has changed recently and including CMakeForceCompiler will not work anymore. CMake Error: Do not include the CMakeForceCompiler module. It is no longer necessary. Update your toolchain file as follows. I tried updating my Toolchain file as suggested but it ends up testing the compiler which wont work with the project I work on simply because the cross-compiler has to build source code from the project in order to link successfully a simple test program. What's the current way of dealing with this situation ? I had removed the old one because I though it was only for eCos which I got working without it. Update from cvs. There is a new CMakeForceCompiler there. It doesn't have the sizeof(void*) argument, so just leave that off. -Brad ___ 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
[CMake] Detecting linux distro?
I'm sure I'm not the first person to need to do this but I can't see an obvious solution. I want to be able to detect which Linux system the package is building on, i.e. is it Fedora, Debian, Gentoo, etc? And also beyond that, what version of the distro is it? (e.g. FC6. F9, Debian 4.0) Can someone point me in the right direction? Thanks, Stephen Quinney ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Detecting linux distro?
check uname -a and cat /etc/issue.net... Worked for me :) On 03/03/2008, Stephen Quinney [EMAIL PROTECTED] wrote: I'm sure I'm not the first person to need to do this but I can't see an obvious solution. I want to be able to detect which Linux system the package is building on, i.e. is it Fedora, Debian, Gentoo, etc? And also beyond that, what version of the distro is it? (e.g. FC6. F9, Debian 4.0) Can someone point me in the right direction? Thanks, Stephen Quinney ___ 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
[CMake] Re: Detecting linux distro?
Stephen Quinney escreveu: an obvious solution. I want to be able to detect which Linux system the package is building on, i.e. is it Fedora, Debian, Gentoo, etc? Hi... Usually there's a file named /etc/lsb-release which contents inform the distribution used (along with other infos). Regards, Rodolfo Lima. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMake and Lua
Miguel A. Figueroa-Villanueva escreveu: The point is that if you need to do complex programming stuff (and that is a big if for build systems, because you should focus on simplicity), why not use a programming language and let CMake Script take care of the build management... Using another external language environment could be costly and can make scripts non portable. On windows I can't use bash, on linux I can't use windows executable, etc. God forbids if I need a whole perl installation because of a script... Best regards, Rodolfo Lima. ___ 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
[CMake] cmake community site
Hi everyone. I've got a proposal for you all which I've been thinking about for a while. Since cmake is now getting more and more widely spread, being used by people for both small, casual projects as well as monolithic projects (e.g. KDE) it seems like cmake itself, as well as the users of it could benefit from a community site of sorts. In my experience with opensource projects, one of the largest factors in how large a mindshare it has as well as how long it manages to hold on to that mind share is how strong a community it has. Now, this list is great; both for quick support as well as a direct line to the developers (kudos to Brad, Bill and co. for that) and the wiki is good for code snippets and extra documentation but I feel it could be better. I'm looking to see what you guys on this list think about me starting up a 'cmake community' site, possibly featuring the following: - News about releases - News about projects' success stories etc. - Simple beginner's tutorials - Tutorials about more specific tasks e.g. platform specific things (even when this isn't necessarily cmake specific) - A repository of Find*.cmake files including the ability to provide feedback to the module writer, such as improvements/patches - A repository of extra macros providing the same as the Find*.cmake repository - Discussion forums So, what do you guys think? Is this sort of site wanted/needed? Is this list and wiki enough and should our efforts be focused on them? I'd like to hear your thoughts before anything is set in motion. Finally, a little about myself: I've been using cmake ever since KDE first switched across to it (thankyou Alex) both for all my own projects as well as helping out a number of other projectsmore to a cmake system, particularly for its Linux and MacOS support. I'm a Physics University student by day and a KDE programmer by night. Regards, Matt Williams http://milliams.com signature.asc Description: This is a digitally signed message part. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Detecting linux distro?
Am Montag 03 März 2008 schrieb Stephen Quinney: I'm sure I'm not the first person to need to do this but I can't see an obvious solution. I want to be able to detect which Linux system the package is building on, i.e. is it Fedora, Debian, Gentoo, etc? And also beyond that, what version of the distro is it? (e.g. FC6. F9, Debian 4.0) Can someone point me in the right direction? You may be successfull with detecting the Distribution vendor (Debian, Fedora, etc.) but the version is mostly _not_ reliable. HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: VMWare on SCons' future
Hi Brandon, 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? 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) Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com http://groups.google.com/group/cppba ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Detecting linux distro?
I had to do that too. I ended up going by distribution-specific file in /etc. For example, Red Hat: /etc/redhat-release Slackware: /etc/slackware-version Slamd64: /etc/slamd64-version To determine whether it is 64-bit vs 32-bit Red Hat, I use 'uname -m'. -- Artur Kedzierski -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Quinney Sent: Monday, March 03, 2008 9:09 To: CMake Subject: [CMake] Detecting linux distro? I'm sure I'm not the first person to need to do this but I can't see an obvious solution. I want to be able to detect which Linux system the package is building on, i.e. is it Fedora, Debian, Gentoo, etc? And also beyond that, what version of the distro is it? (e.g. FC6. F9, Debian 4.0) Can someone point me in the right direction? Thanks, Stephen Quinney ___ 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] 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
Re: [CMake] Detecting linux distro?
Kedzierski, Artur CIV NSWC Corona, PA53 wrote: I had to do that too. I ended up going by distribution-specific file in /etc. For example, Red Hat: /etc/redhat-release Slackware: /etc/slackware-version Slamd64: /etc/slamd64-version To determine whether it is 64-bit vs 32-bit Red Hat, I use 'uname -m'. uname -m is a bad idea. If you compile a 32bit application in a chroot system on a x86_64 system. Then uname -m will return x86_64 and not i386. You should use: if (CMAKE_SIZEOF_VOID_P MATCHES 8) endif (CMAKE_SIZEOF_VOID_P MATCHES 8) -- andreas signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Detecting linux distro?
/usr/bin/lsb_release -a seems to be a platform agnostic way of getting the information from the various files in which it is stored. Amitha. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake, Java and JARs
I'm new to java, so I might be doing something wrong.
Here is the CMakeLists.txt:
project(suplemento Java)
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake)
find_package(GWT)
add_library(suplemento src/pt/ipb/client/Suplemento.java)
target_link_libraries(suplemento ${GWT_LIBRARIES})
The contents of
GWT_LIBRARIES=
/opt/google-web-toolkit/gwt-user.jar; \
/opt/google-web-toolkit/gwt-dev-linux.jar; \
/opt/google-web-toolkit/gwt-servlet.jar
And the output
[100%] Building Java object
CMakeFiles/suplemento.dir/src/pt/ipb/client/Suplemento.class
/usr/bin/javac /home/fsousa/tmp/gwt/src/pt/ipb/client/Suplemento.java -d
CMakeFiles/suplemento.dir/src/pt/ipb/client
/home/fsousa/tmp/gwt/src/pt/ipb/client/Suplemento.java:3: package
com.google.gwt.core.client does not exist
import com.google.gwt.core.client.EntryPoint;
^
For some reason cmake is ignoring the jars.
signature.asc
Description: OpenPGP digital signature
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Detecting linux distro?
Kedzierski, Artur CIV NSWC Corona, PA53 wrote: I had to do that too. I ended up going by distribution-specific file in /etc. For example, Red Hat: /etc/redhat-release Slackware: /etc/slackware-version Slamd64: /etc/slamd64-version Gentoo: /etc/gentoo-release signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Removing cmake as a dependancy
My company is Birdstep Technology, formerly Raima Corporation (http://www.birdstep.com/database) and the SDKs we create are embedded databases. One of our strengths is our support of many different platforms from Windows to the multiplicity of unix distros. We've been dealing with a hodge-podge of make systems to support these different environments, especially between Windows and the unix's and really want to find something we can standardize on! We've been sending out our binaries with example code which had project files build for Windows. That was always a problem as different customers have different versions of Microsoft's compilers, so we'd tried including copies of project files for multiple versions or including only the earliest version so that it could be upgraded, and other things, but they have all been painful both for the customers and for us to maintain. So, with CMake able to easily generate a project file or nmake files, or whatever, it would be a huge benefit for us in our maintenance of this. However, there has been some push-back about requiring the customers to have cmake installed. Especially if we expect them to just install our product and then start compiling the examples to evaluate the product, we want there to be as few steps they need to take to get things working as possible. At this point, our best bet may be to just bundle cmake in with our product install to ensure that customers have the easiest possible experience. Kevin -Original Message- From: Bill Hoffman [mailto:[EMAIL PROTECTED] Sent: Friday, February 29, 2008 12:48 PM To: Kevin Tucker Subject: Re: [CMake] Removing cmake as a dependancy Kevin Tucker wrote: Thanks Philip, I hadn't noticed the absolute paths yet. I can see that they would make portability without cmake a problem. Is there any problem with including the cmake installer inside other products? Just curious, what types of products are you talking about? -Bill ___ 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
[CMake] test
___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
On Saturday 01 March 2008, Miguel A. Figueroa-Villanueva wrote: On Fri, Feb 29, 2008 at 11:09 AM, Bill Hoffman wrote: Rodolfo Schulz de Lima wrote: The main issue with CMake script isn't when writing a build script, but when writing auxiliary stuff, like a more elaborate Find*.cmake. Just look at FindwxWidgets.cmake to see what I mean... Thanks for the feedback. I am wondering if there is something that can be done in CMake c++ code to make writing a Find module like wx widgets easier. Maybe regular expressions in the find_* commands would help. Lots of the verbosity comes from finding different names for libraries and paths. I think that has come up on the list or the bug tracker recently. The new break and return could clean it up some more, and the use of lower case would make it look nicer. -Bill quote from another related thread On Fri, Feb 29, 2008 at 1:22 PM, Rodolfo Schulz de Lima wrote: Bill Hoffman escreveu: Enjoy! Wow, that must be a world record... I've mentioned the problem at 10:57 Don't think so, there are 4 hours in between, Bill and/or Brad have already proven before that they can be even faster than that :-) (Brazilian Standard Time), and the solution got committed at 14:18 (BRST). Guinness anyone?? I which my cable TV customer support were that fast...thanks a lot Bill. And you all thought Bill was so resistant to change :P I really think this is the stuff that needs to be addressed and obviously Bill and the rest of the CMake developers are very willing to accomodate this. That is, things like relaxing the if/else constructs, scoping, return, break, lowercase commands, etc. are the components we need to help facilitate writing more complex stuff in CMake scripting. Yes, maybe we should now simply wait a bit and see how new cmake scripts with the new features actually look. What we all know are cmake scripts using cmake 2.2/2.4 syntax, cmake cvs has all the mentioned improvements, maybe these are already enough to make the scripts easier to read/write and more scalable (e.g. scoped vars and functions). Alex ___ 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] CodeBlocks generator issues
On Monday 03 March 2008, Félix C. Morency wrote: Philip, You seem to be right. Changing the build target to the name of my project did the trick. I can now run and debug the program successfully. If you find any issues, please filel bug reports :-) Known issue: Compile current file is not supported. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] build a shared library from static libraries
On Monday 03 March 2008, packadal wrote: Hi I am trying to build a shared library from many static libs, so I can divide my compilation in subdirectories. Don't do that, just use directly the source files from the subdirectories. But I don't get how i should do this. I tried to use TARGET_LINK_LIBRARY( first_lib, second_lib, ...) But cmake says : Attempt to add link library first_lib, to target second_lib, which is not built by this project. Is there a better way to di this ? Did you use SUBDIRS() ? Use ADD_SUBDIRECTORY() instead, then the dirs will be processed at the time of the call, with SUBDIRS the dirs are processed at the end of the CMakeLists.txt Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VMWare on SCons' future
On Monday 03 March 2008, Brandon Van Every 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.htm l 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. Yes, that was my impression too. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake, Java and JARs
On Monday 03 March 2008, Filipe Sousa wrote:
I'm new to java, so I might be doing something wrong.
Here is the CMakeLists.txt:
project(suplemento Java)
set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake)
find_package(GWT)
add_library(suplemento src/pt/ipb/client/Suplemento.java)
target_link_libraries(suplemento ${GWT_LIBRARIES})
The contents of
GWT_LIBRARIES=
/opt/google-web-toolkit/gwt-user.jar; \
/opt/google-web-toolkit/gwt-dev-linux.jar; \
/opt/google-web-toolkit/gwt-servlet.jar
And the output
[100%] Building Java object
CMakeFiles/suplemento.dir/src/pt/ipb/client/Suplemento.class /usr/bin/javac
/home/fsousa/tmp/gwt/src/pt/ipb/client/Suplemento.java -d
CMakeFiles/suplemento.dir/src/pt/ipb/client
/home/fsousa/tmp/gwt/src/pt/ipb/client/Suplemento.java:3: package
com.google.gwt.core.client does not exist import
com.google.gwt.core.client.EntryPoint;
^
For some reason cmake is ignoring the jars.
No idea, but in general the java support of cmake isn't very mature.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VS2005 PocketPC and Smartphone targets
On Friday 29 February 2008, Philip Lowman wrote: On Fri, Feb 29, 2008 at 3:37 PM, Kevin Tucker [EMAIL PROTECTED] wrote: Tried to post the zip file to the cmake e-mail list, but it bounced because it was too large. Hope you got it, Philip! Here's just the one vcproj file. Kevin, It might be possible to get most of the way there with a lot of custom preprocessor definitions, and tweaked compilation and linking flags . Modifying Windows-cl.cmake to support passing /machine:ARM along with the other ARM specific options that are needed would probably be a good place to start. I'm not sure if anyone has undertaken the effort before though. Also, I'm not sure what this section does (I suspect it just modifies the possible build configurations) but noticed that nothing like it is being generated by CMake 2.4.8. Platforms Platform Name=Pocket PC 2003 (ARMV4) / Platform Name=Smartphone 2003 (ARMV4) / I can't help with testing, since I don't have any Windows installation available, but I'd be happy to help with answering questions and integrating this into cmake cvs. Supporting the MS cross toolchain would be really nice to have in cmake. I'd suggest the first step should be to modify Windows-cl.cmake so it can deal with different architectures and get the nmake generator working for your target. You need to use cmake cvs for that, 2.4 doesn't support cross compiling. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake community site
On Monday 03 March 2008, Matt Williams wrote: Hi everyone. I've got a proposal for you all which I've been thinking about for a while. Since cmake is now getting more and more widely spread, being used by people for both small, casual projects as well as monolithic projects (e.g. KDE) it seems like cmake itself, as well as the users of it could benefit from a community site of sorts. In my experience with opensource projects, one of the largest factors in how large a mindshare it has as well as how long it manages to hold on to that mind share is how strong a community it has. Now, this list is great; both for quick support as well as a direct line to the developers (kudos to Brad, Bill and co. for that) and the wiki is good for code snippets and extra documentation but I feel it could be better. I'm looking to see what you guys on this list think about me starting up a 'cmake community' site, possibly featuring the following: - News about releases - News about projects' success stories etc. - Simple beginner's tutorials - Tutorials about more specific tasks e.g. platform specific things (even when this isn't necessarily cmake specific) - A repository of Find*.cmake files including the ability to provide feedback to the module writer, such as improvements/patches - A repository of extra macros providing the same as the Find*.cmake repository - Discussion forums So, what do you guys think? Is this sort of site wanted/needed? Is this I'd say not yet. For now it would probably be better to just help working on the wiki, there you can also write tutorials etc. A solution for additional cmake modules is needed. There is also a cmake site at google Alex ___ 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] CodeBlocks generator issues
On Mon, Mar 3, 2008 at 7:09 PM, Alexander Neundorf [EMAIL PROTECTED] wrote: On Monday 03 March 2008, Félix C. Morency wrote: Philip, You seem to be right. Changing the build target to the name of my project did the trick. I can now run and debug the program successfully. If you find any issues, please filel bug reports :-) Known issue: Compile current file is not supported. Submitted! :) http://www.cmake.org/Bug/view.php?id=6498 -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VMWare on SCons' future
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? -- /Jesper ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
