Hi,
I've an external project which made the decision to create an executable which
exports symbols. This means if you want to write a plugin for this project you
have to link your plugin against this executable.
Now I've the problem that FIND_LIBRARY doesn't find this executable. Does
anybody k
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
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 a
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
On Thu, Sep 17, 2009 at 6:10 PM, Cristian Adam 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
>> #
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 findin
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:
boost_prog
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
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
#
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
Vis
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 b
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
BundleUtilities in CMake CVS works on Unix and Windows too.
That's how I package Qt with my apps.
You could copy the script and use it with your CMake 2.6 if you want.
In the past, I've used a glob to get the .so.* files and tar to copy them.
Clint
On Thursday 17 September 2009 02:45:53 pm Tyle
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 --bui
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.*
-
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
2009/9/17 :
> 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
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 windows
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 differe
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
20 matches
Mail list logo
