On 2009-05-12 09:01, Werner Smekal wrote:
>
>> Of course the above "parallel" testing considerations for both install
>> tree
>> and build tree are only relevant on Windows if there is a Windows CMake
>> generator that allows parallel commands to be executed similar to the GNU
>> make -j option.
> Of course the above "parallel" testing considerations for both
> install tree
> and build tree are only relevant on Windows if there is a Windows
> CMake
> generator that allows parallel commands to be executed similar to
> the GNU
> make -j option.
AFAIK this is the case for mingw32-make
On 2009-05-12 08:50, Alan W. Irwin wrote:
> On 2009-05-12 08:01+0200 Werner Smekal wrote:
>
>
> I do both, but my tendency is to use the install tree a lot more,
> because of
> the substantial (factor of two gain in speed for my two-CPU box) advantage
> of a parallel test infrastructure there th
On 2009-05-12 08:01+0200 Werner Smekal wrote:
> Hi,
>
> On 11.05.2009, at 19:19, Alan W. Irwin wrote:
>> However, I really do hope you and Werner explore that territory soon. Once
>> set up, it should be a much easier environment for you guys to work in
>> because everything is located in consist
Hi,
On 11.05.2009, at 19:19, Alan W. Irwin wrote:
> On 2009-05-11 13:55+0200 Arjen Markus wrote:
>
>> Hi Alan, Andrew, Werner,
>>
>> it may be nothing of consequence, but when I fixed the command-line
>> issue with Fortran 77/95 last week, I could not find any pkg-config
>> file for the platforms
On 2009-05-11 12:19-0700 Alan W. Irwin wrote:
> On 2009-05-11 10:19-0700 Alan W. Irwin wrote:
>
>> My attention was drawn to this possibility [of a CMake-based build of
> the installed examples] recently on the CMake list so I
>> thought I would share it here, but I know nothing more about this th
On 2009-05-11 22:27+0100 Andrew Ross wrote:
>> These results seem exactly consistent with my analysis. Do you confirm these
>> results on your own system with and without CMAKE_BUILD_TYPE being
>> specified?
>
> I do, but my interpretation of the libraries after the debug is different to
> yours.
On Sun, May 10, 2009 at 08:42:56AM -0700, Alan Irwin wrote:
> On 2009-05-10 11:38+0100 Andrew Ross wrote:
>
> >> I don't completely trust QT_LIBRARIES_optimized because it appears to be
> >> incomplete (see above discussion). However, I have checked with "ldd -r
> >> qt.so" and "ldd -r qt_example
On 2009-05-11 10:19-0700 Alan W. Irwin wrote:
> My attention was drawn to this possibility [of a CMake-based build of
the installed examples] recently on the CMake list so I
> thought I would share it here, but I know nothing more about this then what
> I read in the cmake documentation. I don't
On 2009-05-11 10:19-0700 Alan W. Irwin wrote:
> Finally, I should note that if you don't like the pkg-config approach to
> deliver the build information you need in the installed examples tree there
> is another good possibility which is to store the needed compile and link
> information for libra
On 2009-05-11 13:55+0200 Arjen Markus wrote:
> Hi Alan, Andrew, Werner,
>
> it may be nothing of consequence, but when I fixed the command-line
> issue with Fortran 77/95 last week, I could not find any pkg-config
> file for the platforms I looked at (notably MinGW). I may have missed
> it, but I
Hi Alan, Andrew, Werner,
it may be nothing of consequence, but when I fixed the command-line
issue with Fortran 77/95 last week, I could not find any pkg-config
file for the platforms I looked at (notably MinGW). I may have missed
it, but I was curious whether I should do something about it, as
th
On 2009-05-10 11:38+0100 Andrew Ross wrote:
>> I don't completely trust QT_LIBRARIES_optimized because it appears to be
>> incomplete (see above discussion). However, I have checked with "ldd -r
>> qt.so" and "ldd -r qt_example" that -DCMAKE_BUILD_TYPE=Release works on
>> Linux without any undefi
On Sat, May 09, 2009 at 01:18:17PM -0700, Alan Irwin wrote:
> On 2009-05-09 11:09+0100 Andrew Ross wrote:
>
>> On Fri, May 08, 2009 at 02:01:59PM -0700, Alan Irwin wrote:
>>> P.S. I now see you actually committed a fix to pkg-config.cmake. Since my
>>> changes dealt with the QT_LIBRARIES issue dir
On 2009-05-09 11:09+0100 Andrew Ross wrote:
> On Fri, May 08, 2009 at 02:01:59PM -0700, Alan Irwin wrote:
>> P.S. I now see you actually committed a fix to pkg-config.cmake. Since my
>> changes dealt with the QT_LIBRARIES issue directly, I am wondering whether
>> we should revert your change (bec
On Fri, May 08, 2009 at 02:01:59PM -0700, Alan Irwin wrote:
> P.S. I now see you actually committed a fix to pkg-config.cmake. Since my
> changes dealt with the QT_LIBRARIES issue directly, I am wondering whether
> we should revert your change (because I am not quite sure whether that logic
> will
P.S. I now see you actually committed a fix to pkg-config.cmake. Since my
changes dealt with the QT_LIBRARIES issue directly, I am wondering whether
we should revert your change (because I am not quite sure whether that logic
will always work properly) or just leave it in case some other library e
On 2009-05-08 19:09+0100 Andrew Ross wrote:
> On Thu, May 07, 2009 at 04:52:28PM -0700, Alan Irwin wrote:
>> On 2009-05-07 21:49+0100 Andrew Ross wrote:
>>
>>> You are probably right. What I don't understand is why it works with the
>>> general tag (which is there even if you don't specify a build
On Thu, May 07, 2009 at 04:52:28PM -0700, Alan Irwin wrote:
> On 2009-05-07 21:49+0100 Andrew Ross wrote:
>
> > You are probably right. What I don't understand is why it works with the
> > general tag (which is there even if you don't specify a build type, but
> > not with the optimized or debug t
On 2009-05-07 21:49+0100 Andrew Ross wrote:
> You are probably right. What I don't understand is why it works with the
> general tag (which is there even if you don't specify a build type, but
> not with the optimized or debug tags.
Well remember, the likes of
plplotd_LIB_DEPENDS:STATIC=general;
On Thu, May 07, 2009 at 12:20:49PM -0700, Alan Irwin wrote:
> On 2009-05-07 10:53+0100 Andrew Ross wrote:
>
>>
>> Further to my previous report, this only seems to occur if you explicitly
>> set the cmake build type, e.g. with -DCMAKE_BUILD_TYPE=Debug. This is
>> probably why no-one has reported it
On Thu, May 07, 2009 at 10:36:37AM -0700, Alan Irwin wrote:
> On 2009-05-07 10:53+0100 Andrew Ross wrote:
>
>>
>> Further to my previous report, this only seems to occur if you explicitly
>> set the cmake build type, e.g. with -DCMAKE_BUILD_TYPE=Debug. This is
>> probably why no-one has reported it
On 2009-05-07 10:53+0100 Andrew Ross wrote:
>
> Further to my previous report, this only seems to occur if you explicitly
> set the cmake build type, e.g. with -DCMAKE_BUILD_TYPE=Debug. This is
> probably why no-one has reported it before. Without this option the Qt library
> dependencies contain
On 2009-05-07 10:53+0100 Andrew Ross wrote:
>
> Further to my previous report, this only seems to occur if you explicitly
> set the cmake build type, e.g. with -DCMAKE_BUILD_TYPE=Debug. This is
> probably why no-one has reported it before. Without this option the Qt library
> dependencies contain
Further to my previous report, this only seems to occur if you explicitly
set the cmake build type, e.g. with -DCMAKE_BUILD_TYPE=Debug. This is
probably why no-one has reported it before. Without this option the Qt library
dependencies contain no type tags and so the problem does not occur. Not
I think I have found a bug with our current cmake build system. For link
flags cmake now (with cmake 2.6.3 at least) adds a tag describing which
type of build this link flag is for. E.g.
plpotf77cd_LIB_DEPENDS:STATIC=general;plplotd;
On the whole we seem to handle the general tag correctly, al
26 matches
Mail list logo
