Am 09.06.2011 07:35, schrieb Michael Hertling:
On 06/09/2011 07:13 AM, Andreas Naumann wrote:
Am 08.06.2011 20:43, schrieb Andreas Pakulat:
On 08.06.11 20:00:54, Andreas Naumann wrote:
Am 08.06.2011 15:02, schrieb Eric Noulard:
2011/6/8 Andreas Naumann:
On 06/09/2011 07:13 AM, Andreas Naumann wrote:
> Am 08.06.2011 20:43, schrieb Andreas Pakulat:
>> On 08.06.11 20:00:54, Andreas Naumann wrote:
>>
>>> Am 08.06.2011 15:02, schrieb Eric Noulard:
>>>
2011/6/8 Andreas Naumann:
> Am 08.06.2011 11:56, schrieb Eric Noulard:
Am 08.06.2011 20:43, schrieb Andreas Pakulat:
On 08.06.11 20:00:54, Andreas Naumann wrote:
Am 08.06.2011 15:02, schrieb Eric Noulard:
2011/6/8 Andreas Naumann:
Am 08.06.2011 11:56, schrieb Eric Noulard:
2011/6/8 Andreas Naumann:
Hi @all,
I have some
On 06/07/2011 09:13 PM, Bjørn Forsman wrote:
> 2011/6/7 Michael Wild :
>> If the FindXXX.cmake file called add_definitions(),
>> include_directories() et al., that could be potentially harmful. Some
>> sources might required that some define is not set, or a wrong header
>> file might be #include'e
On 06/07/2011 06:58 PM, Michael Wild wrote:
> On 06/07/2011 06:23 PM, Bjørn Forsman wrote:
>> 2011/6/7 Michael Wild :
>>> On 06/07/2011 03:38 PM, Bjørn Forsman wrote:
Why not put find_package(Qt4) in the sub directories where it is actually
used?
>>>
>>> And if it is used in multiple sub
On 06/07/2011 02:20 PM, Bjørn Forsman wrote:
> Hi all,
>
> As far as I can tell, all Qt programs built with CMake must include
> QT_USE_FILE after find_package(). So why doesn't FindQt4.cmake simply
> include QT_USE_FILE itself? Is there maybe a use case where
> QT_USE_FILE is *not* wanted?
Yes,
On Tuesday 07 June 2011, Alexander Neundorf wrote:
> On Tuesday, June 07, 2011 04:41:03 AM jeeyoung kim wrote:
> > I was wondering if there's some way to prevent make clean in cmake from
> > re-building external dependencies. I'm using ExternalProject to build
> > third party c++ libraries, and the
On Wednesday 08 June 2011, Ilias Miroslav wrote:
> Dear CMake developers,
>
> for our oproject we are utilizing the 'make Exerimental' and 'make Nigthly'
> commands to make the all (update)/configure/build/test and sending report
> steps.
>
> One can see that on our CDash-board, like
> https://r
On 08.06.11 20:00:54, Andreas Naumann wrote:
> Am 08.06.2011 15:02, schrieb Eric Noulard:
> >2011/6/8 Andreas Naumann:
> >>Am 08.06.2011 11:56, schrieb Eric Noulard:
> >>>2011/6/8 Andreas Naumann:
> >>>
> Hi @all,
>
> I have some problem with the library usage in cmake.
>
> It
Am 08.06.2011 15:02, schrieb Eric Noulard:
2011/6/8 Andreas Naumann:
Am 08.06.2011 11:56, schrieb Eric Noulard:
2011/6/8 Andreas Naumann:
Hi @all,
I have some problem with the library usage in cmake.
It seems to me, that cmake removes the full path of the library, if the
p
Hi Mathieu,
May be you could try the following ...
file(GLOB log_files "*.log")
if(log_files)
execute_process(${CMAKE_COMMAND} -E tar cvfz test.tgz ${log_files})
endif()
Hth
Jc
On Wed, Jun 8, 2011 at 12:05 PM, Mathieu Malaterre <
mathieu.malate...@gmail.com> wrote:
> Hi there,
>
> Slightly
Hi there,
Slightly off topic, but how do people cope with cmd.exe not
expanding wildcards (*) ?
I would like to do something like:
cmd> cmake -E tar cvfz test.tgz *.log
Thanks
--
Mathieu
___
Powered by www.kitware.com
Visit other Kitware open-so
2011/6/8 Ilias Miroslav :
> Dear experts,
>
> We would like to check the generated target (main executable) after it was
> built.
>
> For example
> .
> .
> Linking Fortran executable vibcal.x
> [100%] Built target vibcal.x
> [100%] Built target dirac.x
>
> afterwards, it would be good to get own m
Dear experts,
We would like to check the generated target (main executable) after it was
built.
For example
.
.
Linking Fortran executable vibcal.x
[100%] Built target vibcal.x
[100%] Built target dirac.x
afterwards, it would be good to get own message about properties of the
generated target
2011/6/8 Andreas Naumann :
> Am 08.06.2011 11:56, schrieb Eric Noulard:
>>
>> 2011/6/8 Andreas Naumann:
>>
>>>
>>> Hi @all,
>>>
>>> I have some problem with the library usage in cmake.
>>>
>>> It seems to me, that cmake removes the full path of the library, if the
>>> path
>>> is in the environment
Am 08.06.2011 11:56, schrieb Eric Noulard:
2011/6/8 Andreas Naumann:
Hi @all,
I have some problem with the library usage in cmake.
It seems to me, that cmake removes the full path of the library, if the path
is in the environment variable LIBRARY_PATH.
This behaviour cause problems at our
On Tuesday 07 Jun 2011 7:40:33 PM dfurt...@cox.net wrote:
> I have been hammergin on a vxworks cross-compile toolchain file. It seems
> that not all properties that are set in the cross-compilation file
> propogate to the CMakeLists.txt file that is using it. An example is the
> CMAKE_AR property.
2011/6/8 Andreas Naumann :
> Hi @all,
>
> I have some problem with the library usage in cmake.
>
> It seems to me, that cmake removes the full path of the library, if the path
> is in the environment variable LIBRARY_PATH.
> This behaviour cause problems at our system, such that the linker links
>
2011/6/7 Jean-Christophe Fillion-Robin :
> Hi Folks,
>
> I observed there are different ways of naming binary packages:
>
> myproject-Linux-i386.{ext}
> myproject-Linux-amd64.{ext}
> myproject-Linux-x86_32.{ext}
> myproject-Linux-x86_64.{ext}
>
> myproject-Windows-win32_x86.{ext}
>
Hi @all,
I have some problem with the library usage in cmake.
It seems to me, that cmake removes the full path of the library, if the
path is in the environment variable LIBRARY_PATH.
This behaviour cause problems at our system, such that the linker links
against the wrong library.
Is there
20 matches
Mail list logo
