Thanks Michael. I had not included the ${OCTCommon_SOURCE_DIR}/src using
INCLUDE_DIRECTORIES.
- Prathamesh
On 10/20/2010 07:55 PM, Prathamesh Kulkarni wrote:
> I do not understand why I am having errors for only .txx files and not for
> .cpp files placed in the same common folder. Any help would
I know you're simplifying to provide an example, but I hope you don't
normally set CMAKE_CC_COMPILER, CMAKE_Fortran_COMPILER and
CMAKE_CXX_COMPILER in your CMakeLists.txt.
That's precisely the sort of thing that CMake is meant to find for
you. It will find the compilers needed to compile your sou
On Wednesday 20 October 2010, Mohammed Aziz Parande wrote:
> Dear Developers,
>
>
>
> I am a graduate student from University of Maryland Baltimore County.
>
> I have a simple question pertaining to Cmake Development Cycle.
>
>
>
> Has Cmake gone under some refactoring efforts before any of its rel
On 10/20/2010 07:55 PM, Prathamesh Kulkarni wrote:
> I do not understand why I am having errors for only .txx files and not for
> .cpp files placed in the same common folder. Any help would be highly
> appreciated. Right now, I am forced to paste common the files in all the
> project folders where
I do not understand why I am having errors for only .txx files and not for
.cpp files placed in the same common folder. Any help would be highly
appreciated. Right now, I am forced to paste common the files in all the
project folders where ever they are required.
- Prathamesh
On Wed, Oct 20, 2010
> What would a 'debian/rules' file that used CPack look like?
The `debian/rules` file that is generated by my script does currently
not rely on CPack since CPack cannot generate more than one package.
What it currently does, is using CMake to install one component at a
time and then call dpkg to
Thanks, I tried getting rid of the GLOB. But I am still getting the same
error as earlier:
fatal error C1083: Cannot open include file:
'itkImageToVTKImageFilter.txx': No such file or directory
(This file is present in a common directory)
The CMakeLists now looks like this:
SET(IMPORTED_SRCS
> The standard debian way is to have an executable file named
`debian/rules` which creates packages when invoked.
Interesting. Now that I think about it, I guess that's correct. I was
confused by my mostly empty 'debian/rules' file into thinking that it was
an additional layer above that did th
Okay, could you please suggest an alternative over this issue?
- Prathamesh
On Wed, Oct 20, 2010 at 11:16 AM, John Drescher wrote:
> On Wed, Oct 20, 2010 at 12:05 PM, Prathamesh Kulkarni
> wrote:
> >
> > Hello all,
> >
> > I want to interface VTK and ITK. Hence I copied the required 4 files (2
Hi,
> Does it make sense to use CPack for debian packaging?
If you just want to build debian packages, then it probably does not
make sense to use CPack. If however you want to build packages for a
range of platforms and you want to keep them consistent, then CPack
would be an excellent choice.
On Wed, Oct 20, 2010 at 12:19 PM, Prathamesh Kulkarni
wrote:
> Okay, could you please suggest an alternative over this issue?
>
I add each file one by one in variables. The following is from an app
used for unit testing my Qt SQLITE database for my current
application.
SET( DEMO_SRCS
./s
On Wed, Oct 20, 2010 at 12:05 PM, Prathamesh Kulkarni
wrote:
>
> Hello all,
>
> I want to interface VTK and ITK. Hence I copied the required 4 files (2 txx
> and 2 cpp) in InsightApplications/Auxilliary/vtk to a common source
> directory which I want to include in all my other project source
> dir
Hello all,
I want to interface VTK and ITK. Hence I copied the required 4 files (2 txx
and 2 cpp) in InsightApplications/Auxilliary/vtk to a common source
directory which I want to include in all my other project source
directories. In doing this, I am using the following CMake commands:
SET(IMPO
Does it make sense to use CPack for debian packaging? When I first started
my current project I explored creating debian packages with CPack. I
decided not to because it is counter to what any typical debian user will
expect. Anyone getting the source for a debian package knows that running
"dp
On 10/20/2010 9:29 AM, Tim St. Clair wrote:
when using ExternalProject_Add with hand built version of cmake 2.8.2
seems to have a series of issues with auto tools relating to the env,
the afore mentioned example is a direct repo. Where it will fail in
RHEL 5.5 re-running aclocal (when I don't b
Retransmit on the ML.
-- Forwarded message --
From: Eric Noulard
Date: 2010/10/20
Subject: Re: [CMake] Creating Debian source packages with CMake
To: Daniel Pfeifer
2010/10/20 Daniel Pfeifer :
> Hi,
>
> CPack, the packaging system that ships with CMake, builds
> component-based
On Wed, Oct 20, 2010 at 8:19 AM, Bill Hoffman wrote:
> On 10/20/2010 9:08 AM, Tim St. Clair wrote:
>>
>> correction, I can see this issue with 2.8.2 i386 binaries vs. hand build.
>>
>
> Tim, it is still unclear to me what your problem is
when using ExternalProject_Add with hand built version of c
On 10/20/2010 9:08 AM, Tim St. Clair wrote:
correction, I can see this issue with 2.8.2 i386 binaries vs. hand build.
Tim, it is still unclear to me what your problem is and where you are
getting the binaries from.
So, a few questions:
1. Where did the binaries come from (i.e. cmake.org, s
correction, I can see this issue with 2.8.2 i386 binaries vs. hand build.
On Wed, Oct 20, 2010 at 7:40 AM, Tim St. Clair wrote:
> 2.8.0 vs. 2.8.2 hand made
>
> On Tue, Oct 19, 2010 at 4:24 PM, David Cole wrote:
>> What version are these stock i386 binaries you speak of?
>> Where did they come fr
2.8.0 vs. 2.8.2 hand made
On Tue, Oct 19, 2010 at 4:24 PM, David Cole wrote:
> What version are these stock i386 binaries you speak of?
> Where did they come from?
> For 2.8.1 and earlier the problem did not exist.
> For 2.8.2, the problem did exist.
> It should be fixed again in 2.8.3-rc2 and la
On 10/20/2010 09:05 AM, Michael Wild wrote:
>
> On 20. Oct, 2010, at 9:01 , Micha Renner wrote:
>
>> Is there a way to specify a WORKING_DIRECTORY for ADD_TEST, similar
>> ADD_CUSTOM_COMMAND?
>>
>> Greetings
>>
>> Micha
>
>
> No, unfortunately not. You will have to wrap EXECUTE_PROCESS in a CMa
Hi,
CPack, the packaging system that ships with CMake, builds
component-based installers for Mac OS X and Windows only. On Linux, the
packages generated by CPack are single, monolithic units.
I hacked a CMake script that creates a single deb-src package, uploads
it to the Launchpad build service w
2010/10/20 Mohammed Aziz Parande :
> Dear Developers,
>
> I am a graduate student from University of Maryland Baltimore County.
>
> I have a simple question pertaining to Cmake Development Cycle.
>
> Has Cmake gone under some refactoring efforts before any of its release? If
> yes could you please
On Tue, 2010-10-19 at 08:24 -0400, Bill Hoffman wrote:
> On 10/19/2010 4:21 AM, Marcel Loose wrote:
> > Hi all,
> >
> > I stumbled upon IMHO weird behaviour of CTest.
> > It seems that compilation errors are not picked up, somehow. Look at
the
> > output of a run of "ctest -V -D ExperimentalBuild"
On 20. Oct, 2010, at 9:01 , Micha Renner wrote:
> Is there a way to specify a WORKING_DIRECTORY for ADD_TEST, similar
> ADD_CUSTOM_COMMAND?
>
> Greetings
>
> Micha
No, unfortunately not. You will have to wrap EXECUTE_PROCESS in a CMake script
and use that script as the test using "${CMAKE_CO
Is there a way to specify a WORKING_DIRECTORY for ADD_TEST, similar
ADD_CUSTOM_COMMAND?
Greetings
Micha
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep message
26 matches
Mail list logo
