On 8/11/10 4:29 PM, Michael Wild wrote:
>
> On 11. Aug, 2010, at 22:16 , Michael Jackson wrote:
>
>>
>>
>> On Aug 11, 2010, at 3:52 PM, Michael Wild wrote:
>>
>>>
>>> On 11. Aug, 2010, at 21:44 , Erik Lindahl wrote:
>>>
Hi,
Sound technical answers from both David & Clinton - I se
On 8/11/10 5:39 PM, Eric Noulard wrote:
> 2010/8/11 Thawan Kooburat :
>> Hi Eric,
>>
>> I read though this thread and also two bug reports related to this issue.
>>
>> It seems like it will take a while because of CPack design issue. Do
>> you think there will be any workaround or small hack to m
On 11.08.10 16:07:21, Brad King wrote:
> On 08/05/2010 02:29 PM, Andreas Pakulat wrote:
> > One more info: I'm seeing the 'Scanning dependencies of target
> > kdevpatchreview' message a lot later than the error when using -k with
> > make. And at that point I also see the 'Generating ui_xxx.h' mess
I am using Ctest to do testing and coverage for my code. The directory is
set up like so:
SourceDir/
subdir1/
foo.cpp
foo.gcda
foo.gcno
foo.h
subsub/
foo2.cpp
foo2.gcda
foo2.gcno
subdir2/
bar
2010/8/11 Thawan Kooburat :
> Hi Eric,
>
> I read though this thread and also two bug reports related to this issue.
>
> It seems like it will take a while because of CPack design issue. Do
> you think there will be any workaround or small hack to make this work
> with current CPackRPM?
I think it
Hi Eric,
I read though this thread and also two bug reports related to this issue.
It seems like it will take a while because of CPack design issue. Do
you think there will be any workaround or small hack to make this work
with current CPackRPM?
On Tue, Aug 10, 2010 at 7:48 AM, Chris Wolf wrot
On 11. Aug, 2010, at 22:31 , Erik Lindahl wrote:
> Hi Mike,
>
> On Aug 11, 2010, at 10:16 PM, Michael Jackson wrote:
>>
>> So CMake is _trying_ to help you as best it can at the moment. You should
>> still be able to wrap the test to CheckTypeSize() with your own function,
>> detect the chang
Hi Mike,
On Aug 11, 2010, at 10:16 PM, Michael Jackson wrote:
>
> So CMake is _trying_ to help you as best it can at the moment. You should
> still be able to wrap the test to CheckTypeSize() with your own function,
> detect the change to CMAKE_OSX_ARCHITECTURES and the forcibly rerun the test
On 11. Aug, 2010, at 22:16 , Michael Jackson wrote:
>
>
> On Aug 11, 2010, at 3:52 PM, Michael Wild wrote:
>
>>
>> On 11. Aug, 2010, at 21:44 , Erik Lindahl wrote:
>>
>>> Hi,
>>>
>>> Sound technical answers from both David & Clinton - I see the limitations,
>>> and why we have to live with
On Wed, Aug 11, 2010 at 10:23 PM, Clinton Stimpson wrote:
>> No we didn't. And no, it is not the same problem. Windows compiles a
>> single architecture at a time.
>>
>
> He may be referring to a previous discussion was about one visual studio
> project to generate both 32 and 64 bit code. In tha
On Wednesday, August 11, 2010 02:13:09 pm Michael Jackson wrote:
> H
> ___
> Mike Jackson www.bluequartz.net
> Principal Software Engineer mike.jack...@bluequartz.net
> BlueQuartz Software Dayton, Ohio
On Aug 11, 2010, at 3:52 PM, Michael Wild wrote:
On 11. Aug, 2010, at 21:44 , Erik Lindahl wrote:
Hi,
Sound technical answers from both David & Clinton - I see the
limitations, and why we have to live with it for now ;-)
Given that there are good reasons to change it on-the-fly, but th
H
___
Mike Jackson www.bluequartz.net
Principal Software Engineer mike.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
On Aug 11, 2010, at 4:00 PM, Olaf van der Spek wrote:
On Wed, Aug 11,
On 08/05/2010 02:29 PM, Andreas Pakulat wrote:
> One more info: I'm seeing the 'Scanning dependencies of target
> kdevpatchreview' message a lot later than the error when using -k with
> make. And at that point I also see the 'Generating ui_xxx.h' message.
[snip]
On 08/11/2010 03:46 PM, Andreas Pak
On Wed, Aug 11, 2010 at 9:52 PM, Michael Wild wrote:
> The problem is more fundamental. If you set CMAKE_OSX_ARCHITECTURES to e.g.
> i386;x86_64;ppc;ppc64 to compile a four-way universal binary, what is the
> expected result from CheckTypeSize() and similar functions? There should be
> one resu
On 11. Aug, 2010, at 21:44 , Erik Lindahl wrote:
> Hi,
>
> Sound technical answers from both David & Clinton - I see the limitations,
> and why we have to live with it for now ;-)
>
> Given that there are good reasons to change it on-the-fly, but that it is
> still almost as fundamental as a
Hi,
Sound technical answers from both David & Clinton - I see the limitations, and
why we have to live with it for now ;-)
Given that there are good reasons to change it on-the-fly, but that it is still
almost as fundamental as a compiler change, perhaps it could at least make
sense to display
On Wednesday, August 11, 2010 12:52:32 pm Erik Lindahl wrote:
> Hi Sean,
>
> On Aug 11, 2010, at 8:08 PM, Sean McBride wrote:
> > On Wed, 11 Aug 2010 18:08:35 +0200, Erik Lindahl said:
> >> All the CheckTypeSize() tests then seem to run directly when e.g. ccmake
> >> is invoked, and they thus set
On Wed, Aug 11, 2010 at 2:52 PM, Erik Lindahl wrote:
> Hi Sean,
>
> On Aug 11, 2010, at 8:08 PM, Sean McBride wrote:
>
> > On Wed, 11 Aug 2010 18:08:35 +0200, Erik Lindahl said:
> >
> >> All the CheckTypeSize() tests then seem to run directly when e.g. ccmake
> >> is invoked, and they thus set al
Hi Sean,
On Aug 11, 2010, at 8:08 PM, Sean McBride wrote:
> On Wed, 11 Aug 2010 18:08:35 +0200, Erik Lindahl said:
>
>> All the CheckTypeSize() tests then seem to run directly when e.g. ccmake
>> is invoked, and they thus set all SIZEOF_XXX defines to the 64-bit
>> values (e.g. 8 for "long int")
Hi Mike,
Oh, we already have a _huge_ amount of configuration #ifdefs since we run on
virtually every hardware and OS there is that supports ANSI C. Think Fujitsu
FR-V embedded chips, MIPS, ia64, Cray Unicos, Playstation3, Sparc & Sparc64,
PowerPC, Power5,6,7, PowerCell 8xi, BlueGene (with and
On Wed, 11 Aug 2010 18:08:35 +0200, Erik Lindahl said:
>All the CheckTypeSize() tests then seem to run directly when e.g. ccmake
>is invoked, and they thus set all SIZEOF_XXX defines to the 64-bit
>values (e.g. 8 for "long int").
Why do you need to know the size of 'long'? Its size is not guaran
Erik,
OS X is "special" because of all the platforms that CMake supports
it is the only one where you can compile for multiple architectures at
the same time. All the other platforms assume 1) you are compiling for
the platform you are running on or 2) you are cross compiling and you
hav
Hi,
Thanks for the suggested workaround Mike!
However, that will get pretty cluttered when we add everything we need for 50MB
of source code... Our entire reason for moving from autoconf CMake is to avoid
having Windows as a "special case", so we'd rather not exchange it for having
OS X as a s
So basically you will "over ride" some of the values that get returned
from those tests for OS X. Typically you end up with a "Configuration"
file that has something like this in it:
#if !defined(__APPLE__)
/* The size of `size_t', as computed by sizeof. */
#define MXA_SIZEOF_SIZE_T
/* The s
Hi cmake-list,
We've run into a minor problem when adapting our source code Gromacs to use
CMake for the default build environment.
CMake 2.8 doesn't use any string for the default OS X architecture, which on
Snow Leopard is interpreted as the default x86_64.
All the CheckTypeSize() tests then
On Sun, Aug 8, 2010 at 11:44 AM, Eric Noulard wrote:
> 2010/8/7 David Cole :
> > Excellent! I am now officially done for the weekend. :-)
> > Would you recommend a certain location on the Wiki? i.e. -- were you
> looking
> > someplace for this, and found a place where you think such an explanation
On 10-08-11 8:36 AM, Nicholas Kinar wrote:
Does this file actually exist?
/Library/Frameworks/Python.framework/Versions/6.1/lib/vtk-5.4/libvtkHybrid.dylib
The question is, how did you get a VTK library inside your python
framework? That is completely unexpected. (As is a 6.1 version of
pytho
On 10-08-11 7:08 AM, Bill Hoffman wrote:
On 8/11/2010 12:53 AM, Nicholas Kinar wrote:
Library/Frameworks/Python.framework/Versions/6.1/lib/vtk-5.4/libvtkHybrid.dylib,
file was built for i386 which is not the architecture being linked
(x86_64)
You built VTK 32 bit, and are now trying to link it
On 08/10/2010 09:13 AM, Andreas Pakulat wrote:
> On 10.08.10 09:04:34, Brad King wrote:
>> On 08/05/2010 05:33 PM, Andreas Pakulat wrote:
>>> Sure, this is the plugin that breaks:
>>> http://gitorious.org/kdevelop/kdevplatform/blobs/master/plugins/reviewboard/CMakeLists.txt
>>
>> Do you have KDE4_E
Does this file actually exist?
/Library/Frameworks/Python.framework/Versions/6.1/lib/vtk-5.4/libvtkHybrid.dylib
The question is, how did you get a VTK library inside your python
framework? That is completely unexpected. (As is a 6.1 version of
python... as far as I know, version 6.1 of python
Hi again,
even more strange: Now everything runs fine again. But the self link is still
there and I have changed nothing. :confused:
Thanks for your reply!
Andreas
___
Powered by www.kitware.com
Visit other
Hi,
> OK... I won't ask "why?" -- the fact that you told us not to ask means you
> realize this is some flavor of crazy
I'm actually sure, that it was useful for them at some point in time... no, I'm
not!
> I would guess it's because of the symlink to "." that you mention. Does the
> sam
On 8/11/2010 12:53 AM, Nicholas Kinar wrote:
Library/Frameworks/Python.framework/Versions/6.1/lib/vtk-5.4/libvtkHybrid.dylib,
file was built for i386 which is not the architecture being linked (x86_64)
You built VTK 32 bit, and are now trying to link it to a 64 bit
application. You have to bui
On Wed, Aug 11, 2010 at 4:21 AM, Diablo 666 wrote:
> Hi,
>
> I'm getting in some trouble with a self linking directory under Linux here.
> In /home/, there is a sym-link "zam", linking to . (please don't ask me, why
> they created this one...)
>
OK... I won't ask "why?" -- the fact that you tol
Does this file actually exist?
/Library/Frameworks/Python.framework/Versions/6.1/lib/vtk-5.4/libvtkHybrid.dylib
The question is, how did you get a VTK library inside your python framework?
That is completely unexpected. (As is a 6.1 version of python... as far as I
know, version 6.1 of python is s
Hi,
I'm getting in some trouble with a self linking directory under Linux here. In
/home/, there is a sym-link "zam", linking to . (please don't ask me, why they
created this one...)
Now I have a directory Test with a sub-directory Foo and the following
CMakeLists.txt:
cmake_minimum_required
On Tue, Aug 10, 2010 at 7:47 PM, Alexander Neundorf
wrote:
> On Tuesday 10 August 2010, Mathieu Malaterre wrote:
>> Hi there,
>>
>> I am trying to find a solution to find the openjpeg package.
>>
>> In the 1.x version, openjpeg uses a makefile based build system. In
>> this case I need to writ
38 matches
Mail list logo
