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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
[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
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.
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
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
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
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)
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
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
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
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
**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)
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
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
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
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:
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:
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
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
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
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
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
39 matches
Mail list logo
