On Sat, Mar 20, 2010 at 7:04 PM, Eric Noulard wrote:
> Ok then it explains the difference.
> File must installed at there absolute location but not package by CPack
> which cannot handle aboslute location without using CPACK_SET_DESTDIR.
>
> Another option would be to use fakeroot
> see http://www
2010/3/20 Rob Hasselbaum :
> Thanks for the quick responses!
>
> On Sat, Mar 20, 2010 at 6:20 PM, Eric Noulard wrote:
>> Which one did you try?
>> RPM, TGZ, ZIP ?
>
> DEB and TGZ.
>
>> when you do "make install" are you root or normal user?
>> Are you installing files in absolute location or relat
Thanks for the quick responses!
On Sat, Mar 20, 2010 at 6:20 PM, Eric Noulard wrote:
> Which one did you try?
> RPM, TGZ, ZIP ?
DEB and TGZ.
> when you do "make install" are you root or normal user?
> Are you installing files in absolute location or relatively to your
> install prefix?
I am ro
2010/3/20 Rob Hasselbaum :
> Hi all,
>
> I'm trying to use CPack to generate packages for my Linux-based
> project (version 2.6), but what I'm finding is that some files are
> missing from the output package regardless of what generator I try.
Which one did you try?
RPM, TGZ, ZIP ?
> Specifically
On 03/20/2010 02:23 PM, Rob Hasselbaum wrote:
Hi all,
I'm trying to use CPack to generate packages for my Linux-based
project (version 2.6), but what I'm finding is that some files are
missing from the output package regardless of what generator I try.
Specifically, executables, shared libraries
> If the projects UMC3D, GFL etc can be used independently, but
> are all "under your control", then you shouldn't write
> FindUMC3D.cmake, FindGFL.cmake etc files, but create
> UMC3D-config.cmake, GFL-config.cmake etc files instead. Read
> the documentation of the FIND_PACKAGE command, especia
Hi all,
I'm trying to use CPack to generate packages for my Linux-based
project (version 2.6), but what I'm finding is that some files are
missing from the output package regardless of what generator I try.
Specifically, executables, shared libraries, and resources files
passed through the "config
On Sat, Mar 20, 2010 at 11:30 AM, Theodore Papadopoulo
wrote:
> Hi,
>
> I have the following problem.
> I try to build a DLL library with Visula Studio 2005. The project is
> schematically structured in this way:
>
> project:
> src
> test
> zlib
>
> The src directory contains the so
Hi,
I have the following problem.
I try to build a DLL library with Visula Studio 2005. The project is
schematically structured in this way:
project:
src
test
zlib
The src directory contains the sources of the DLL library.
The test directory contains a sample binary that im
I also face this bug, which seems not to have been fixed.
I use Cygwin and MinGV on XP.
This thread was posted on the ITK bug list, so should I copy it on the cmake
bug list?
http://www.itk.org/Bug/view.php?id=8516
_
On 20. Mar, 2010, at 14:15 , Daniel Lidström wrote:
> Hi Mike,
>
>> Most of us would write a "FindGFL.cmake" file which will locate the
>> GFL library and set GFL_INCLUDE_DIRS, GFL_LIBRARIES, and other
>> standard directories/files like that. Some of these files will do the
>> "include(${GFL_IN
Hi Mike,
> Most of us would write a "FindGFL.cmake" file which will locate the
> GFL library and set GFL_INCLUDE_DIRS, GFL_LIBRARIES, and other
> standard directories/files like that. Some of these files will do the
> "include(${GFL_INCLUDE_DIRS}" for you and some will not.
>Some design those
Most of us would write a "FindGFL.cmake" file which will locate the
GFL library and set GFL_INCLUDE_DIRS, GFL_LIBRARIES, and other
standard directories/files like that. Some of these files will do the
"include(${GFL_INCLUDE_DIRS}" for you and some will not.
Some design those (like FindQt4.cmake)
Hello,
I am just starting to get familiar with CMake. We are currently using
Boost.Build,
so I am of course used to the behaviour of Boost.Build. One of the things I am
now
trying to do with CMake is to set library usage requirements. For example, with
Boost.Build I can specify the include/ dire
14 matches
Mail list logo