Hi all,
I've been bitten by this more than once. When specifying a module path
on the command line, you must not forget to make this an absolute path,
otherwise calling a macro from a (CMakeLists.txt file in a) subdirectory
will fail.
Would it be an idea to let CMake always convert a relative
I am trying to do a cross-compilation with CMake. I got a problem
in creating a 64-bit shared library on a Win32 platform.
The problem is the CMAKE is always appending the
/machine:I386 following my arch setup /machine:x64.
My CMake file looks like,
On Tue, Aug 25, 2009 at 12:08:10AM -0700, Xiangyun Kong wrote:
I am trying to do a cross-compilation with CMake. I got a problem
in creating a 64-bit shared library on a Win32 platform.
The problem is the CMAKE is always appending the
/machine:I386 following my arch setup /machine:x64.
Use
Hi John,
I took a different approach to the problem you're describing.
Following the instructions on the Wiki
(http://www.cmake.org/Wiki/CMake/Assembler), I've written the three
required *ASM*.cmake files.
In the CMakeASM-fooInformation.cmake file I've redefined the rule to
build .S files.
On 25.08.09 12:37:46, David Ojeda wrote:
I have a shared library that I managed to compile and install using cmake.
This is working great but now I want to use this library in another
cmake-based development. Normally, as with any other shared library, I use a
FindPackage to get the include
Just to be clear, did you build them with the 64bit command prompt
from Visual Studio? Otherwise how did you build them?
I ended up tweaking the cmake files that come with boost 1.39 in
order to remove the -s that is tagged onto the unittest libraries.
Otherwise not really sure what to do as
On 25. Aug, 2009, at 15:06, Pol Monsó IRI wrote:
Hello cmake users!
I'm quite new to cmake as well as makefiles, and i've bumped the same
trouble twice. I'm trying to break a source code into several
libraries and
a main program. The scenario has one main executable called
calClient which
On Tue, Aug 25, 2009 at 12:47 PM, Andreas Pakulat ap...@gmx.de wrote:
On 25.08.09 12:37:46, David Ojeda wrote:
I have a shared library that I managed to compile and install using
cmake.
This is working great but now I want to use this library in another
cmake-based development. Normally,
On 25. Aug, 2009, at 15:23, David Ojeda wrote:
On Tue, Aug 25, 2009 at 12:47 PM, Andreas Pakulat ap...@gmx.de
wrote:
On 25.08.09 12:37:46, David Ojeda wrote:
I have a shared library that I managed to compile and install using
cmake.
This is working great but now I want to use this
On 25. Aug, 2009, at 15:23, David Ojeda wrote:
On Tue, Aug 25, 2009 at 12:47 PM, Andreas Pakulat ap...@gmx.de
wrote:
On 25.08.09 12:37:46, David Ojeda wrote:
I have a shared library that I managed to compile and install using
cmake.
This is working great but now I want to use this
On 25. Aug, 2009, at 15:51, Pol Monsó IRI wrote:
DON'T EVER do something like this unless you really know what
you're doing.
The proper way of doing this is to use the Debug configuration at
configure-time:
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=-Wall /path/to/
source
On Tue, Aug 25, 2009 at 9:06 AM, Pol Monsó IRIpmo...@iri.upc.edu wrote:
Hello cmake users!
I'm quite new to cmake as well as makefiles, and i've bumped the same
trouble twice. I'm trying to break a source code into several libraries and
a main program. The scenario has one main executable
DON'T EVER do something like this unless you really know what you're doing.
The proper way of doing this is to use the Debug configuration at
configure-time:
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=-Wall /path/to/source
Thanks for the tip! I had just put the warnings on to find
My message bounced due to size limitations (!?). I'm resending it without
the appended previous replies.
In case you'd like to see the compilation too, here's the complete output.
The 1A's and 1B's real name is wammoves and inout and the 2C's is wammates.
yarp is an external 3d party libraries
On 25. Aug, 2009, at 16:06, Pol Monsó IRI wrote:
In case you'd like to see the compilation too, here's the complete
output.
The 1A's and 1B's real name is wammoves and inout and the 2C's is
wammates.
yarp is an external 3d party libraries framework for robot software,
it's
all under the
Did you try the
nm lib/libcallibs.a | grep print_double_array
command?
Thanks Michael!
With that command I spotted the mistake, it was already undefined before the
linking process. The function was in the header, but not on the c file (!!).
I recopied it nice clean now.
Thank you very
Thanks. After I use the new generator, it always looks for the 32 bit
cl.exe at vc_root/VC/bin,
and complain that the cl.exe does not work, even though I set the
PATH as vc_root/VC/bin/x86_amd64.
I used to use NMake Makefile, which does not complain about that.
Xiangyun
--- On Tue, 8/25/09,
On Tue, Aug 25, 2009 at 12:56 PM, Xiangyun Kongxyk...@yahoo.com wrote:
Thanks. After I use the new generator, it always looks for the 32 bit
cl.exe at vc_root/VC/bin,
and complain that the cl.exe does not work, even though I set the
PATH as vc_root/VC/bin/x86_amd64.
I used to use NMake
It can generate 64-bit code if the cross-compiler under bin/x86_amd64
is used.
Xiangyun
--- On Tue, 8/25/09, John Drescher dresche...@gmail.com wrote:
From: John Drescher dresche...@gmail.com
Subject: Re: [CMake] Cross-compilation related question
To: Xiangyun Kong xyk...@yahoo.com
Cc:
I am using the Visual Studio generator from the cmake binary distribution.
If I change flags using ADD_DEFINITIONS, I notice that it doesn't trigger a
rebuild of all the affected files.
Is this by design?
Juan
___
Powered by www.kitware.com
Visit
If you are using NMake Makefiles as the CMake generator, just be sure to
launch cmake (or cmake-gui) from the Visual Studio x64 Cross Tools Command
Prompt That should build x64 code for you without any special
adjustments out of the box.
HTH,
David
On Tue, Aug 25, 2009 at 12:56 PM, Xiangyun
Michael and Marcel have already posted helpful follow-ups to the
original question about compiling assembler files.
On Mon, Aug 24, 2009 at 01:38:13PM -0400, John Smith wrote:
Most surely I am over-thinking it. After more local testing I think I
understand how variables are processed in the
Thanks for the information. Unfortunately, I cannot find the
command prompt.
Xiangyun
--- On Tue, 8/25/09, David Cole david.c...@kitware.com wrote:
From: David Cole david.c...@kitware.com
Subject: Re: [CMake] Cross-compilation related question
To: Xiangyun Kong xyk...@yahoo.com
Cc: Tyler
On my Linux platform for CMake-2.6.4, dependencies work for imported library
targets but not imported module targets. To be specific if I touch
/home/software/plplot_cvs/installcmake/lib/libplplotd.so.9.6.2 (the location
of the imported library corresponding to the plplotd target) parts of the
On 2009-08-25 19:19-0700 Alan W. Irwin wrote:
Oops. I had a screwup in the file dependencies for the project that was
importing PLplot libraries and modules. Once that was solved touch
ps.so made the component of the project that file depended on the ps target
build fine. Sorry for the
25 matches
Mail list logo
