Re: [CMake] absolute rpath
On Friday, 29. February 2008 00:18:18 Alexander Neundorf wrote: So you need your program to be executable anywhere in the file system, and it also has to find its shared libs ? Would setting PATH be a alternative ? Yes, setting PATH or LD_LIBRARY_PATH in a shell wrapper is an alternative. You could create automatically shell scripts which do that for you. Does automatically mean by CPack? The docu about CPack is quite short (Is No. Automatically means that you can write a macro which wraps add_executable() and which also creates such a wrapper script. I'll try it this way. Thanks a lot for your help! Jörg ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Converting a VS Build to CMake/Problems with Post-Build steps, questions
Hello,
I'm currently converting a fairly large project over to CMake. This is
my first contact with CMake, so I might be trying to do things totally
wrong, anyway, I've encountered some problems which I could not solve.
Searching the Web or reading the FAQ didn't help; is there any way to
search the mail archives easily?
Setup:
Visual Studio 2008 / Vista, I'm porting the x64 part only at the
moment. Using CMake 2.4.8.
Problems:
* I want to name my debug libraries with a trailing 'd'. I use
SET_TARGET_PROPERTIES(MyTarget PROPERTIES DEBUG_POSTFIX d) to do this.
However, MyTarget is a unit-test runner and I want to execute it using
ADD_COMMAND as described here
http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_generate_an_executable.2C_then_use_the_executable_to_generate_a_file.3F
albeit without the output:
GET_TARGET_PROPERTY(PRJ_UT_TARGET MyTarget OUTPUT_NAME)
ADD_CUSTOM_COMMAND(
TARGET MyTarget
POST_BUILD
COMMAND ${PRJ_UT_TARGET} VERBATIM
)
This works fine for release, but not for debug, as it always returns the
name without the prefix. How is this supposed to work?
* Is there a way to force both Debug and Release to end up in the
same folder? The VC++ project builder seems to put Debug into
EXECUTABLE_OUTPUT_PATH/Debug always, and I found no way to force it to
put both into the same. Rationale behind this is that my project needs
some more files in order to run, and I'd like to put the binaries right
into this data folder (instead of copying the data around during
pre/post-build ...).
* Is it possible to have x86 x64 configurations inside a single VC
solution? During configure, I have to choose either x64 or x86. This is
nothing serious, I'm just wondering.
* What is the recommended way to check for x64 Windows? I'm using a
custom option, but I'd like to have that fully automatic if possible. I
only found this list here
http://www.cmake.org/Wiki/CMake_Useful_Variables#System_.26_Compiler_Information
-- is there some more up-to-date place?
Cheers,
Anteru
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] linking to arbitrary libraries in linux.
Alexander Neundorf wrote: On Friday 29 February 2008, David Cole wrote: On 2/28/08, Alexander Neundorf [EMAIL PROTECTED] wrote: target_link_libraries(targetName /full/path/to/libName.a) FYI: The /full/path/to/ feature was only recently added to CVS CMake. The specify lib by a full path technique may not work as you'd expect in CMake 2.4.8 If you want to use full paths in target_link_libraries calls, be sure to use CVS CMake. No, just the behaviour has been changed, to make sure always the right library is used if there are multiple libs (versions) with the same name. Using target_link_libraries(hello /my/custom/path/libfoo.so) is working since I think very early cmake versions (that's also what find_library() returns) This is correct. With ALL versions of CMake, it is better to give the full path to a library you are linking to. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake and Lua
James Mansion wrote: Sebastien BARRE wrote: Again: *deal*. February 29th, 2010 *precisely*. Special CMake/Lua day, the 29th. That will indeed be a very special day. Shame really. I like Lua, and I find that the CMake script language seems designed to make COBOL coders feel they don't actually have the worst job in the world. So what exactly about the CMake language gives you this feel? And a SWIG based wrapping of the C++ code would surely allow extension of the core in 'soft' languages too, so that generators could be develeoped and so on too. But if we did that would we have a binary that that had all the wrapped languages? CMake is meant to be a build tool, and not a toolkit library. There are already adoption issues because you have to install CMake before you can do a build. Imagine how much worst it would be if you had to pick the right language variant of CMake before you could build a package using CMake. I love SWIG and language wrapping and it makes sense for a library of visualization or computer vision tools. However, in the case of a build system it would be a tower of babel. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem of dependencies
Alexander Neundorf wrote: On Wednesday 27 February 2008, Guillaume Damiand wrote: Hello, I have discovered cmake one week ago and I am very impressed by its powerful and facility of using. However, I have a problem concerning dependencies and I have not found any solutions in forums or documentations. I use 3 types of files .hh et .cc (as usual) and .icc for inline fonctions. I have two macros INCLUDE_INLINE and INCLUDE_NON_INLINE which allow, given a compilation option, to include an .icc file into a .hh or a .cc depending if we want to inline fonctions or not. cmake already scans the source files for included files. In your case the included .icc files are not found ? You can check e.g. CMakeFiles/target.dir/depend.internal for that. If that's the case I think you can adjust some regular expression variable so that your include fioes are also recognized. The problem is that cmake does not expand macros, it only looks for #include lines. In this case the #include lines are macros, so cmake can't figure out what is being included. A work around that we use in kwsys is this: #include KWSYS_HEADER(ios/iostream) #include KWSYS_HEADER(ios/fstream) #include KWSYS_HEADER(ios/sstream) // Work-around CMake dependency scanning limitation. This must // duplicate the above list of headers. #if 0 # include SystemTools.hxx.in # include Directory.hxx.in # include kwsys_ios_iostream.h.in # include kwsys_ios_fstream.h.in # include kwsys_ios_sstream.h.in #endif I am thinking we may want to look at a more general fix to this problem. Feel free to create a feature request. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMake and Lua
Bill Hoffman escreveu:
So what exactly about the CMake language gives you this feel?
Hi, let me just add my opinion on this one. I really think that in a if
clause, having to repeat the condition in the else, elseif and endif is
a little too much verbose for my taste. The following snippet
illustrates this issue
IF(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR})
set(outofbuild true)
ELSE(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR})
set(outofbuild false)
endif(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR}
I know that we can disable this *feature*, but it isn't default. I know
you did this to help programmers know which 'if' an 'endif' is related,
but this kind of thing is normally done with comments. And in my example
above since each branch has one line, the verbosity is unnecessary.
The set clause is also a little bit awkward. I really think that cmake
began as a really simple language for simple things, but then it needed
to support some complex stuff and some features were hammered into the
language, and the simple syntax just couldn't afford it, and we ended up
with the cmake script language we have now.
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...
Best regards,
rod
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Converting a VS Build to CMake/Problems with Post-Build steps, questions
From: Anteru [EMAIL PROTECTED]
I'm currently converting a fairly large project over to CMake.
This is how I got into CMake, albeit without the x86/x64 wrinkle. It
took some effort to switch the project over, but I am very glad we did.
Caveat: The following is based on a much older version of CMake which
I've been using for the same project for about five years.
* I want to name my debug libraries with a trailing 'd'. I use
SET_TARGET_PROPERTIES(MyTarget PROPERTIES DEBUG_POSTFIX d) to do
this.
However, MyTarget is a unit-test runner and I want to execute it using
ADD_COMMAND as described here
http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_generate_an_executable.2C_t
he
n_use_the_executable_to_generate_a_file.3F
albeit without the output:
GET_TARGET_PROPERTY(PRJ_UT_TARGET MyTarget OUTPUT_NAME)
ADD_CUSTOM_COMMAND(
TARGET MyTarget
POST_BUILD
COMMAND ${PRJ_UT_TARGET} VERBATIM
)
This works fine for release, but not for debug, as it always returns
the
name without the prefix. How is this supposed to work?
We've always done it like this on the biggest project I have under
CMake:
ADD_CUSTOM_COMMAND(
TARGET my_target
COMMAND ${my_project_BINARY_DIR}/my_path/my_unit_test
)
In cases where we needed the debug file name to be different from the
release file name, we defined a variable for that file name, with an IF
command to determine whether the variable is defined as the release file
name or the debug file name. Then we would just write ${MY_UNIT_TEST}
instead of my_unit_test. But we also invoke CMake from a script that
sets the variable BUILD_RELEASE when we want to build in release mode,
so we have an obvious IF condition. I suspect there's a way to test for
debug or release if you don't do this, but I've never bothered to find
out.
* Is there a way to force both Debug and Release to end up in the
same folder? The VC++ project builder seems to put Debug into
EXECUTABLE_OUTPUT_PATH/Debug always, and I found no way to force it to
put both into the same. Rationale behind this is that my project needs
some more files in order to run, and I'd like to put the binaries
right
into this data folder (instead of copying the data around during
pre/post-build ...).
We do this:
SET(CMAKE_LINKER_OUTPUT_FILE
${my_project_BINARY_DIR}/my_path/my_executable)
Actually, we use a CMake MACRO definition to invoke this and a bunch of
other commands on each library and executable we build, so we have, for
example, ${exe_file_name}.exe instead of my_executable for an
executable output, where exe_file_name is a parameter of the MACRO.
But that's because we build many libraries and executables, and it would
have been quite tedious to have to maintain all the commands for each
one independently.
There's probably a way to do these things that uses CMake to do more of
the details, but I've taken the approach to rely on CMake to get the
basics right (which it does very well, for things that would be very
hard for me to do without it), and to do the fancy stuff myself on top
of that. That's why I have about four or five different scripts to
invoke CMake with different sets of variables defined depending on what
kind of build I want to make.
David Karr
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake and Lua
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 ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake and Lua
Will Kitware consider making CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS default to on starting with 2.6.0 and doing away with this annoying construct? I think it would be a cool things to do this. Soon I will reformat all our scripts to remove this uneeded stuff, I'm pretty sure that a lot of CMake users will also do it. --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMake and Lua
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 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. It's tough... I mean, if you follow the cmake script road, you'll have to 'reinvent the wheel', so to speak, while adding 'return', 'break', 'continue' (it already has scoped variables). The more features you add, more you turn cmake script in to a full blown script language, but, as I said, built on a weak and awkward syntax. God knows what this 'Frankenstein' will become. But, if you decided to go to the Lua way, it's everything there, semantics, syntax, garbage collector, etc, you just have to worry about writing primitives that deals with your specific needs, i.e., project 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 compatibility, which is a valid and important commitment to have. So, like 99% of engineering problems, you can't have it all, there's always a restriction. The idea of isolating cmake from the language parsing isn't to make cmake a tower of babel (like .NET is, for instance). It's just to have an infrastructure that would enable you to maintain backwards compatibility with the cmake syntax, which would be deprecated, and a hopefully new Lua syntax. With a well thought infrastructure, you wouldn't have problems to maintain 2 languages. Just correct bugs on the old syntax as they appear, and add features on the new syntax. If someone want the new feature, well, he should move to Lua. It's a tough decision that should have been made in the beginning, but postponing it just make it worst... Best regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Re: CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE by default
Will Kitware consider making CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS default to on starting with 2.6.0 and doing away with this annoying construct? Bill is looking into making this implicit. .e.g. if you do not specify the matching arguments then you are using LOOSE_LOOP_CONSTRUCTS by default. So folks who want it will get it, folks who do not will not get it, effectively automatically on a construct by construct basis. Ken ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake and Lua
On Fri, Feb 29, 2008 at 8:57 AM, Rodolfo Schulz de Lima [EMAIL PROTECTED]
wrote:
Bill Hoffman escreveu:
So what exactly about the CMake language gives you this feel?
Hi, let me just add my opinion on this one. I really think that in a if
clause, having to repeat the condition in the else, elseif and endif is
a little too much verbose for my taste. The following snippet
illustrates this issue
IF(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR})
set(outofbuild true)
ELSE(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR})
set(outofbuild false)
endif(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR}
I know that we can disable this *feature*, but it isn't default. I know
you did this to help programmers know which 'if' an 'endif' is related,
but this kind of thing is normally done with comments. And in my example
above since each branch has one line, the verbosity is unnecessary.
I wholeheartedly agree. I don't think people realize how unreadable,
unmaintainable, and confusing this feature really is.
It's unreadable because you have to read the same crap over and over again
(occupying at least 3 lines, sometimes 6 depending on how complex the
conditional is).
It's unmaintainable because every time you make the slightest modification
to your original IF() statement you have to modify both ELSE() and ENDIF().
It's confusing because most people using CMake are programmers and most
modern programming languages have no such requirement in their conditionals,
function declarations, etc.
Can you imagine if C had been written so you had to do this:
if(x == 6 y = 15)
{
// do something
}
else if(x ==6 y 15)
{
// do something else
}
else(x==6 y = 15)
{
// the programmer is extremely confused here... It looks like another
ELSEIF() but it's not.
}
endif(x==6 y = 15)
Will Kitware consider making CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS default to on
starting with 2.6.0 and doing away with this annoying construct?
--
Philip Lowman
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE by default
On Feb 29, 2008, at 8:00 AM, Sylvain Benner wrote: Will Kitware consider making CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS default to on starting with 2.6.0 and doing away with this annoying construct? I think it would be a cool things to do this. Soon I will reformat all our scripts to remove this uneeded stuff, I'm pretty sure that a lot of CMake users will also do it. Yeah, I can't use this feature, because there's a lot of monkey see, monkey do at my work where the developers are not that familiar with CMake. If someone copied my code or included it from another project it will just not work causing confusion. If it was the default, then I could start using such a feature and just demand this script code be used in cmake = 2.6 (I could even force this in scripts that include it by forcing a minimum cmake version). James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Having problems getting started
I'm trying to get started using CMake, but I'm having a couple of issues:
1. Is there some way to use wildcards when specifying files for a library?
Something like this:
add_library(VSEngine *.cpp)
That particular line doesn't work. I tried, but there must be a way that I
can add a file to a project without having to modify the makefile.
2. I found what I think is a flaw in the FAQ, though I don't know the
resolution for it. In the FAQ, there's a question about using SWIG. In the
answer two examples are given. One with python and one with TCL. Since my
project uses TCL, I thought I could follow along to a certain extent, but
when I added the line:
TARGET_ADD_LIBRARY(${MODULE_NAME} TCL_LIBRARY)
I received an error telling me that TARGET_ADD_LIBRARY doesn't exist. Did I
miss something here?
Thanks in advance for the help, folks.
-Arlen
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cmake cannot find source file / Cmake can not determine linker language
Simply, in a subdirectory: ADD_LIBRARY (sift_h common.hxx) and altho the file common.hpp is there, he returns 'Cmake cannot find source file .../.../common.hxx for target sift_h tried extensions ... .hpp ...' if i change the CMakeLists in that subdirectory to ADD_LIBRARY (sift_h common.hpp) he doesn't complain at first, but when Ok is clicked 'Cmake can not determine linker language for target:sift_h' .. wth? the CMakeLists in ROOT is PROJECT (SIFT) ADD_SUBDIRECTORY (includes) ADD_EXECUTABLE (siftpp main.cpp) TARGET_LINK_LIBRARIES (siftpp sift_h) -- Dario Figueira ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE by default
Ken Martin wrote: Will Kitware consider making CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS default to on starting with 2.6.0 and doing away with this annoying construct? Bill is looking into making this implicit. .e.g. if you do not specify the matching arguments then you are using LOOSE_LOOP_CONSTRUCTS by default. So folks who want it will get it, folks who do not will not get it, effectively automatically on a construct by construct basis. Done: /cvsroot/CMake/CMake/Source/cmForEachCommand.cxx,v -- cmForEachCommand.cxx new revision: 1.27; previous revision: 1.26 /cvsroot/CMake/CMake/Source/cmFunctionCommand.cxx,v -- cmFunctionCommand.cxx new revision: 1.5; previous revision: 1.4 /cvsroot/CMake/CMake/Source/cmIfCommand.cxx,v -- cmIfCommand.cxx new revision: 1.83; previous revision: 1.82 /cvsroot/CMake/CMake/Source/cmMacroCommand.cxx,v -- cmMacroCommand.cxx new revision: 1.35; previous revision: 1.34 /cvsroot/CMake/CMake/Source/cmMakefile.cxx,v -- cmMakefile.cxx new revision: 1.438; previous revision: 1.437 /cvsroot/CMake/CMake/Source/cmWhileCommand.cxx,v -- cmWhileCommand.cxx new revision: 1.11; previous revision: 1.10 Enjoy! -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMake and Lua
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 of context, don't take it literally. Regards, rod ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE by default
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 ___ 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
[EMAIL PROTECTED] schrieb:
Caveat: The following is based on a much older version of CMake which
I've been using for the same project for about five years.
Just out of curiosity, how much maintenance work was required for those
project files over the five years? Switching from a VS to a new one
takes some while, and I wonder how good CMake's forward/backward
compatibility is :)
Actually, we use a CMake MACRO definition to invoke this and a bunch of
other commands on each library and executable we build, so we have, for
example, ${exe_file_name}.exe instead of my_executable for an
executable output, where exe_file_name is a parameter of the MACRO.
But that's because we build many libraries and executables, and it would
have been quite tedious to have to maintain all the commands for each
one independently.
So you are hard-wiring all the executable names per config? Doesn't this
make the stuff extra hard for the developers if they have to open a
different config for debug and release? I like the convenience of having
both available in a single config, as I can easily switch between
debug/release then (I'm using VS).
I just really need those different names, otherwise a debug lib could
easily end up in a release ... plus, as noted, I'm actually trying to
put both into the same folder to avoid copying around data :)
of that. That's why I have about four or five different scripts to
invoke CMake with different sets of variables defined depending on what
kind of build I want to make.
Unfortunately, this is exactly why I'm trying over to switch to CMake,
as I want to get rid of pre- postprocessing scripts as much as
possible. For instance, I could get already rid of my custom install
script with the INSTALL command, which is really great.
Thanks for the insights into your approach, if there is indeed no better
solution I'll probably have to resort to something similar, I'm just
hoping that there is indeed a solution that gives me all the comfort of
the current VS build.
Cheers,
Anteru
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMake and Lua
On Fri, Feb 29, 2008 at 9:55 AM, Philip Lowman [EMAIL PROTECTED] wrote:
On Fri, Feb 29, 2008 at 8:57 AM, Rodolfo Schulz de Lima
[EMAIL PROTECTED] wrote:
Bill Hoffman escreveu:
So what exactly about the CMake language gives you this feel?
Hi, let me just add my opinion on this one. I really think that in a if
clause, having to repeat the condition in the else, elseif and endif is
a little too much verbose for my taste. The following snippet
illustrates this issue
IF(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR})
set(outofbuild true)
ELSE(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR})
set(outofbuild false)
endif(NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR}
I know that we can disable this *feature*, but it isn't default. I know
you did this to help programmers know which 'if' an 'endif' is related,
but this kind of thing is normally done with comments. And in my example
above since each branch has one line, the verbosity is unnecessary.
I wholeheartedly agree. I don't think people realize how unreadable,
unmaintainable, and confusing this feature really is.
It's unreadable because you have to read the same crap over and over again
(occupying at least 3 lines, sometimes 6 depending on how complex the
conditional is).
The problem is, there's an impedance mismatch between short and long
contexts. The repetition is *very* readable and helpful when the
branch is long enough that you have to scan through 20 lines of code
to see what's going on. Would it be a sin to require that if..else
statements more than 20 lines apart have matching clauses? I suppose
that could end up being a PITA for macros expanding within macros, as
the line lengths could easily change. But it's tempting to have one's
cake and eat it too. I don't buy the do it with comments approach.
Something changes, then the comments are wrong. That's why CMake
throws an error when you change a clause and they don't match.
I grudgingly admit that in terms of marketing prejudice, most
newcomers will hate the repetition. I think that's blind prejudice on
their part and that the repetition has technical merit. But I agree
it doesn't have marketing merit.
It's unmaintainable because every time you make the slightest modification
to your original IF() statement you have to modify both ELSE() and ENDIF().
That's not unmaintainable, that's forced maintenance. Compilers give
warnings and throw errors, it's no different.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE by default
On Fri, Feb 29, 2008 at 10:40 AM, Ken Martin [EMAIL PROTECTED] wrote: Will Kitware consider making CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS default to on starting with 2.6.0 and doing away with this annoying construct? Bill is looking into making this implicit. .e.g. if you do not specify the matching arguments then you are using LOOSE_LOOP_CONSTRUCTS by default. So folks who want it will get it, folks who do not will not get it, effectively automatically on a construct by construct basis. I agree that from a marketing standpoint, this makes sense. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Having problems getting started
You may want to look at the
file(GLOB variable [RELATIVE path] [globbing expressions]...)
or
file(GLOB_RECURSE variable [RELATIVE path]
[globbing expressions]...)
if you do a cmake --help-command file a print out of the
documentation for that command will be listed.
Also,
Some projects use the following as the way to get source files:
SET (MyProject_SRCS SomeFile.cpp SomeOtherFile.cxx lib/
SomeLibFile.cpp )
ADD_LIBRARY(VSEngine ${MyProject_SRCS})
That will default to a static library. If you want a shared library:
ADD_LIBRARY(VSEngine SHARED ${MyProject_SRCS})
--
Mike Jackson
On Feb 29, 2008, at 11:37 AM, Arlen Cox wrote:
1. Is there some way to use wildcards when specifying files for a
library? Something like this:
add_library(VSEngine *.cpp)
That particular line doesn't work. I tried, but there must be a
way that I can add a file to a project without having to modify the
makefil
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Having problems getting started
Thanks Mike.
That was exactly what I was looking for.
-Arlen
On Fri, Feb 29, 2008 at 11:20 AM, Mike Jackson [EMAIL PROTECTED]
wrote:
You may want to look at the
file(GLOB variable [RELATIVE path] [globbing expressions]...)
or
file(GLOB_RECURSE variable [RELATIVE path]
[globbing expressions]...)
if you do a cmake --help-command file a print out of the documentation
for that command will be listed.
Also,
Some projects use the following as the way to get source files:
SET (MyProject_SRCS SomeFile.cpp SomeOtherFile.cxx lib/SomeLibFile.cpp
)
ADD_LIBRARY(VSEngine ${MyProject_SRCS})
That will default to a static library. If you want a shared library:
ADD_LIBRARY(VSEngine SHARED ${MyProject_SRCS})
--
Mike Jackson
On Feb 29, 2008, at 11:37 AM, Arlen Cox wrote:
1. Is there some way to use wildcards when specifying files for a
library? Something like this:
add_library(VSEngine *.cpp)
That particular line doesn't work. I tried, but there must be a way that
I can add a file to a project without having to modify the makefil
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cmake cannot find source file / Cmake can not determine linker language
I am guessing here, but I _think_ cmake really wants a .cpp/cxx/c file instead of a header file. -- Mike Jackson Senior Research Engineer Innovative Management Technology Services On Feb 29, 2008, at 11:21 AM, Dario Figueira wrote: ADD_LIBRARY (sift_h common.hpp) ___ 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
Brandon Van Every schrieb: http://public.kitware.com/pipermail/cmake/ does have a searchbox at the top. It forwards to a Kitware webpage that performs broader searches than just CMake. I don't consider this to be entirely desirable behavior, but it is often passable. If it isn't, then I suggest using Google Advanced Search directly on the URL http://public.kitware.com/pipermail/cmake/ . The latter is a trick you can generally use for any mailing list archive, unless the archive has been made invisible to non-subscribers. This is rather interesting: Searching for postfix execute in the Search Box leads to http://preview.tinyurl.com/25pqdw -- it does not search the archives properly, at least it didn't find anything useful? OTOH, searching via Google and restricting the site does turn up some valid results: http://preview.tinyurl.com/yu5abe Searching the archives with Yahoo also ends up with no results. That's why I supposed there is some anti-search-engine stuff going on first. The suggested workaround for the debug/release folder problem seems to be setting the PREFIX to ../. This does solve the problem; is there some better/cleaner solution for this? Otherwise I'll stick with it. Leaves the other problem only, seems it has been discussed already (http://preview.tinyurl.com/yw6vlc) without a definite answer whether it is a bug or not. Cheers, Anteru ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE by default
On Fri, Feb 29, 2008 at 12:19 PM, Bill Hoffman [EMAIL PROTECTED] wrote: Ken Martin wrote: Will Kitware consider making CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS default to on starting with 2.6.0 and doing away with this annoying construct? Bill is looking into making this implicit. .e.g. if you do not specify the matching arguments then you are using LOOSE_LOOP_CONSTRUCTS by default. So folks who want it will get it, folks who do not will not get it, effectively automatically on a construct by construct basis. Done: /cvsroot/CMake/CMake/Source/cmForEachCommand.cxx,v -- cmForEachCommand.cxx new revision: 1.27; previous revision: 1.26 /cvsroot/CMake/CMake/Source/cmFunctionCommand.cxx,v -- cmFunctionCommand.cxx new revision: 1.5; previous revision: 1.4 /cvsroot/CMake/CMake/Source/cmIfCommand.cxx,v -- cmIfCommand.cxx new revision: 1.83; previous revision: 1.82 /cvsroot/CMake/CMake/Source/cmMacroCommand.cxx,v -- cmMacroCommand.cxx new revision: 1.35; previous revision: 1.34 /cvsroot/CMake/CMake/Source/cmMakefile.cxx,v -- cmMakefile.cxx new revision: 1.438; previous revision: 1.437 /cvsroot/CMake/CMake/Source/cmWhileCommand.cxx,v -- cmWhileCommand.cxx new revision: 1.11; previous revision: 1.10 Enjoy! Sweet! Thanks Bill. -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Removing cmake as a dependancy
On Thu, Feb 28, 2008 at 11:54 PM, Kevin Tucker [EMAIL PROTECTED] wrote: I have some example programs that are shipped with our sdk and would like to maintain support for VC6 and various VS200x project files. Cmake obviously does a great job of generating these project files. However, as an additional simplification for the end user, I would like to avoid them having to install cmake to be able to compile. Looks like I can just remove the ZERO_CHECK, INSTALL, PACKAGE projects from the solution and things are pretty well set. Is there an option in cmake for it to leave itself out of the projects/makefiles that it generates? You could use CMAKE_SUPPRESS_REGENERATION to suppress running CMake but that's not going to get you the ability to avoid having the user install CMake to be able to compile your CMake generated projects. For technical reasons (which I'm sure are discussed at length in previous posts) CMake uses absolute paths in generated Makefiles / VCproj files (have a look at a generated one). Unless your target audience is going to have an identically configured machine (down to the location of the source and binary directories and dependent libraries) OR you're planning on trying to modify CMake generated VCproj files before the user attempts compilation, they are most likely going to need CMake. -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake + OpenCV + Visial Studio 2005 (V8)
In the CMakeLists: FIND_PACKAGE(OPENCV REQUIRED) CMake runs smoothly, but when VS tries to compile, it can't find by itself where, for instance, cv.h is By manually adding to VS VC++ include directories where the OpenCV includes are (which CMake knows, for instance, in the OPENCV_ INCLUDE_DIR_CV variable, that is well filled automaticly by CMake), things work. I was wondering if this manual step could be avoided, am i missing something? thank you, -- Dario Figueira ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CHECK_FUNCTION_EXISTS for pthread_spin_init
**On Thu, Feb 28, 2008 at 9:21 AM, Brantner Matthias [EMAIL PROTECTED] wrote: Hi, I wanted to write a check whether pthread_mutex_init and pthread_spin_init exist in pthread.h. Therefore, I used the following CMake commands: INCLUDE(CheckFunctionExists) CHECK_FUNCTION_EXISTS(pthread_spin_init HAVE_PTHREAD_SPINLOCK) CHECK_FUNCTION_EXISTS(pthread_mutex_initHAVE_PTHREAD_MUTEX) The result of running CMake on a Linux system gives me -- Looking for pthread_spin_init -- Looking for pthread_spin_init - not found -- Looking for pthread_mutex_init -- Looking for pthread_mutex_init - found. Although pthread_spin_init is declared in my pthread.h and my code compiles and uses it, CMake does not find it. However, I saw that this function is guarded in an #ifdef __USE_XOPEN2K. Could that be the reason why CMake doesn't find it or am I doing something wrong here? *CheckFunctionExists*: macro which checks if the function exists CHECK_FUNCTION_EXISTS(FUNCTION VARIABLE) FUNCTION - the name of the function VARIABLE - variable to store the result The following variables may be set before calling this macro to modify the way the check is run: CMAKE_REQUIRED_FLAGS = string of compile command line flags CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar) CMAKE_REQUIRED_INCLUDES = list of include directories CMAKE_REQUIRED_LIBRARIES = list of libraries to link The following works for me: INCLUDE(CheckFunctionExists) SET(CMAKE_REQUIRED_LIBRARIES pthread) CHECK_FUNCTION_EXISTS(pthread_create HAVE_PTHREAD) -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VS2005 PocketPC and Smartphone targets
On Thu, Feb 28, 2008 at 11:58 PM, Kevin Tucker [EMAIL PROTECTED] wrote: Do you have a recommendation for how to generate project files with VS2005 for PocketPC and/or Smartphone targets? Could you post an example project file on the mailing list? -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Removing cmake as a dependancy
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? Kevin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Lowman Sent: Friday, February 29, 2008 12:07 PM To: Kevin Tucker Cc: cmake@cmake.org Subject: Re: [CMake] Removing cmake as a dependancy On Thu, Feb 28, 2008 at 11:54 PM, Kevin Tucker [EMAIL PROTECTED] wrote: I have some example programs that are shipped with our sdk and would like to maintain support for VC6 and various VS200x project files. Cmake obviously does a great job of generating these project files. However, as an additional simplification for the end user, I would like to avoid them having to install cmake to be able to compile. Looks like I can just remove the ZERO_CHECK, INSTALL, PACKAGE projects from the solution and things are pretty well set. Is there an option in cmake for it to leave itself out of the projects/makefiles that it generates? You could use CMAKE_SUPPRESS_REGENERATION to suppress running CMake but that's not going to get you the ability to avoid having the user install CMake to be able to compile your CMake generated projects. For technical reasons (which I'm sure are discussed at length in previous posts) CMake uses absolute paths in generated Makefiles / VCproj files (have a look at a generated one). Unless your target audience is going to have an identically configured machine (down to the location of the source and binary directories and dependent libraries) OR you're planning on trying to modify CMake generated VCproj files before the user attempts compilation, they are most likely going to need CMake. -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] absolute rpath
Jörg Becker wrote: On Friday, 29. February 2008 00:18:18 Alexander Neundorf wrote: So you need your program to be executable anywhere in the file system, and it also has to find its shared libs ? Would setting PATH be a alternative ? Yes, setting PATH or LD_LIBRARY_PATH in a shell wrapper is an alternative. You could create automatically shell scripts which do that for you. Does automatically mean by CPack? The docu about CPack is quite short (Is No. Automatically means that you can write a macro which wraps add_executable() and which also creates such a wrapper script. I'll try it this way. Thanks a lot for your help! Hi, I've written a bash script for wengophone which sets LD_LIBRARY_PATH. http://hg.qutecom.org/qutecom-2.2/file/b9d00ba33b90/scripts/wengophone.sh You can create symlinks to this script or execute it from everywhere. The script will figure out in which path it is located :) Jörg -- andreas ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- http://www.cynapses.org/ - cybernetic synapses signature.asc Description: OpenPGP digital signature ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] VS2005 PocketPC and Smartphone targets
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 From: Kevin Tucker Sent: Friday, February 29, 2008 12:32 PM To: 'Philip Lowman' Cc: cmake@cmake.org Subject: RE: [CMake] VS2005 PocketPC and Smartphone targets Hi Philip, Here is a default configured smartphone 2003 VS2005 project and for comparison, a project for Win32 and Win32console. I created all of them through the VS2005 new project wizard. Thanks! Kevin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philip Lowman Sent: Friday, February 29, 2008 12:29 PM To: Kevin Tucker Cc: cmake@cmake.org Subject: Re: [CMake] VS2005 PocketPC and Smartphone targets On Thu, Feb 28, 2008 at 11:58 PM, Kevin Tucker [EMAIL PROTECTED] wrote: Do you have a recommendation for how to generate project files with VS2005 for PocketPC and/or Smartphone targets? Could you post an example project file on the mailing list? -- Philip Lowman smartdev.vcproj Description: smartdev.vcproj ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake + OpenCV + Visial Studio 2005 (V8)
Dear Philip,
Didn't work :S, other considerations aside,
adding INCLUDE_DIRECTORIES(${OPENCV_INCLUDE_DIR_CV})
and confirming in the CMake GUI that OPENCV_INCLUDE_DIR_CV does point to the
correct location, Visual Studio still complains that it cannot find the
sought for 'cv.h'
fatal error C1083: Cannot open include file: 'cv.h': No such file or
directory
Thank you for your time tho =), any other ideas?
On 2/29/08, Philip Lowman [EMAIL PROTECTED] wrote:
On Fri, Feb 29, 2008 at 2:59 PM, Dario Figueira [EMAIL PROTECTED]
wrote:
In the CMakeLists: FIND_PACKAGE(OPENCV REQUIRED)
CMake runs smoothly, but when VS tries to compile, it can't find by
itself where, for instance, cv.h is
By manually adding to VS VC++ include directories where the OpenCV
includes are (which CMake knows, for instance, in the OPENCV_
INCLUDE_DIR_CV variable, that is well filled automaticly by CMake),
things work.
I was wondering if this manual step could be avoided, am i missing
something?
Dario,
When FIND_PACKAGE(OPENCV REQUIRED) is called that should invoke the
FindOPENCV.cmake file which I'm assuming is somewhere in your source
tree. This file will attempt to find the OPENCV include path (i.e. where
it's header files are) and perhaps other things (not sure what OPENCV is, so
I can't speculate).
If after configuring with CMakeSetup you see an OPENCV_INCLUDE_DIR_CV
variable in the cache that likely needs to be pointed to where the cv.hfile
is. Assuming that that variable is being pointed to the proper
location of where OPENCV is, you'll need to make sure that somewhere in the
CMakeLists.txt file after the FIND_PACKAGE(OPENCV REQUIRED) line that you
call:
INCLUDE_DIRECTORIES(${OPENCV_INCLUDE_DIR_CV})
(This assumes that you're OK with adding OPENCV to your include path for
all of your targets)
--
Philip Lowman
--
Dario Figueira - IST nº 54545 - Delegado 5º Ano de MEEC
no google ^^ [EMAIL PROTECTED]
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
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? No problem at all. Really because of the amount of system introspection that is done, CMake has to be around on the actual target build machine for things to work correctly. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VS2005 PocketPC and Smartphone targets
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) / -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Adding non-build-related sources to IDE projects
Is there an appropriate way to cause an IDE like Visual Studio or Xcode to present entries for source files such as .h files and .xml files, which do not get compiled? I'm currently listing those files as sources for library and executable targets. This doesn't work very well: I have to make sure I'm not generating a Makefile, because then the files are listed in the Makefile rule and cause compilation to fail. Under Xcode, doing this causes lots of build warnings as xcodebuild complains that it has no rules for .txt or .xml files. Is there a better way? b ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Adding non-build-related sources to IDE projects
Bryan O'Sullivan wrote: Is there an appropriate way to cause an IDE like Visual Studio or Xcode to present entries for source files such as .h files and .xml files, which do not get compiled? I'm currently listing those files as sources for library and executable targets. This doesn't work very well: I have to make sure I'm not generating a Makefile, because then the files are listed in the Makefile rule and cause compilation to fail. Under Xcode, doing this causes lots of build warnings as xcodebuild complains that it has no rules for .txt or .xml files. Is there a better way? That is the right way. .h files should not be a problem. For other files you might have to call set_source_files_properties with the HEADER_FILE_ONLY set to true. I just realized the documentation for this is bogus... What it does is keep it from being compiled by makefiles and various IDE's. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Include dir for inotify.h
Hi, I'm working on ap project that users inotify.h, a module that is
included in recent versions of glibc, but for example not in Debian
Etch.
The thing is, in any modern distro I'd have to include sys/inotify.h,
while in etch I have to include inotifytools/inotify.h. I've managed
to do it in CMake with CHECK_INCLUDE_FILES and a config.h, but I found
a cleaner solution that should work in theory but actually doesn't,
for me:
src/CMakeList.txt
SET(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake_modules/)
FIND_PACKAGE(Inotify REQUIRED)
IF(INOTIFY_FOUND)
INCLUDE_DIRECTORIES( ${INOTIFY_INCLUDE_DIR} )
ENDIF(INOTIFY_FOUND)
cmake_modules/FindInotify.cmake
IF (INOTIFY_FOUND)
IF (NOT Inotify_FIND_QUIETLY)
MESSAGE(STATUS Found Inotify: ${INOTIFY_INCLUDE_DIR})
ENDIF (NOT Inotify_FIND_QUIETLY)
ELSE (INOTIFY_FOUND)
IF (Inotify_FIND_REQUIRED)
MESSAGE(FATAL_ERROR Could not find Inotify)
ENDIF (Inotify_FIND_REQUIRED)
ENDIF (INOTIFY_FOUND)
INCLUDE_DIRECTORIES( ${INOTIFY_INCLUDE_DIR}
${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR} )
So, when I get the correct inotify path I get it into my include dirs,
but if CMake can't find it gives an error. This should work, but how
do I include inotify.h in my source? #include inotify.h or
inotify.h doesn't seem to work.
Also, I've tried compiling this with plain g++, and I get a very weird error:
[EMAIL PROTECTED] klikd]$ g++ -I/usr/include/sys src/*.cpp -lpthread -lrt
In file included from /usr/include/sys/signal.h:1,
from /usr/include/sys/signal.h:1,
from /usr/include/sys/signal.h:1,
from /usr/include/sys/signal.h:1,
from /usr/include/sys/signal.h:1,
from /usr/include/sys/signal.h:1,
(...)
/usr/include/sys/signal.h:1:20: error: #include nested too deeply
In file included from /usr/include/sys/unistd.h:1,
from /usr/include/sys/unistd.h:1,
from /usr/include/sys/unistd.h:1,
from /usr/include/sys/unistd.h:1,
from /usr/include/sys/unistd.h:1,
(...)
Being:
[EMAIL PROTECTED] klikd]$ cat /usr/include/sys/signal.h
#include signal.h
[EMAIL PROTECTED] klikd]$ cat /usr/include/sys/unistd.h
#include unistd.h
Is this normal? Anyone know how to make it work?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
