I could not still build cmake.. But I did this modification
locally you suggested and that is the output:
CPack: Create package using RPM
CPack: Install projects
CPack: - Run preinstall target for: Gluon
CPack: - Install project: Gluon
CPack: Create package
CPackRPM: Will use GENERATED spec fi
Hi guys,
Good news -- the system admins are installing 2.8.4 on all the government Cray
machines!
Bad news -- I can't actually get anything to work. I pulled the git repo
version and built the master branch because of what David pointed out. However,
I cannot figure out how to make it actual
1) What is the hackaround to install the newest version on arm ?
2) What is the final solution ? I think there are severe thread issues
debug output contains almost the same information as the "normal", not
much addition...
Should I open a bugreport instead with critical priority ? Put it
mil
Are you calling ctest_start(Experimental) or ctest_start(Nightly) before
callng ctest_submit...?
On Mon, Mar 7, 2011 at 4:32 PM, Zou, Di (Cont, ARL/CISD) wrote:
> I have been looking at this webpage:
> http://www.kitware.com/products/html/CDashSubprojects.html. I have created
> a Project.xml fi
Hi,
I am starting a separate thread on this "hanging" issue.
-- Forwarded message --
From: Laszlo Papp
Date: 2011/3/8
Subject: Re: [CMake] CPack and RPM packages
To: Eric Noulard
Cc : CMake ML
1st run:
ca
-- The C compiler identification is GNU
-- The CXX compiler identific
2011/3/8 Laszlo Papp :
> On Tue, Mar 8, 2011 at 12:45 AM, Eric Noulard wrote:
>> 2011/3/8 Laszlo Papp :
>>> Well: http://public.kitware.com/Bug/view.php?id=11595
>>> That is fixed in cmake 2.8.4.
>>> Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html
>>> "CPackRPM fix bug 00
1st run:
ca
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compi
On Tue, Mar 8, 2011 at 12:45 AM, Eric Noulard wrote:
> 2011/3/8 Laszlo Papp :
>> Well: http://public.kitware.com/Bug/view.php?id=11595
>> That is fixed in cmake 2.8.4.
>> Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html
>> "CPackRPM fix bug 0011595 : Can't generate RPMs (o
2011/3/8 Laszlo Papp :
> Well: http://public.kitware.com/Bug/view.php?id=11595
> That is fixed in cmake 2.8.4.
> Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html
> "CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...)"
>
> I am trying to build this version now on Me
Well: http://public.kitware.com/Bug/view.php?id=11595
That is fixed in cmake 2.8.4.
Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html
"CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...)"
I am trying to build this version now on MeeGo since the available
binary one
2011/3/7 Laszlo Papp :
> As said, the working OBS spec files can be found here:
> http://repo.pub.meego.com/home:/sandst1/standard/armv7l/
> http://repo.pub.meego.com/home:/sandst1/standard/i586/
Not really, since binary RPMs do not contains the spec file,
but I did find the spec file in src:
http
On Mon, Mar 7, 2011 at 7:03 PM, Alexander Neundorf
wrote:
>
> It's an internal variable.
May we use it? Or is it not intended for users to use it?
--
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com
___
Powered by www.kitware.com
Visit oth
Further news, I have just tried the rpm generation on my host system
out and it worked like a charm, here are the logs:
http://djszapi.homelinux.net/cpack_host.log
http://djszapi.homelinux.net/gluon_host.spec
I hope it helps with something...
Best Regards,
Laszlo Papp
On Mon, Mar 7, 2011 at 9:29
I have been looking at this webpage:
http://www.kitware.com/products/html/CDashSubprojects.html. I have created a
Project.xml file to list my subprojects. Right now I am just trying to use
Project.xml to add subprojects to a dashboard. I am trying to submit the file
to the dashboard like so:
#
I have several compilers setup on my box for various reasons.
I definately know this shows up when building for mingw and using the
wrong command prompt with say visual studio in the path, and gcc not
in the path.
First, I create a new build output directory go into that directory
and run a comma
My first subject line was "Who decided to break FindITK.cmake in
2.8.4?" but that isn't probably very tactful.
We have a whole bunch of projects that used to configure and build
just fine with CMake 2.8.3. With 2.8.4 they fail.
The error message we get is:
CMake Error at /opt/cmake-2.8.4-Darwin-
On Friday 04 March 2011, Campbell Barton wrote:
> On Thu, Mar 3, 2011 at 5:10 PM, Alexander Neundorf
>
> wrote:
> > On Tuesday 01 March 2011, Campbell Barton wrote:
> >> On Tue, Mar 1, 2011 at 2:47 PM, Marcus D. Hanwell
> >>
> >> wrote:
> >> > On Tue, Mar 1, 2011 at 9:15 AM, John Drescher
> >
>
As said, the working OBS spec files can be found here:
http://repo.pub.meego.com/home:/sandst1/standard/armv7l/
http://repo.pub.meego.com/home:/sandst1/standard/i586/
http://djszapi.homelinux.net/gluon.spec -> this is the cpack/cmake
generated one.
Well, the cpack one doesn't really do anything,
On Mon, Mar 7, 2011 at 9:11 PM, Eric Noulard wrote:
> 2011/3/7 Laszlo Papp :
>> Any progress on it ?
>
> Nope.
> I won't be very responsive this week.
That does not sound too good.. !
>> One more information, this n900-devel image uses
>> internally qemu and I am not sure that can ca
2011/3/7 Laszlo Papp :
> Any progress on it ?
Nope.
I won't be very responsive this week.
> One more information, this n900-devel image uses
> internally qemu and I am not sure that can cause any issue for the
> build system.
I don't like I said I'm not that experienced with cross-compiling env.
Hi,
Try putting set(CMAKE_USER_MAKE_RULES_OVERRIDE MyCompilerFlags) before
project() command.
Then, override variable CMAKE_BUILD_TYPE_INIT (with plain unconditional set
command, without putting into cache) in MyCompilerFlags.cmake file (make
sure you put it into location CMake can reach).
Regard
Any progress on it ? One more information, this n900-devel image uses
internally qemu and I am not sure that can cause any issue for the
build system.
That is also interesting why the debian packaging worked just fine in
the scratchbox using also qemu internally.
Best Regards,
Laszlo Papp
On Mon
I looked at the code and the possibility of introducing a policy to
allow the alternate behavior. Looks quite straight forward, so I ask:
What is the policy on adding policies?
Aaron C. Meadows
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Meadows, Aaron C.
On Monday 07 March 2011, Johannes Zarl wrote:
> Hi,
>
> I just wanted to read the documentation on
> "CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT", but discovered
> that the variable is not listed in the cmake docs.
>
> Is there a reason for this?
It's an internal variable.
> Should I open a bugr
On 3/7/2011 1:14 AM, Rolf Eike Beer wrote:
In my solution I have several samples, some of which are windows based
while other are console based.
So I need to be able to change the link flag /SUBSYSTEM:CONSOLE (or
/SUBSYSTEM:WINDOWS) depending on the executable I'm building
Am I missing something
In order to build the project the users have to land on a doku page or
a README.FIRST anyway. There we can give the command instead of
documenting how this behaves with different generators. So I think
this is a good tradeoff.
On Mon, Mar 7, 2011 at 1:06 PM, Michael Hertling wrote:
> On 03/07/201
On 03/07/2011 12:37 PM, Gabriel Petrovay wrote:
> Thanks for the tips, Michael.
>
> We will do so, using project specific BUILD_TYPE and INSTALL_PREFIX.
However, the downside of this approach is that your project's users
should not refer to the well-known CMake variables CMAKE_BUILD_TYPE
and CMAK
Thanks for the tips, Michael.
We will do so, using project specific BUILD_TYPE and INSTALL_PREFIX.
Gabriel
On Mon, Mar 7, 2011 at 12:20 PM, Michael Hertling wrote:
> On 03/07/2011 11:33 AM, Michael Hertling wrote:
>> On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
>>> Hi,
>>>
>>> Is there a wa
On 03/07/2011 11:33 AM, Michael Hertling wrote:
> On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
>> Hi,
>>
>> Is there a way to read the arguments that were passed to CMake from
>> inside a CMakeLists.txt file?
>>
>> There is a problem that some generators (like "NMake Makefiles") set a
>> default
Hi,
I just wanted to read the documentation on
"CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT", but discovered
that the variable is not listed in the cmake docs.
Is there a reason for this? Should I open a bugreport on it?
Cheers,
Johannes
--
Johannes Zarl
Virtual Reality Services
Johannes
On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
> Hi,
>
> Is there a way to read the arguments that were passed to CMake from
> inside a CMakeLists.txt file?
>
> There is a problem that some generators (like "NMake Makefiles") set a
> default value for certain variables (like CMAKE_BUILD_TYPE=Deb
> Usually there are 2 ways: 1) put them into separate directories (like Debug
> and Release), probably specifying different output directories or 2) use
> different file names, say adding suffixes like D, or d8.
> BTW, what's the point to have different configurations in the same workspace
> (do y
32 matches
Mail list logo
