On Thu, Sep 17, 2009 at 07:55:29AM +0200, Xavier Larrodé wrote:
On linux i always use the command CMAKE_BUILD_TYPE to set the binary dir.
But on windows, even if a project is set with cmake as Build Debug, it
generates the Release cmake project too.
In Visual Studio and other IDEs, the user
Ok thank you
2009/9/17 Tyler Roscoe ty...@cryptio.net
On Thu, Sep 17, 2009 at 07:55:29AM +0200, Xavier Larrodé wrote:
On linux i always use the command CMAKE_BUILD_TYPE to set the binary dir.
But on windows, even if a project is set with cmake as Build Debug, it
generates the Release
Tyler,
Thank you for the tips on VERBATIM make VERBOSE=1. I added VERBOSE to
my add_custom_command, but it seems that it fixed one problem and caused
another.
On the plus side, the passed arg #../../XML/Types/## is now properly
quoted. On the minus side, the xsd command invocation fails
Boudewijn Rempt wrote:
Hm, I downgraded from the CVS version to 2.6.4 and the problem doesn't
seem to occur, so I suspect a bug in CMake, after all.
How can I reproduce this?
Can you give a verbose output of the link line with 2.6.4 and with CVS
CMake, I would like to figure out the
Hi,
I may haven't used the right keywords on google, as I believe this is asked
many times befor:
I have a multiplatform project that uses external tools (yacc/bison/lex/flex).
I don`t have any problems under linux/solaris etc. but I really had a bad time
trying to make this work under
2009/9/17 th@gmx.de:
Hi,
I may haven't used the right keywords on google, as I believe this is asked
many times befor:
I have a multiplatform project that uses external tools (yacc/bison/lex/flex).
I don`t have any problems under linux/solaris etc. but I really had a bad
time
On Thu, Sep 17, 2009 at 08:24:28AM -0400, Eric Tellefsen wrote:
On the plus side, the passed arg #../../XML/Types/## is now properly
quoted. On the minus side, the xsd command invocation fails outright,
because for some reason the directory name being passed in for the
location of the .xsd
I'm trying to package all the 3rd party libraries needed by my project
so that my project is self-contained (very handy for testing). On Unix,
these 3rd party libraries often have version symlinks that go with them:
[tyle...@alta:/3rdpartylibs/Qt/4.5.1/build/linux/release/lib]$ ls -l libQtCore.*
Hi,
I have encountered problems with Boost 1.40 (build on Windows using
Visual Studio 2008 and MinGW GCC 4.4.0) with CMake 2.6.4.
Boost was compiled for Visual Studio 2008 like this:
bjam --build-dir=c:\temp\boost toolset=msvc --build-type=complete install
and for MinGW GCC like this:
bjam
As noted in the other question I just posted, I'm collecting all my 3rd
party dependencies into one place so my application is self-contained.
I'm using FindQt4 to manage the Qt stuff. FindQt4 has some clever logic
where each buildable unit that uses Qt can define the Qt submodules it
needs:
set
On Thursday 17 September 2009 02:56:02 pm Tyler Roscoe wrote:
As noted in the other question I just posted, I'm collecting all my 3rd
party dependencies into one place so my application is self-contained.
I'm using FindQt4 to manage the Qt stuff. FindQt4 has some clever logic
where each
When you build boost use the --prefix=C:\boost_1_40 ... install
also you should specify toolset==msvc9.0 or the libraries will not be
named correctly.
Mike Jackson
On Sep 17, 2009, at 4:48 PM, Cristian Adam wrote:
Hi,
I have encountered problems with Boost 1.40 (build on Windows using
From FindBoost.cmake:
# These last three variables are available also as environment
variables:
#
# BOOST_ROOT or BOOSTROOT The preferred installation prefix for
searching for
#Boost. Set this if the module has
problems finding
#
On Thu, Sep 17, 2009 at 03:08:44PM -0600, Clinton Stimpson wrote:
I mentioned BundleUtilities.cmake in another email.
It takes care of all this. I suggest you try it out.
Yup, I've been digging through the archives and reading about
BundleUtilities and GetPrerequisites (I guess my eyes glazed
Michael Jackson wrote:
When you build boost use the --prefix=C:\boost_1_40 ... install
also you should specify toolset==msvc9.0 or the libraries will not be
named correctly.
Hmm, I managed to compile a small program_options test program.
Program options libraries are named like:
James C. Sutherland wrote:
From FindBoost.cmake:
# These last three variables are available also as environment variables:
#
# BOOST_ROOT or BOOSTROOT The preferred installation prefix for
searching for
#Boost. Set this if the module has
problems
On Thu, Sep 17, 2009 at 6:10 PM, Cristian Adam cristian.a...@gmx.net wrote:
James C. Sutherland wrote:
From FindBoost.cmake:
# These last three variables are available also as environment variables:
#
# BOOST_ROOT or BOOSTROOT The preferred installation prefix for
searching for
#
John Drescher wrote:
You set BOOST_ROOT in your windows environment variables.
Thanks for the tip. Setting BOOST_INCLUDEDIR environment variable
to c:/boost/include/boost-1_40 resolved all the problems, no need
to set additional versions, it just worked.
I was a bit surprised to see that
How is this work coming along? I'm using a build of CVS HEAD, which I
believe is v2.7.2. Does this currently build the appropriate version of
xcode projects?
Also, where are the CMAKE_OSX_ variables documented on the Wiki? I can't
seem to find them.
-
Robert Dailey
On Fri, Jul 10, 2009
Hello,
I'm using the latest (as of now) CMake build from CVS head. I noticed that
when I specify a source file like so:
/Users/imac/work/redsword/projects/foobar/mysource.mm
XCode actually thinks it is here:
/Users/imac/work/redsword/projects/foobar/projects/foobar/mysource.mm
And when I right
20 matches
Mail list logo
