Hi, I've been playing with imported targets and one *feature* surprised
me. The documentation states that an imported target is visible in the
current directory and below. What is the rationale for this behaviour?
It seems to be different from regular targets, where it can be
referenced everywhere
Rodolfo Schulz de Lima escreveu:
me. The documentation states that an imported target is visible in the
current directory and below. What is the rationale for this behaviour?
After some testing, the documentation is misleading. Actually cmake does
the right thing, it's possible to reference
Brad King escreveu:
Really? That isn't intended, and I can't reproduce it. Can you provide
an example of this?
Sorry Brad, I did a more thoughtful test and cmake works according to
the documentation. In my previous test cmake was referencing directly
the library in /usr/lib instead of
Michael Jackson wrote:
I'll throw a no vote on that but what I would like to hear is some
more detail from Rodolfo explaining why he thinks he needs this? Have
you tried embedding the build directory inside the source directory?
Some of us use this type of setup and it seems to work really
On Thu, Dec 03, 2009 at 12:41:59PM -0500, Bill Hoffman wrote:
Tools like emacs and other build tools can be taught how to deal with
the sources not being right there. The symlinks will likely be a pain
to maintain. What happens when a file is removed in the source tree?
Who updates the
Rodolfo Schulz de Lima wrote:
About emacs/vi, they can locate the source file only if we're going
though an error list, as gcc spits out the path to the source files
involved. But if you want to load another file, you must do it yourself,
which can be irritating sometimes.
Sorry to reply
Michael Jackson wrote:
I guess those of us that use IDEs like Visual Studio, Eclipse, NetBeans,
Xcode, CobeBlocks, QtCreator may not see the issue you are trying to
solve.
That's precisely it, I'm use an old-school setup, Vi + make, and my idea
would certainly be helpful in this case.
Bill Hoffman wrote:
And, they can still have that, but I once they get used to it, I bet
they will like it...
Sorry Bill, I think I didn't understand, you mean that they will like to
have source code in a different directory than Makefile's?
Another option might
be a tool on top of CMake.
Jed Brown wrote:
See etags/ctags (this is ancient technology). Also semantic (part of
cedet for emacs) does semantic analysis so it can jump more
intelligently between files (i.e. determine the type of a variable and
jump to the appropriate definition).
Hi Jed, I know about ctags and the
Andreas Pakulat wrote:
See my other mail, there's no way for cmake to find out which symlinks
are dead links, except by scanning all source files on a cmake run.
Thats a huge waste of time, especially on bigger projects with a few
thousand files scattered over a few hundered directories.
I
Andreas Pakulat wrote:
We're using out-of-source builds (custom buildsystem) at work for about
almost a year now. And in fact none of the developers uses an IDE, its
emacs or vi. And none of them ever complained about that particular
problem, I don't know exactly how they manage that (I'm
Jed Brown wrote:
I use command-find-tag M-. and enter (a) part of the file name (not
including the path) or (b) part of the function name, with tab
completion, or (c) part of the struct name also with tab completion, and
it takes me to the definition. No need to enter paths, and this works
Michael Jackson wrote:
cmake -C ${workspace_loc}/${project_name}/Build -j 16 VERBOSE=1
And the executables (as setup in the Cmake files) are always built into
Build/Bin.
This way you can only have one build tree per project. One way to extend
it is to use something like Build_${build_type}
Eric Noulard wrote:
Cscope is another light and fast (compared to IDE) alternative
Thanks Eric, I'm gonna check this one out. I've heard of it but never tried.
[]s,
rod
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
Eric Noulard wrote:
I'm using both vi+make and Eclipse CDT (for C/C++ project using CMake).
In fact I was a pure command line guy until the noise of mouse click
surround me and I decided to give a try to IDE way to see the code :-)
I went into the opposite direction, from mouse to keyboard,
Michael Jackson wrote:
True, but I can always change the build to something else if needed
(like a release). 98% of the time using Build works just fine. I think
there have been lots of great discussions and suggestions in this thread
that you should be able to find something that works for
Bill Hoffman escreveu:
What is in your CMakeCache.txt file?
Also, does this happen with a very simple one line cmakelist.txt file?
add_library(foo.cxx)
(of course you will have to create an empty foo.cxx)
I always test with a clean CMakeCache.txt (i.e., without it), and don't
even add a
Bill Hoffman escreveu:
Rodolfo Schulz de Lima wrote:
function call_command()
{
-- I think that passing 'COMMAND' is not needed, but it's ok if
-- one cares about maintaining the cmake script syntax.
ret = execute_process(COMMAND, whatever);
-- do something with ret
return
Bill Hoffman escreveu:
OK, I know I will regret this, but how would lua help here? Other than
the myscript.cmake would be myscript.lua and the syntax would by
slightly different, it would be the exact same thing. The issue is that
cmake and whatever language it uses is not around at build
Cristian Bidea escreveu:
Hello
Is it possible to set some C_FLAGS per target?! I know about the
global variable CMAKE_C_FLAGS but I don't need all the flags for all
the targets in the project.
Thank you!
I think you can set it with set_target_properties, for example:
In my setup, the xrc resource file is generated from another file
(wxformbuilder format) by a custom command, which calls wxformbuilder to
convert it to xrc. This one is input to WXWIDGETS_ADD_RESOURCES.
Since WXWIDGETS_ADD_RESOURCES tries to read from xrc BEFORE it is
created by
Bill Hoffman escreveu:
Right, so you want the execute_process to be executed at build time,
basically convert the lua/cmake to the right code for the generator.
Really has nothing to do with the language used. You want the
call_command function to run at build time. Your example is simple
Bill Hoffman escreveu:
Can you give an example that shows the unwanted semicolons?
For sure. Here's the setup:
test.c:
int main() {}
CMakeLists.txt:
list(APPEND CMAKE_C_FLAGS -Wall)
add_executable(test test.c)
when we run make, we have:
gcc: no input files
/bin/sh: -Wall: not found
make[2]:
Bill Hoffman escreveu:
That said, an automatic way of running a cmake script at build time as
part of a custom_command might be a good feature.
Well, if one of the reasons not to use lua is to avoid calling cmake
during build, why do it with a cmake script is a good thing?
I am thinking the
Brandon Van Every escreveu:
Certain CMake people want to *say* it was conclusive, so that the
issue will go away, but it wasn't conclusive. In particular, I have
to note the self-selecting nature of the CMake community. If you
stick around and duke it out with CMake, there's a pretty good
Bill Hoffman escreveu:
I never said that it was a bad thing to call cmake during the build we
do it all the time. That was the suggestion from Brandon that started
this whole thread (which I said I would regret :) ). To go one step
further from the suggestion would be to make it easy to
Bill Hoffman escreveu:
It really boils down to this: There is no way we can ever stop
supporting the current cmake language. It would be a huge break in
backwards compatibility. The prospect of having two languages forever
is not something I would like to do either. So, we will continue
Mike Jackson escreveu:
Don't forget that time is a real barrier, not a perceived one. How
long would you wait for the lua implementation. What other features
would you be willing to give up in order to have lua in x number of
months? Remember Kitware has to pay their employees. They get money
Brandon Van Every escreveu:
On Dec 14, 2007 7:43 AM, Rodolfo Lima [EMAIL PROTECTED] wrote:
If CMAKE_CXX_FLAGS is actually null, then your script should terminate
with an error. Correct syntax is either plain CMAKE_CXX_FLAGS or
${CMAKE_CXX_FLAGS}. What you've written would work only if the
Joshua Jensen escreveu:
Brandon asked me a short while ago to post a response I had made to a
thread on Sweng-Gamedev. I don't post this to fan flames or to even
form an opinion. It is just my experience in the matter.
What is written in the response is quite like what I feel when using
Brandon Van Every escreveu:
I'm not willing to concede the clarity. As I just wrote, backwards
compatibility is an issue to solve, not a dealbreaker. As for labor,
there's already a quorum of people interested in the issue, and CMake
forks have been threatened before. I'd like to see people
Brandon Van Every escreveu:
I can't call set(var value) ugly. I can call it slightly verbose,
as opposed to var=value.
Ugliness is highly subjective. I'm handsome, by the way :)
It is boring precisely because it is *not* error prone. It is a way
of ensuring against errors. If you haven't
Brandon Van Every escreveu:
CMAKE_*_LIBRARY_POSTFIX could serve the purpose of _d and so forth.
This is parallel with the meaning of CONFIG_POSTFIX in the docs.
I didn't know about CONFIG_POSTFIX. The documentation says that it is
used for all targets, including libraries, isn't it? So
Gonzalo Garramuño escreveu:
I honestly don't think it will take 10 more years for a tool to match
the benefits of cmake with a better syntax. As I have said before, I
think it is only 3 or so years away from happening.
What bugs me is the fact that cmake achieves like 90% of build system
First of all, thanks for the relatively quick commit of this feature to
cmake-cvs!
Brad King escreveu:
Thanks, we're looking at the patch. We typically have constructed the
set of source files for a target in a variable so they can be used later:
SET(mylib_SOURCES
mylib1.c
mylib2.c
)
Alexander Neundorf escreveu:
If you can find some spare time, there is a command argument parser in
CMake/Source/kwsys/, which is used e.g. by cpack, but not (yet) by cmake.
Using this in cmake is the first step in getting better support for custom
command line parameters. A patch would be
Bill Hoffman escreveu:
Command line options have been a feature request for some time. If
someone comes up with a good way to do them, I have no problem putting
them in CMake. I guess the problem has always been the iterative nature
of the CMakeCache.txt file. --help has to basically run
Bill Hoffman escreveu:
CVS CMake (and the coming 2.6 CMake) have extensive support for cross
compilation.
http://www.cmake.org/Wiki/CMake_Cross_Compiling
And I'm using it every day with success. I think there should be some
common toolchain files, for instance, to compile to mingw32 target,
Alexander Neundorf escreveu:
I don't think so.
analyzing the CMakeLists.txt means executing them basically completely.
See the following pseudocode:
if(WIN32)
define some args
else
define some other args
endif
You're right, I didn't give it much thought it deserves.
Oh, I think some
Alexander Neundorf escreveu:
Yes, you can get map-like behaviour by using just variables:
SET(MY_MAP_${KEY} myValue)
That's fine if ${KEY} doesn't have spaces nor characters that aren't
allowed in variable names. As I'm using a string containing compiler
flags and stuff, this solution isn't
Brandon Van Every escreveu:
On Dec 17, 2007 2:29 PM, Rodolfo Schulz de Lima [EMAIL PROTECTED] wrote:
A workaround would be
computing a hash from the string and using it as a key, but once again,
it'd be a pain in the *** to do it in cmake script.
I wouldn't shy away from trying it though. I
Brandon Van Every escreveu:
What's so hard about writhing a hash function using only MATH(EXPR
...) ? Geez, once upon a time there were guys who wrote this using
punch cards.
I have a life, I live in Copacabana, Rio de Janeiro/Brazil, it's summer,
those stuff, you know :)
Regards,
rod
Bill Hoffman escreveu:
Something like PCH support is a native build feature that CMake should
support. As such, it should be done in C++, and built into CMake. Some
work has been done to support this. The hard stuff for CMake should
be done in C++. That is the implementation language of
James Bigler wrote:
What is it that people want beyond -DBUILD_THIS_THAT_WHATEVER:BOOL=TRUE
could provide?
Do they want: --enable-build_this_that_whatever?
People that work with embedded systems might want a stripped down
version of a library, for instance. So disabling features might be
Brandon Van Every wrote:
Hmm, I wrote writhing a hash function, I wonder if that was a Freudian slip?
That's the problem with English, you people throw H's everywhere in
words! Throughout, although, though, thighs,... you don't know how hard
it is for a non-native speaker write those
There's a functionality that I'm missing in find_program(...). I must
find an executable that matches a regex expression.
What I'm trying to achieve is find the name of a cross-compiler. It
would be mingw32-gcc, i585-mingw32msvc-gcc, etc... so I would match
.*mingw32.*-gcc. Is there any other
Bill Hoffman wrote:
find_program(PROG NAMES name1 name2 name3)
You have to list all the names explicitly, but you can have as many as
you want.
That's what I'm using right know, but this doesn't address the more
general problem.
Regards,
rod
Alexander Neundorf wrote:
That's right.
As a practical solution, how about you add now the names you know of and if
you get reports of other names you add these too ?
That's what I'm doing, but I think it's a common use case that might
deserve a special support from cmake.
Regards,
rod
Alexander Neundorf wrote:
I have (currently) two ideas:
either a special file, e.g. CMakeCustomArgs.txt, which in some way sets up the
custom command line parameters.
There's a beauty in having everything inside CMakeLists.txt
Or have a cmake modules, which handles this stuff, and which
What are the implications of using FILE(REMOVE_RECURSE ...) instead of
FILE(REMOVE ...) on clean targets? I'm setting
CMAKE_ADDITIONAL_CLEAN_FILES to a directory that isn't being removed.
I've discovered that I must change REMOVE to REMOVE_RECURSE inside
Brandon Van Every wrote:
How about include(ForwardsCompatibility). That would make the intent
really clear.
IMHO a better solution would be to specify which CMAKE version is
expected to parse the CMakeFiles.txt. Hint: there's already the
cmake_minimum_required command (at least in
Brandon Van Every wrote:
I thought REMOVE_RECURSE was a straightforward unconditional nuke. I
don't see that cleanliness has anything to do with it.
Well, if I want to clean (remove) a directory, I'd expect it to be
removed regardless if it contains subdirectories.
Regards,
rod
Brandon Van Every wrote:
FILE commands are performed at configuration time. They don't have
any relevance to actions performed at build time. Not unless you've
wrapped them up in a CMake script and issued an ADD_CUSTOM_COMMAND of
the form COMMAND ${CMAKE_COMMAND} -P myscript.cmake.
I think
Brandon Van Every wrote:
Hint: there's already the
cmake_minimum_required command (at least in cmake-cvs, that is)...
cmake_minimum_required has been around for awhile now. It does not
solve the problem.
Why is it so? If I'm using, say, 2.10.0 stuff, I'd issue a
Brandon Van Every wrote:
Let's say really old code does cmake_minimum_required(VERSION 2.2.0
FATAL_ERROR). CMake 2.6.0 meets that minimum requirement. It should
run the old code correctly, unless there's a really really good reason
to break backwards compatibility. CMake 2.6.0 isn't going to
Brandon Van Every wrote:
Sounds like a bug. File a reproducer in the bug tracker.
Yes, that's what I thought. I've filled bug report #6180 with a patch to
correct this.
Regards,
rod
___
CMake mailing list
CMake@cmake.org
Alexander Neundorf wrote:
Hi,
there were a lot of emails, I'll try to make a summary.
So what is needed to get a big market share for cmake and what seems to be
required in cmake features.
This is not intended to be a task list for Kitware, e.g. ant and the support
for languages would be nice
Bill Hoffman escreveu:
will be set. The real answer is that the command line is a poor
interface to cmake projects. The new QT GUI is a much better way to go.
Don't say that... I think that a command line interface capability
should be pursued, even if it's non-optimal. God knows if
I wonder if the cmake developers are following this thread, given its
importance...
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Brandon Van Every escreveu:
On Dec 19, 2007 1:52 AM, Gonzalo Garramuño [EMAIL PROTECTED] wrote:
Sure, lua runs 10 times faster than the cmake language does, but that's
a different story.
So what's the story? Can you substantiate that?
There's an implementation of cmake with lua at
Brandon Van Every escreveu:
We don't want things to work as expected, we want things to work correctly.
This is getting nowhere...
Can you create an example of such error condition?
What if VERBATIM behavior becomes easier to work with? Or quoting
behavior in corner cases? What if macros
You are right. I was confusing cmake time with build time. However, what
is
to stop you building your own version of wxwidgets as an external project?
Then cmake; make, etc., would have to be run once to build wxwidgets and
once for your project. If that turned out to be too complicated for
In my NOT so humble opinion, this is a REALLY bad idea and here is why.
I second this. In linux who deals with /usr is the package manager (apt,
portage etc). If I deliberately install something there, the package manager
won't know about it and maybe something might be overwriten in the
No personal experience myself, but the PLplot bare windows (i.e., no
Cygwin,
or MinGW) developers tell me there is a bash for windows that they can
install. So ctest (which in our case runs shell scripts) is
cross-platform
for PLplot iff the windows user has installed bash. However, instead
Hi people,
I've been wondering if there's any will among cmake developers to use
subversion as source versioning management system.
CVS is showing its age, and the benefits I see in migrating to subversion
are:
1) changeset-oriented commits: that's what I miss the most. I want to know
what
Write a CMake script containing the configure command. Invoke it at
build time using ADD_CUSTOM_COMMAND COMMAND ${CMAKE_COMMAND} -P
myscript . Of course, this isn't going to configure anything. :-)
Are you just trying to perform text substitutions or something?
If he's trying to compile an
That's great news. Since I've never been involved in a CVS - SVN migration,
I couldn't help so much with it. Also, excuse me for assuming you weren't
using svn and trying to sell it to you :)
Regards,
rod
___
CMake mailing list
CMake@cmake.org
Note, you don't have to do any of the above with add_custom_command. In
principle, you could also do those external builds with execute_process.
The difference, of course, is execute_process runs at CMake time so that
solves the issue we discussed before of wx-config from your build of
wxwidgets
Use cvs2cl and read the ChangeLog file that the command creates. I only
know
it on Linux though. The result is pretty much the same as svn log.
Thanks Hendrik, this will be a valuable tool.
svn doesn't really do tagging and branching, it only does copies.
Which accomplishes the same
Josef Karthauser wrote:
Does it correctly include the contents of ${BUILD_TYPE}_POSTFIX? I'm
using 2.4.7, and reported a few weeks ago that the value of LOCATION
doesn't include the postfix. Andreas Pakulat confirmed that he was
seeing the same thing. Are you saying that it works for you?
Hi, I'd like to comment on the Find*.cmake variable naming procedure
adopted by cmake. Right now I have to look at some Find*.cmake files to
see what are the output variables they create. Some packages create a
*_LIBRARY, others *_LIBRARIES, others *_INCLUDE_DIRS and others
*_INCLUDE_DIR. The
Josef Karthauser wrote:
Hmm, I can't see where it would have been fixed. Can one of the
developers please comment?
If you look at Sources/cmTarget.cxx:1987, you'll read:
// Append the per-configuration postfix.
outBase += configPostfix?configPostfix:;
before that configPostfix is set to the
Bill Hoffman wrote:
Something like this:
find_package(bar REQUIRED)
add_executable(foo foo.cxx)
target_link_libraries(foo bar)
This would be GREAT! What is the status on this one? Is it ready waiting
for testing or you are still developing it? I could use this right now.
Thank you very
Rodolfo Schulz de Lima wrote:
Sorry people, I was wrong. Actually when you get the target's LOCATION
property, the name returned doesn't have any postfix attached. To get
the name with a debug postfix, one should get the DEBUG_LOCATION
property, for instance.
Regards,
rod
Miguel A. Figueroa-Villanueva wrote:
Again, I think this behaviour is a quite unintuitive and should be
well documented, at least.
I shall add that at first I expected 'raise_scope' to work like 'set'
when the parameter value is a list. But, for instance:
set(mylist item1 item2 item3)
Brad King escreveu:
I've just implemented the request in 1645 in CMake HEAD. If you call
Thank you very much Brad, I've just seen it while updating from cvs.
I'll give it a try with my own modules here.
Regards,
rod
___
CMake mailing list
Alexander Neundorf wrote:
But I also had the same idea already several times.
Can you add a feature request in teh bug tracker ?
It's done, issue #6274
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
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
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
Bill Hoffman escreveu:
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
Rodolfo Schulz de Lima escreveu:
building, that's what you're being paid to do, not to create another
language, there's already a ton of them. The down side is backward
Hi, I think I've used the wrong words here, I'm not saying what
someone's being paid to do... that could be harsh out
Bill Hoffman escreveu:
Enjoy!
Wow, that must be a world record... I've mentioned the problem at 10:57
(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.
Best Regards,
rod
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).
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
Bill Hoffman escreveu:
This is a difficult decision for me. I have never been forced into a
situation like this. However, Brandon's posts to this list have been
disruptive to the community and myself. I have therefore come to the
conclusion that Brandon needs to be kicked off the list.
85 matches
Mail list logo
