Hello,
I just posted a series of screencasts on how to use CMake (for
end-users). This is not a coding tutorial, but a usage tutorial for
newbies and outsiders.
My usual problem in getting people to seriously give CMake a chance is
that they don't really understand what it can do or how to get
On 6/18/09, Michael Jackson mike.jack...@bluequartz.net wrote:
What is the difference and what does a project that is Xcode 3.0+
compatible gain you? In other words, what are we missing by NOT having
a true Xcode 3.0+ compatible project?
Since CMake does a very good job with dependency
I have a minor problem, though maybe this is a CMake bug.
I wanted to see my CMakeLists.txt in Xcode so I could try to edit them
in the IDE. So I've been manually adding CMakeLists.txt to my targets
(ADD_LIBRARY, etc). I tend to miss things like top level
CMakeLists.txt when lists are common to
As you can see, when a rebuild is done, the template gets copied to
main.cpp which in turn is compiled and linked. This works great in
Xcode. But, whenever I change the template, i.e. my CUDA sources, I
have to run the build twice to make the changes appear in the test
program. It looks like
On Fri, Mar 6, 2009 at 2:40 AM, Marcel Loose lo...@astron.nl wrote:
Hi Dmitriy,
I don't really need this feature, but it would have made some tasks
easier to program in CMake. So, I thought, if it's possible, then how
should I do it. But, as it turns out it's not possible, I'll have to
find
I want to link something against the date_time library in boost. The
comments in the FindBoost.cmake module imply that I
should be able to use something like ${Boost_date_time_LIBRARY}. But the
variable is always empty for me.
Here is my code:
SET(Boost_USE_STATIC_LIBS ON)
On Mon, Mar 2, 2009 at 7:55 AM, Gerhard Grimm ggr...@detec.de wrote:
Hi Eric,
genrb does not create libraries to link against, but binary resource files
that will be loaded by an application using ICU at runtime.
Here's an example how we are using genrb in our project:
Thanks for the replies. Capitalization was indeed the problem.
FIND_PACKAGE(Boost 1.3.6 COMPONENTS date_time filesystem regex system)
The 1.3.6 is a typo, btw. You probably want 1.36 or whatever minimum
version you need to use boost
Thanks for pointing that out. I probably would have
Do you feel that I'm better off using Boost_LIBRARIES?
If you're comfortable with maintaining the dependencies where they are
needed I would recommend doing it the way you were planning on and use
Boost_COMPONENT_LIBRARY, it also handles the debug/optimized links for
Visual Studio. I only
Anybody out there know anything about ICU and genrb? I need to convert a
build system that uses genrb.
As I understand it, genrb is a tool that creates a static library from some
input and you are supposed to link against it.
So I have 2 different questions about this.
1) Using CMake, what is
This conservation has moved to the bug tracker:
http://www.cmake.org/Bug/view.php?id=8481
On Fri, Feb 6, 2009 at 7:26 PM, E. Wing ewmail...@gmail.com wrote:
I just got back to using CMake again for a project. I am using 2.6.2 and
Xcode 3.1.2 (everything current as of today). Using the Xcode
I just got back to using CMake again for a project. I am using 2.6.2 and
Xcode 3.1.2 (everything current as of today). Using the Xcode generator,
the generated project seems to be ignoring all my breakpoints in the Xcode
debugger. This problem severely limits the usefulness of CMake for me in
Given the fact that you know Bryan O'Sullivan, you should be
considering Mercurial.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Interesting. I was expecting the PATH_SUFFIXES to work on Windows. I
thought I had tested this general technique, though maybe not with the
Freetype module and maybe not 2.6.0. I think this may be a CMake bug,
but I'm not an authority on the matter.
You might want to try a more generalized
Can somebody tell me how to enhance this so that it removes empty directories?
I am testing the OS X framework building support, and the problem is that all
the empty directory husks are left behind.
Also, how bad is it to remove the check:
IF(EXISTS \\${file}\)\n)
I have code that creates
On 8/21/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hello,
we are currently developing with MPC (Makefile project creator) and I'm
trying to find out what advantages we would have with a switch to CMake.
First of all I would like to say, that CMake is very useful for me.
Still there are
Management Technology Services
On Aug 7, 2008, at 1:53 AM, E. Wing wrote:
On 8/6/08, Bill Hoffman [EMAIL PROTECTED] wrote:
Mike Jackson wrote:
I have the following:
SET_TARGET_PROPERTIES(${MXADATAMODEL_LIB_NAME} PROPERTIES
#DEBUG_OUTPUT_NAME ${MXA_LIBRARY_RELEASE
Why not LUA51_FOUND?
Is this valid?
I think not.
Attached patch changes variable name LUA50_FOUND to LUA51_FOUND.
Yes, that looks like a bug. That FIND_PACKAGE_HANDLE_STANDARD_ARGS
stuff is new to me. Somebody else added it and must have done the
normal copy/paste thing/bug. I checked in the
-And I don´t know how to use it in a sdl proyect, like in the
following example:
#include stdlib.h
#include SDL.h
int main(int argc, char *argv[])
{
if ( SDL_Init(SDL_INIT_AUDIO|SDL_INIT_VIDEO) 0 )
I think I recall reading Brad's notes on the bug report, and I think
they look good. I'm still trying to find time to dig through all my
correspondences on this issue. Below is something I posted to the
OpenSceneGraph mailing list. It talks about versioning at the dylib
level, but also talks about
Also, I posted this to the Xcode list. Follow the threads for the responses.
http://lists.apple.com/archives/xcode-users/2007/May/msg00417.html
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
In sum, pkg-config is already widely used on the Linux/Mac OS X side of
things and there doesn't seem to be any fundamental reason to discourage
the
use of pkg-config on windows even though most windows-only developers are
currently completely unaware of how useful pkg-config can be.
This seems familiar. I remember a long discussion on this somewhere.
It must have been offlist. I forgot the outcome. Were we going to
introduce a different versioning variable separate from SOVERSION?
-Eric
On 4/2/08, Sean McBride [EMAIL PROTECTED] wrote:
On 4/2/08 5:31 PM, Alan W. Irwin
I hate to be drawn into this, but I agree with Rodolfo that banning
may be overly harsh. One important thing Brandon was reasonably
restrained at was personal attacks. He generally argued on issues and
though not everybody agreed he was arguing on issues that always
mattered, he generally
The other is that a non-trivial portion of CMake is written in the scripting
language ala the Modules directory. So supporting multiple languages becomes
problematic. Most languages are not designed to mix with other languages. I
doubt you can mix python and Lua and expect them to be able to
I am not seeing the merit of trying to support multiple scripting
languages. This fragments CMake into many sub-language communities.
Who would handle all the inevitable bugs? It's many times the work of
maintaining a quality implementation with 1 scripting language.
I don't think this is
On 2/24/08, Brandon Van Every [EMAIL PROTECTED] wrote:
On Sun, Feb 24, 2008 at 8:03 AM, E. Wing [EMAIL PROTECTED] wrote:
Apple introduced
a second completely independent framework called Carbon, but they told
people they should use Cocoa to get first-class looking applications.
Kitware
On 2/24/08, Brandon Van Every [EMAIL PROTECTED] wrote:
On Sun, Feb 24, 2008 at 12:56 PM, E. Wing [EMAIL PROTECTED] wrote:
On 2/24/08, Brandon Van Every [EMAIL PROTECTED] wrote:
So are you going to write this framework for us, that makes all the
work of supporting multiple languages
In ccmake or CMakeSetup, add the flag to either CMAKE_C_FLAGS or
CMAKE_CXX_FLAGS.
-Eric
On 2/24/08, David Sveningsson [EMAIL PROTECTED] wrote:
Hi, I'm quite new with cmake and I can't figure out how to enable
warnings for the generated makefiles/projects. For instance, I would
like to use
On 12/12/07, Miguel A. Figueroa-Villanueva [EMAIL PROTECTED] wrote:
On Dec 10, 2007 9:40 AM, E. Wing wrote:
snip
That's all I can remember on Mac issues for the moment. But on a
general CMake issue, I just submitted a whole bunch of Find*.cmake
modules for inclusion.
http://www.cmake.org
On 12/22/07, Brandon Van Every [EMAIL PROTECTED] wrote:
On Dec 22, 2007 6:48 PM, Andreas Schneider [EMAIL PROTECTED] wrote:
Rodolfo Schulz de Lima wrote:
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
Also missing the thread, I did want to chime in on a few things before
it is left.
First, Mike's pretty much nailed it on all points, though I think the
use of installers needs to be qualified a little (below).
As for where it is said not to install to /usr/bin, I don't know where
in the docs,
I'm playing around with the MinGW generator. I was wondering if there
is a special environmental variable that CMake will check for finding
mingw32-make.exe. MinGW is not in my PATH so everytime I specify the
MinGW generator in CMakeSetup, it complains it can't find the make
program. I was hoping
CMake assumes the environment is setup to work. Just like with visual
studio, you have to run vcvars.bat. Basically, cmake expects a working
compiler, and can not modify the PATH. It can not modify the PATH
because it won't be around when make is actually run.
Actually, CMake did an
Ugh, sorry, accidentally botched the first replies because the
original reply was not to the list.
On 12/28/07, Rodolfo Lima [EMAIL PROTECTED] wrote:
On Fri, Dec 28, 2007 at 05:40:59PM -0800, E. Wing wrote:
I didn't know cross-compiling was a feature now.
Yes, works very well once you
- The source code seems to have been crappified by windows. There's
missing +x permissions on executable files and cr-lf linefeeds everywhere.
- The source does:
#include lua.h
but the bootstrap/cmakelists.xt does not search for paths to it. Under
my Ubuntu box, lua.h is located in
Hi, sorry for the delay, but I just sacrificed my weekend trying to
get caught up on CMake things.
So all the issues are fuzzy. But here's what I remember:
- The bootstrap used to fail if CMake had not been previously installed.
I just tested this on a system that did not have CMake installed and
(Aside: what's with the cm_ prefix?)
The cm_ prefix was something Ken put in his demo. I assumed he was
trying to 'namespace' the thing. I personally like the idea and really
think it should have been applied to the regular CMake language. Often
when I have to read other people's code, I can't
Is backward compatibility with the current language a goal of the LUA
experiment? I ask because the examples spoken of on this list appear to be
trying to mimic the current CMake syntax.
Right now I think it's just an experiment to see how things might
work, how much effort would be involved,
I'd also like a shorter way to dereference a table than
unpack(table).
Seriously, this is a total non-issue and unpack is totally unnecessary.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Hi Ken,
Wow, thank you for playing with this. I personally think it's great.
Every so often, I have to write some evil stuff in CMake script, and
it always leaves me frustrated with things sometimes not working
correctly. Working with a well known and well defined language is a
big plus for me,
I think you are misinterpreting some things about the Lua syntax.
The heart and soul of Lua is the 'table'. It is *the* data structure
in Lua. A table is an hash or associative array. But in Lua, a table
can also be an array. There are some very interesting optimizations
under the hood that make
For interest, this topic has been brought up before.
http://public.kitware.com/pipermail/cmake-promote/2005-December/39.html
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
I'm wondering the same about this topic. I think Sean might be right
about checking for the SDK target version instead of OS X version,
though I could come up with a contrived example where knowing the
actual OS X version could be important, such as a CMake bug/issue you
need to work around that
So, life is slightly trickier since you are using a PrivateFramework.
We never requested the CMake folks handle this explicitly, though
there may already be enough built-in flexibility to handle this.
For the library:
FIND_LIBRARY(CHUD_LIBRARY
NAMES CHUD
PATHS
From: Pau Garcia i Quiles [EMAIL PROTECTED]
For OpenThreads, I'm fairly close to the OpenThreads project and I've
been working on a formal find script for CMake. (I thought one of my
older scripts was already in the distribution too.) Our users have
found a lot of interesting problems, so
Hi, a few comments on your Find modules you just submitted.
For OpenThreads, I'm fairly close to the OpenThreads project and I've
been working on a formal find script for CMake. (I thought one of my
older scripts was already in the distribution too.) Our users have
found a lot of interesting
Several questions/problems on FIND_* search behavior:
1) Somebody complained to me that FIND_FILE was not finding things in
the paths that the documentation say they should be in. I confirmed on
OS X. I don't know about other platforms.
So if I do:
FIND_FILE(FOO libm.dylib)
I'm expecting it to
Okay, here's a silly question. Why doesn't this work as I think it should?
SET(IS_TRUE TRUE)
IF(${IS_TRUE})
MESSAGE(IS_TRUE Is true)
ELSE(${IS_TRUE})
MESSAGE(IS_TRUE Is false)
ENDIF(${IS_TRUE})
I get IS_TRUE Is false when I run this.
The same thing for SET(IS_TRUE YES) and
:
Thanks Eric and Mike-
May I mirror your posts on the cmake wiki to help speed things up
for new os x users, or would one of you like to do the honors?
I would add a bullet on
http://www.cmake.org/Wiki/CMake
in section 2.1 (cmake tutorials)
Drew
On Apr 5, 2007, at 5:22 PM, E. Wing wrote
CMake's framework detection mechanism is now complete. Mike already
pointed out how to use FIND_LIBRARY which is all correct. There is a
nuance with include paths which I'll describe here.
You need to decide about your #include usage pattern. Generally, OS X
system frameworks are included as:
The issue I see at the moment is that setting SDL_LIBRARY_TEMP is
not required by CMakeSetup. So you can finish the configure step
without setting SDL_LIBRARY_TEMP. But if you do so it will not compile
under Windows. So this should not happen.
So the options to me are:
- initialize
And if I check all variables using the show advanced values,
SDL_LIBRARY is nowhere. The only other variable is SDL_LIBRARY_TEMP
showing the value SDL_LIBRARY_TEMP-NOT-FOUND.
Any clue?
Yeah, this is an artifact of how the script works. The quick answer is
to set the SDL_LIBRARY_TEMP
And if I check all variables using the show advanced values,
SDL_LIBRARY is nowhere. The only other variable is SDL_LIBRARY_TEMP
showing the value SDL_LIBRARY_TEMP-NOT-FOUND.
Any clue?
Yeah, this is an artifact of how the script works. The quick answer is
to set the SDL_LIBRARY_TEMP with your
Very weird. I've never had this problem myself when running on
FreeBSD. I agree with Philip and make sure something isn't defining it
somewhere in the code. Also make sure the person didn't generate the
CMake stuff in Apple first, and then reboot or used a shared disk in
FreeBSD and tried reusing
Hi Werner,
I was curious if you saw any other glaring problems with the
FindSDL.cmake module, particularly with the Msys and MinGW stuff? I
put most of that together by trial and error without really any
understanding of it (like what do mingw32 and mwindows libraries
provide). And obviously I
So I would like to set the Universal Binary options as the default for
my project when on Apple. The issue is the options need to be
different for different versions of OS X.
In 10.4, I want to build ppc;i386. The SDK path must be set to 10.4u.
In 10.5, I want to build ppc;i386;ppc64;x86_64. I'm
From: PA Galmes [EMAIL PROTECTED]
Looking at your bug report, SDL_LIBRARY shouldn't be empty. This is
your problem. For Windows, you need at least SDLmain and SDL. I'm not
sure why these variables are empty. It could be a bug in the script.
Did you manually set the SDL_LIBRARY in your
Anyway, I would really like to improve this current Makefile scheme if
possible so it is more a one step build without the user having to
intervene with setting environment paths or 'installing'.
Is that even technically possible in the underlying build dependencies?
Yes, I believe this is
But that's OSG. Says nothing about OpenThreads and Producer. I'm
saying, write a CMake script that installs OpenThreads and Producer in a
way they're expected to be installed. There's really no value in
CMakeifying a build that the library maintainers themselves aren't going
to support. All
60 matches
Mail list logo
