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
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
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
http
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_typ
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 wor
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 u
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
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
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
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.
> S
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
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
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 reall
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 (wrong
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 t
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
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.
We
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 ext
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,
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
___
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
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
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
i
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 buildi
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
Hi, currently when invoking make to generate an assembly output, it
generates it inside CMakeFiles/.dir. Is it possible to generate
it in the ${CMAKE_CURRENT_BINARY_DIR}? That's where I'd expect it to go
since I'm doing a 'make .s' in this directory.
Regards,
rod
_
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
CMake@
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 is a list. But, for instance:
set(mylist item1 item2 item3)
set(var1
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.
Re
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 much
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 th
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 M
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?
W
"Alexander Neundorf" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
Why do you need that at build time ?
If the lib is built in the same project, you can get the flags directly
from
there.
In all other cases it should be possible to write a cmake test to figure
it
out or to load
"Alexander Neundorf" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
No, that's not possible.
Is there any interest in making this possible?
Regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cma
By setting the mode to ONLY cmake will look ONLY in the directories with
the
CMAKE_FIND_ROOT_PATH prefix.
Yes, I do this. The problem is that those scripts hardwire some default
paths to the native places where headers and libraries are found. When we
cross-compile, those defaults should be c
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 bus
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
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
ht
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 ex
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
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 o
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 fut
(through property svn:externals, for the svn-inclined)
3) make -j2
...
Thanks to cmake my recipe is the same no matter the environment my
Sorry, I lied, on windows he would have to use 'nmake' or fire up Visual
Studio IDE, but he's used to this, so it's a no brainer.
Abraços,
rod
_
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 you
Is there a way to override CMAKE_BUILD_TYPE per target?
For instance, I'd like to write:
set_target_properties(target PROPERTIES BUILD_TYPE Release)
And have my target compiled in Release mode regardless of the current value
of CMAKE_BUILD_TYPE.
Regards,
rod
__
Have a look at the internals of FindwxWidgets.cmake that comes with
CMake-2.4.7. It uses wx-config for the case where wxwidgets is already
externally installed. It should be straightforward to adapt this module
for
the case where you are building wxwidgets internally.
I cannot use wx-config
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
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
http:/
Brandon Van Every escreveu:
You could use a macro to generate a CMake script containing a macro,
and then call that script. :-)
Nice... :)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
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
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 someon
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 nic
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
http://www.cmake.org/mai
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:
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
cmake_minimum_required(VERS
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 y
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:
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 cmake-cvs
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
MakeFiles/project.dir/cmake_clean.cmake
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 also
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
__
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
__
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 othe
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 corre
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 a
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
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
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
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
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 cm
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,
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 t
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 very
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
)
AD
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
fe
Brandon Van Every escreveu:
CMAKE_*_LIBRARY_POSTFIX could serve the purpose of "_d" and so forth.
This is parallel with the meaning of _POSTFIX in the docs.
I didn't know about _POSTFIX. The documentation says that it is
used for all targets, including libraries, isn't it? So
CMAKE_*_LIBRARY
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'
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
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 mone
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
CMa
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 th
Bill Hoffman escreveu:
OK, Dave Cole, just pointed out that list is the wrong thing to use
here. The CMAKE_C_FLAGS variable is supposed to be a string and not a
list. If you used list(APPEND more than once it would always fail. So,
although odd that it has a space in it, it is benign. You sh
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 t
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 use
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 chanc
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
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 and
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 wxformbuilder
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:
set_target_properties(ta
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");
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 lib
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 tim
94 matches
Mail list logo