2013/3/15 Casey Basichis
> Hi,
>
> I tried the tool chain. This console output shows the error. I've tried
> adding the SDK path up to the include and with the iPhoneOS6.1... part
> stripped off as well.
>
> CASEYs-MacBook-Pro:build caseybasichis$ export
> CMAKE_IOS_SDK_ROOT=/Applications/Xcode.
Only for the RC1 candidate would the toolset name be wrong. We can make
sure that the proper toolset name goes into the final 2.8.11 release.
On Thu, Mar 14, 2013 at 4:57 PM, Alexander Neundorf wrote:
> On Thursday 14 March 2013, Robert Maynard wrote:
> > I am sorry I was incorrect. The changes
On Thu, Mar 14, 2013 at 8:57 PM, Alexander Neundorf wrote:
> On Thursday 14 March 2013, Robert Maynard wrote:
> > I am sorry I was incorrect. The changes made to close bug 12405 are going
> > to be in RC1. These new changes aren't going to make RC1 but should be in
> > RC2 if we need one.
>
> I m
Hi,
I tried the tool chain. This console output shows the error. I've tried
adding the SDK path up to the include and with the iPhoneOS6.1... part
stripped off as well.
CASEYs-MacBook-Pro:build caseybasichis$ export
CMAKE_IOS_SDK_ROOT=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS
On Thursday 14 March 2013, Robert Maynard wrote:
> I am sorry I was incorrect. The changes made to close bug 12405 are going
> to be in RC1. These new changes aren't going to make RC1 but should be in
> RC2 if we need one.
I merged TI_DSP_to_TI_2 into next.
It would be great if this could still ma
On 14 March 2013 18:44, Casey Basichis wrote:
>
> On the SOCI mailing list they directed me to this, that suggests the
> Threading may have been a problem on iOS.
>
> http://stackoverflow.com/a/14198386/151641
Casey,
Thanks for posting this issue here.
Just FYI, I'm watching this list too, so if
On 2013-03-14 15:33, Stephen Kelly wrote:
Matthew Woehlke wrote:
Now that 2.8.11 supports interface include_directories on targets, is
there a way to create a library target that can be exported that has no
actual library, but *does* define interface include_directories?
That won't be possible
I am sorry I was incorrect. The changes made to close bug 12405 are going
to be in RC1. These new changes aren't going to make RC1 but should be in
RC2 if we need one.
On Thu, Mar 14, 2013 at 3:39 PM, Alexander Neundorf wrote:
> On Thursday 14 March 2013, Robert Maynard wrote:
> > These changes
Hi,
Forgive me if this issue has been discussed or is documented elsewhere,
but after some thorough perusal of the archives I didn't find anything.
When using the Xcode generator, is there a way to get find_library() and related
commands to search within the SDK directory specified by CMAKE_OSX_S
Alexander Neundorf wrote:
> On Thursday 14 March 2013, Robert Maynard wrote:
>> These changes will be in 2.8.11 RC1 for you to test out.
>
> Cool :-)
> Before I merge it into next, could you have a look at the TI_DSP_to_TI
> branch, I had some git trouble and I'm not quite sure everything is in
>
On Thursday 14 March 2013, Robert Maynard wrote:
> These changes will be in 2.8.11 RC1 for you to test out.
Cool :-)
Before I merge it into next, could you have a look at the TI_DSP_to_TI branch,
I had some git trouble and I'm not quite sure everything is in this branch as
it should...
Thanks
A
Matthew Woehlke wrote:
> Now that 2.8.11 supports interface include_directories on targets, is
> there a way to create a library target that can be exported that has no
> actual library, but *does* define interface include_directories?
>
That won't be possible in 2.8.11, but will be possible in
These changes will be in 2.8.11 RC1 for you to test out.
On Thu, Mar 14, 2013 at 2:54 PM, Laszlo Papp wrote:
> On Thu, Mar 14, 2013 at 6:48 PM, Alexander Neundorf <
> a.neundorf-w...@gmx.net> wrote:
>
>> the TI_DSP_to_TI branch on cmake stage now tries to automatically
>> detect the
>> compile
2013/3/14 Casey Basichis
> Sorry about that last post - in a one two punch half of the email got
> selected, deleted and then sent
>
> I've cross compiled several libraries using
> -DCMAKE_OSX_ARCHITECTURES="i386;armv7" ../
>
> I tried compiling with the toolchain and also with the SOCI scripts I
On Thu, Mar 14, 2013 at 6:48 PM, Alexander Neundorf wrote:
> the TI_DSP_to_TI branch on cmake stage now tries to automatically detect
> the
> compiler prefix and suffix and searches ar and strip accordingly.
> It seems to work for me (but I can't run the binaries).
>
> Please verify that it works
Sorry about that last post - in a one two punch half of the email got
selected, deleted and then sent
I've cross compiled several libraries using
-DCMAKE_OSX_ARCHITECTURES="i386;armv7" ../
I tried compiling with the toolchain and also with the SOCI scripts I
posted earlier. The command line flag
On Thursday 14 March 2013, Laszlo Papp wrote:
> On Thu, Mar 14, 2013 at 8:59 AM, Florian Reinhard <
>
> florian.reinh...@googlemail.com> wrote:
> > If ARM and DSP toolchain are commandline compatible, there could be an
> > option to specify the architecture, like C6000 (DSP core in OMAP
> > proces
Hi,
I've looked at the toolchain but I will read the cross compiling one. I
tried compiling SOCI with the toolchain and with those scripts I posted in
my last post.
On the SOCI mailing list they directed me to this, that suggests the
Threading may have been a problem on iOS.
http://stackover
2013/3/14 Casey Basichis
> Hi,
>
> I followed your instructions.
>
> I also modified the make files a bit according to this -
> http://ares.lids.mit.edu/redmine/projects/forest-game/wiki/Building_soci_for_iOS
>Though I'm not using their scripts.
>
> I compiled to 386:Arm7 fat target. Here ar
Hmm, well I think you're missing some variables. The buildscript up on the site
could use some updates, but that should be your ticket.
On 2013-14-03, at 19:10:08 , Casey Basichis wrote:
> Hi,
>
> I followed your instructions.
>
> I also modified the make files a bit according to this -
> htt
Hi,
I followed your instructions.
I also modified the make files a bit according to this -
http://ares.lids.mit.edu/redmine/projects/forest-game/wiki/Building_soci_for_iOS
Though I'm not using their scripts.
I compiled to 386:Arm7 fat target. Here are the errors I get. The thread
bits are at
You can only 'cmake' a single-target. If you want to have more targets, create
more directories: for each target one.
On 2013-14-03, at 19:07:36 , John Drescher wrote:
>> I use cmake 2.8.10 on windows.
>>
>>
>>
>> I would like to build several targets with cmake --build so the
>> underlying
> I use cmake 2.8.10 on windows.
>
>
>
> I would like to build several targets with cmake --build so the
> underlying build tool to do parallel jobs.
>
>
>
> Currently it only seems to be possible to build one target at a time, using
> --target .
> (http://www.cmake.org/cmake/help/v2.8.10/cmake.h
Hello,
I use cmake 2.8.10 on windows.
I would like to build several targets with cmake --build so the
underlying build tool to do parallel jobs.
Currently it only seems to be possible to build one target at a time, using
--target . (http://www.cmake.org/cmake/help/v2.8.10/cmake.html#opt:--bu
You should install boost in /usr/local with ./b2 install, then more packages
will find it. Did you do this or not?
Anyway, I just did this:
git clone git://github.com/SOCI/soci.git
cd soci
cd src
mkdir build
cd build
cmake ..
And it worked for me. So what did you do exactly?
On 2013-14-03, at
On Thursday 14 March 2013, newuserhere wrote:
> Hi,
> I am getting an error in CMAKE configuration after it was updated to 2.8.7.
> The line to which error is pointed :
> /find_package(PythonInterp)/
>
> Well the error is as follows :
>
> /CMake Warning (dev) at
> /usr/share/cmake-2.8/Modules/Fin
Hi,
I'm tryng to build SOCI on iOS. I was able to enter my boost path in my
~/.profile to get that running, but I'm getting stuck on finding threads.
-- Could NOT find Threads (missing: Threads_FOUND)
CMake Error at core/CMakeLists.txt:22 (message):
No thread library found
Is there a way to
I'm still learning (or hacking) my way around using CMake and I've had some
success in attempting to integrate a C# csproj as part of our larger CMake
build with mostly C++ and some C++/CLI projects. This is to build a solution
file for Visual Studio 2008. I am doing some customization of the cspro
Hi,
I am getting an error in CMAKE configuration after it was updated to 2.8.7.
The line to which error is pointed :
*find_package(PythonInterp)*
Well the error is as follows :
*CMake Warning (dev) at
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:86
(INCLUDE):
File /usr/share
Hi,
I am getting an error in CMAKE configuration after it was updated to 2.8.7.
The line to which error is pointed :
/find_package(PythonInterp)/
Well the error is as follows :
/CMake Warning (dev) at
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:86
(INCLUDE):
File /usr/sha
Now that 2.8.11 supports interface include_directories on targets, is
there a way to create a library target that can be exported that has no
actual library, but *does* define interface include_directories?
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
On Thursday 14 March 2013 10:57:10 Brad King wrote:
> On 03/14/2013 10:47 AM, Matthew Woehlke wrote:
> > This is now pushed to stage/fix-java-jar-depends. If someone
> > knowledgeable could have a look, that would be much appreciated.
>
> Andreas, Nicholas?
Hi Brad,
thanks for the mail. I've rev
On 03/14/2013 10:47 AM, Matthew Woehlke wrote:
> This is now pushed to stage/fix-java-jar-depends. If someone
> knowledgeable could have a look, that would be much appreciated.
Andreas, Nicholas?
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://ww
On 2013-03-13 18:14, Matthew Woehlke wrote:
On 2013-03-13 17:09, Matthew Woehlke wrote:
I have a project that builds a bunch of jar's with add_jar from
UseJava.cmake. Let's say we have myjar1 and myjar2. How do I write the
build rules for myjar2 such that it depends on myjar1?
It looks like add
On 03/14/2013 12:43 AM, James Bigler wrote:
> I'm not sure what the expected behavior is supposed to be
IMPORTED_LINK_DEPENDENT_LIBRARIES is not about transitive linking.
That is IMPORTED_LINK_INTERFACE_LIBRARIES.
The former is only for implementation dependencies of a shared
library that are not
On 3/14/2013 7:13 AM, ChangZhuo Chen wrote:
Hi,
I am a maintainer of libchewing project [1] which try to integrate cmake
recently. However, we need
unicode/wide curses library to build our tool, but cmake cannot find the
unicode/wide curses library.
This issue was already reported before [2] but
Hi,
I am a maintainer of libchewing project [1] which try to integrate cmake
recently. However, we need
unicode/wide curses library to build our tool, but cmake cannot find the
unicode/wide curses library.
This issue was already reported before [2] but is not fix yet. Is there any
plan to implemen
Dear All,
I finally succeeded in installing gromacs 4.6.1 with prefix.
Michael you were right, I need to set GMS_DEFAULT_SUFFIX to FALSE.
Following is the command line option used :
CMAKE_PREFIX_PATH=/soft/sudip/abc/apps/fftw-3.3.3 CC=icc cmake ..
-DCMAKE_INSTALL_PREFIX=/soft/sudip/abc/apps/gromac
On Thu, Mar 14, 2013 at 8:59 AM, Florian Reinhard <
florian.reinh...@googlemail.com> wrote:
> If ARM and DSP toolchain are commandline compatible, there could be an
> option to specify the architecture, like C6000 (DSP core in OMAP
> processors), C2000, C6400 which map to the correct
> compiler/li
If ARM and DSP toolchain are commandline compatible, there could be an
option to specify the architecture, like C6000 (DSP core in OMAP
processors), C2000, C6400 which map to the correct
compiler/linker/archiver/strip names.
2013/3/14 Laszlo Papp :
> On Wed, Mar 13, 2013 at 10:14 PM, Alexander Neu
40 matches
Mail list logo
