Re: [CMake] cmake qt4 Lplates

[Andreas Pakulat]

On 10.12.10 22:09:29, luxInteg wrote:
> Greetings,
> 
> I   have my cmake L-plates firmly on ( with a Qt4  project I am stumbling on )
> 
> I have these in   CMakeLists.txt file:-
>  FIND_PACKAGE( Qt4 REQUIRED )
>   INCLUDE( ${QT_USE_FILE} )
>   set(QT_USE_OPENGL TRUE)
>   set(QT_USE_QTSVG  TRUE )
>   SET( QT_USE_QTXML TRUE )
>   SET( QT_USE_QT3SUPPORT TRUE )
>   SET( QT_USE_QTNETWORK  TRUE )
>   SET( QT_USE_QTASSISTANT TRUE )
>   SET(QT_USE_QTSCRIPT TRUE)

This is wrong, you should set the use-variables _before_ including
the use-file. Otherwise the qt-include-dir-variable as well as libraries
variable won't contain these modules. Thats the whole point of the
use-module.

> include_directories( ${CMAKE_BINARY_DIR} ${QT_INCLUDE_DIR} )

This should work, but with the wrong order above it might only set
includes for Qt/, QtCore/ and QtGui/ subdirs.

> Two sets pf problems I have encountered include:'
> 
> A:- I cannot set   the includes for Qt4  as 'found' by FindQt4.cmake.  I 
> looked through  the said file for such a variable  under mark_as_advanced()  
> or somesuch but I could not discern any  related functions nor  variable 
> names.  I tried  ${QT_INCLUDE_DIR}, ${QT_HEADERS_DIR} aand ${QT_INCLUDES} to 
> no avail.I had to resort to  setting these manually as 
> /opt/qt4/include/

Did you print out QT_INCLUDE_DIR to check its value or QT_INCLUDES?

> B:- This might be due to the manual setting of   the Qt4_INCLUDE 
> (directory(s), but I seem to get duplication in the preprocessors
> (generated automatically):   Below is an example
> 
> -DQT_NO_DEBUG 
> -DQT_SVG_LIB 
> -DQT_QT3SUPPORT_LIB 
> -DQT3_SUPPORT 
> -DQT_XML_LIB 
> -DQT_OPENGL_LIB 
> -DQT_GUI_LIB 
> -DQT_NETWORK_LIB 
> -DQT_CORE_LIB 
> -DQT_SHARED 
> -DQT_NO_DEBUG 
> -DQT_GUI_LIB 
> -DQT_CORE_LIB 
> -DQT_SHARED
> 
> (REMARK I have  -DQT_SHARED   -DQT_NO_DEBUG   both duplicated) 

Whats the problem with that? And are you setting the defines yourself to
be included (via QT_DEFINITIONS) or is that done by the use-module?

Andreas

-- 
Are you sure the back door is locked?
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] cmake qt4 Lplates

[luxInteg]

Greetings,

I   have my cmake L-plates firmly on ( with a Qt4  project I am stumbling on )

I have these in   CMakeLists.txt file:-
 FIND_PACKAGE( Qt4 REQUIRED )
  INCLUDE( ${QT_USE_FILE} )
  set(QT_USE_OPENGL TRUE)
  set(QT_USE_QTSVG  TRUE )
  SET( QT_USE_QTXML TRUE )
  SET( QT_USE_QT3SUPPORT TRUE )
  SET( QT_USE_QTNETWORK  TRUE )
  SET( QT_USE_QTASSISTANT TRUE )
  SET(QT_USE_QTSCRIPT TRUE)

include_directories( ${CMAKE_BINARY_DIR} ${QT_INCLUDE_DIR} )

Two sets pf problems I have encountered include:'

A:- I cannot set   the includes for Qt4  as 'found' by FindQt4.cmake.  I 
looked through  the said file for such a variable  under mark_as_advanced()  
or somesuch but I could not discern any  related functions nor  variable 
names.  I tried  ${QT_INCLUDE_DIR}, ${QT_HEADERS_DIR} aand ${QT_INCLUDES} to 
no avail.I had to resort to  setting these manually as 
/opt/qt4/include/

B:- This might be due to the manual setting of   the Qt4_INCLUDE 
(directory(s), but I seem to get duplication in the preprocessors
(generated automatically):   Below is an example

-DQT_NO_DEBUG 
-DQT_SVG_LIB 
-DQT_QT3SUPPORT_LIB 
-DQT3_SUPPORT 
-DQT_XML_LIB 
-DQT_OPENGL_LIB 
-DQT_GUI_LIB 
-DQT_NETWORK_LIB 
-DQT_CORE_LIB 
-DQT_SHARED 
-DQT_NO_DEBUG 
-DQT_GUI_LIB 
-DQT_CORE_LIB 
-DQT_SHARED

(REMARK I have  -DQT_SHARED   -DQT_NO_DEBUG   both duplicated) 

advice would be appreciated

luxInteg
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Trying to setup make folder configuration on linux

[Tyler Roscoe]

On Fri, Dec 10, 2010 at 08:11:45PM +0100, Louis Hoefler wrote:
> -- Build files have been written to: /root/massmailer/Debug

Probably not a good idea to be doing this kind of thing as root.

> [100%] Built target massmailer
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /root/massmailer/Release
> [100%] Built target massmailer
> Install the massmailer release now [Yes/n]? Yes
> [100%] Built target massmailer
> Install the project...
> -- Install configuration: "Release"
> CMake Error at massmailer/cmake_install.cmake:36 (FILE):
>   file INSTALL cannot find "/root/massmailer/massmailer/massmailer".
> Call Stack (most recent call first):
>   cmake_install.cmake:37 (INCLUDE)

We'll need to see your CMakeLists.txt to help further, but it's likely
that you got a path wrong in your install() command.

hth,
tyler
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake bug tracker discussion

[Eric Noulard]

2010/12/10 Bill Hoffman :
> There are a few things we have already started to do that should help with
> the bug tracker issue.
>
> 1. We hare having 4 releases of CMake each year.   After each release we
> post to the list and ask people to "vote" for bugs they would like fixed in
> the next release.
>
> 2. We are now sending all new bugs to the cmake-developer list.  This way
> any CMake developer can start working on them or at least know about them
> when the are opened.

This was a very good idea.

I would suggest that each reporter get the follow-up of the bug he posted,
I think (but I have no way to verify that) that bug reporters do not
get automatic
e-mail follow-up for each comment posted to their bug unless they add themselves
as "monitor".

I'm using this default behavior for other opens source project bug
tracker and I usually
get fast answers (including "I have no time/mean to answer") on bug comments.

Knowing that, If a bug reporter does not react to a comment posted on his bug I
would usually tend to stop working on this bug because of the lack of
info and let the bug
close itself after a grace period.

> I have a third idea that we have not yet tried:
>
> What do people think of automatically closing bugs if they are not modified
> for some period of time (say 6 months).   They can always be reopened if the
> closed.   By closing them, it will notify those that have expressed interest
> in the bug.  We could send the closed bugs to the cmake-developer list just
> like the new ones.  That way all developers will know that they are being
> closed.

I would prefer having 2 messages:
One after 6 monthes of inactivity (i.e. no new comments etc...)
   saying the bug will be automatically closed a month later
   unless the situation evolves
A second one closing it if no activity is seen after the "grace period".

Those message should be sent to the monitor list AND the bug reporter.

The first message should be didactic, and may be explain that a bug
is more easily fixed with the involvement of the reporter:
- test case
- patch
etc

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake bug tracker discussion

[Pau Garcia i Quiles]

On Fri, Dec 10, 2010 at 7:56 PM, Alan W. Irwin
 wrote:

>> On the other hand, on KDE, when we moved to KDE4, we closed almost all
>> KDE3-related bugs without checking if they had been fixed. It did not
>> made too much sense to keep bug reports around unless they were
>> feature requests.
>
> That sounds like you would support version-based (as opposed to
> time-based) bug report closing.
>
> To be specific what would you think of a new bugtracker policy to
> close all bugs automatically that were submitted for old versions of
> CMake with the message, "please reopen this bug if it still applies to
> CMake-2."? Such a policy seems reasonable to me (especially if the
> old version cutoff is sufficiently in the past, e.g., close all bugs
> relevant to CMake-2. when the 2. series starts) and avoids the
> implicit bad message to bug reporters of a time-based policy that we
> both dislike so much.

That looks reasonable to me for "plain" bugreports but not for feature
requests or any bugreport which includes a proposed patch

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Trying to setup make folder configuration on linux

[Louis Hoefler]

Hello everyone,
i currently try to setup a make configuration where the debug and the 
release version of my programm should be built into different subfolders.

My problem is that the installation does not find the created executable.
The directory stucture looks like this:
/massmailer
  CmakeLists.txt
  build_script.sh
 cd Release
 cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr ../
 make
 make install
/massmailer/Debug
/massmailer/Release
/massmailer/massmailer
  main.cpp
  CmakeLists.txt

The installation stops with:

-- Configuring done
-- Generating done
-- Build files have been written to: /root/massmailer/Debug
[100%] Built target massmailer
-- Configuring done
-- Generating done
-- Build files have been written to: /root/massmailer/Release
[100%] Built target massmailer
Install the massmailer release now [Yes/n]? Yes
[100%] Built target massmailer
Install the project...
-- Install configuration: "Release"
CMake Error at massmailer/cmake_install.cmake:36 (FILE):
  file INSTALL cannot find "/root/massmailer/massmailer/massmailer".
Call Stack (most recent call first):
  cmake_install.cmake:37 (INCLUDE)


make: *** [install] Error 1

How do I solve this error?

Thank you, Louis

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake bug tracker discussion

[Alan W. Irwin]

On 2010-12-10 17:01+0100 Pau Garcia i Quiles wrote:


On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman  wrote:

I have a third idea that we have not yet tried:

What do people think of automatically closing bugs if they are not modified
for some period of time (say 6 months).   They can always be reopened if the
closed.   By closing them, it will notify those that have expressed interest
in the bug.  We could send the closed bugs to the cmake-developer list just
like the new ones.  That way all developers will know that they are being
closed.


It's a bad idea, IMHO.

If a user took the time to file a bug and CMake developers do nothing
in 6 months, closing it is the wrong thing to do.

The message you are sending to the bugreporter is "I didn't care about
the bug you reported in 6 months, and now I will care even less". For
an example, see what I said yesterday about bug 8707: two years later,
a patch provided, still no action on Kitware's side.


I completely agree.  Time-based automatic bug closing is a bad idea.



On the other hand, on KDE, when we moved to KDE4, we closed almost all
KDE3-related bugs without checking if they had been fixed. It did not
made too much sense to keep bug reports around unless they were
feature requests.


That sounds like you would support version-based (as opposed to
time-based) bug report closing.

To be specific what would you think of a new bugtracker policy to
close all bugs automatically that were submitted for old versions of
CMake with the message, "please reopen this bug if it still applies to
CMake-2."? Such a policy seems reasonable to me (especially if the
old version cutoff is sufficiently in the past, e.g., close all bugs
relevant to CMake-2. when the 2. series starts) and avoids the
implicit bad message to bug reporters of a time-based policy that we
both dislike so much.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.4 release scheduled for next month

[David Cole]

On Thu, Dec 9, 2010 at 3:57 PM, Tyler Roscoe  wrote:
> So are you ready to start collecting candidate bugs for 2.8.4? I
> nominate this one!
>
> http://www.vtk.org/Bug/view.php?id=11561
>
> Thanks,
> tyler
>
> On Thu, Dec 09, 2010 at 03:37:16PM -0500, David Cole wrote:
>> We are still planning to start the release candidate cycle for CMake
>> 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be
>> considered for inclusion in the -rc1 build should be pushed to the
>> stage and merged to 'next' before the nightly start time on the
>> evening of Mon. Jan. 10, 2011.
>
>

This one (11561) is now on the roadmap for 2.8.4.

Thanks,
David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake bug tracker discussion

[Bill Hoffman]

On 12/10/2010 12:48 PM, Thompson, David C wrote:

Mantis lets you customize bug resolution. Maybe a new category of
resolution could be created. Instead of "Won't Fix" it could be
"Lack of Activity"?



It would have to be something that made it clear, that unless someone 
cares enough to re-open it, it is not going to be fixed.  I sort of like 
closed, with a special comment that explains why it is being closed, and 
how to re-open it.


-Bill
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake bug tracker discussion

[Thompson, David C]

Mantis lets you customize bug resolution. Maybe a new category of
resolution could be created. Instead of "Won't Fix" it could be
"Lack of Activity"?

David

From: cmake-boun...@cmake.org [cmake-boun...@cmake.org] On Behalf Of Bill 
Hoffman [bill.hoff...@kitware.com]
Sent: Friday, December 10, 2010 09:31
To: Pau Garcia i Quiles
Cc: cmake@cmake.org
Subject: Re: [CMake] CMake bug tracker discussion

On 12/10/2010 11:01 AM, Pau Garcia i Quiles wrote:
> On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman  
> wrote:
>> I have a third idea that we have not yet tried:
>>
>> What do people think of automatically closing bugs if they are not modified
>> for some period of time (say 6 months).   They can always be reopened if the
>> closed.   By closing them, it will notify those that have expressed interest
>> in the bug.  We could send the closed bugs to the cmake-developer list just
>> like the new ones.  That way all developers will know that they are being
>> closed.
>
> It's a bad idea, IMHO.
>
> If a user took the time to file a bug and CMake developers do nothing
> in 6 months, closing it is the wrong thing to do.
>
> The message you are sending to the bugreporter is "I didn't care about
> the bug you reported in 6 months, and now I will care even less". For
> an example, see what I said yesterday about bug 8707: two years later,
> a patch provided, still no action on Kitware's side.
Right, and by closing that bug after six months with a message like: "If
you are still interested in this issue, please re-open and comment. You
may want to bring this issue up on the CMake mailing list as well."

I am thinking that issues like 8707 would not be forgotten because they
would be re-opened and eventually addressed.  So, by closing the issue,
it would keep the issues from getting stale.

-Bill
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake bug tracker discussion

[Bill Hoffman]

On 12/10/2010 11:01 AM, Pau Garcia i Quiles wrote:

On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman  wrote:

I have a third idea that we have not yet tried:

What do people think of automatically closing bugs if they are not modified
for some period of time (say 6 months).   They can always be reopened if the
closed.   By closing them, it will notify those that have expressed interest
in the bug.  We could send the closed bugs to the cmake-developer list just
like the new ones.  That way all developers will know that they are being
closed.


It's a bad idea, IMHO.

If a user took the time to file a bug and CMake developers do nothing
in 6 months, closing it is the wrong thing to do.

The message you are sending to the bugreporter is "I didn't care about
the bug you reported in 6 months, and now I will care even less". For
an example, see what I said yesterday about bug 8707: two years later,
a patch provided, still no action on Kitware's side.
Right, and by closing that bug after six months with a message like: "If 
you are still interested in this issue, please re-open and comment. You 
may want to bring this issue up on the CMake mailing list as well."


I am thinking that issues like 8707 would not be forgotten because they 
would be re-opened and eventually addressed.  So, by closing the issue, 
it would keep the issues from getting stale.


-Bill
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] ANN: Books available on amazon.co.uk

[Lisa Avila]

Great news for everyone in Europe who would like to purchase the VTK User's
Guide or Mastering CMake - we now have these two titles available on
amazon.co.uk (thanks to our new
officein Lyon, France).
You can get the VTK User's Guide
herefor£69.00
and
Mastering CMake
herefor
£49.00. You can always find these links on our web site under
www.kitware.com - use the menu to navigate to Products -> Books, then select
the book you'd like to order. The amazon.com and amazon.co.uk links are both
listed on the Ordering Information tab. Ordering from amazon.co.uk should
result in significantly lower shipping costs for our European customers. We
do plan to offer more of our titles on more Amazon sites in the EU in this
coming year.

Lisa



---
Lisa S. Avila
Vice President
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065 USA
518-371-3971 x103
lisa.av...@kitware.com
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake bug tracker discussion

[Pau Garcia i Quiles]

On Fri, Dec 10, 2010 at 3:42 PM, Bill Hoffman  wrote:
> I have a third idea that we have not yet tried:
>
> What do people think of automatically closing bugs if they are not modified
> for some period of time (say 6 months).   They can always be reopened if the
> closed.   By closing them, it will notify those that have expressed interest
> in the bug.  We could send the closed bugs to the cmake-developer list just
> like the new ones.  That way all developers will know that they are being
> closed.

It's a bad idea, IMHO.

If a user took the time to file a bug and CMake developers do nothing
in 6 months, closing it is the wrong thing to do.

The message you are sending to the bugreporter is "I didn't care about
the bug you reported in 6 months, and now I will care even less". For
an example, see what I said yesterday about bug 8707: two years later,
a patch provided, still no action on Kitware's side.

On the other hand, on KDE, when we moved to KDE4, we closed almost all
KDE3-related bugs without checking if they had been fixed. It did not
made too much sense to keep bug reports around unless they were
feature requests.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Simultaneous --build-and-test and CDash submission

[David Cole]

On Fri, Dec 10, 2010 at 10:42 AM, Wojciech Migda  wrote:
>>
>> You can do it all in one step with ctest, but you have to write a
>> ctest -S script, and call that... Inside it, you can do a "configure
>> from scratch" using the ctest_configure(...) command. Then you'll see
>> all the configure output submitted to the dashboard.
>>
>> Poke around the wiki and the mailing list for ctest -S script
>> documentation. (Go with a new style script that uses the commands
>> 'ctest_configure' and 'ctest_build' and 'ctest_test'.) Maybe somebody
>> else has time to chime in and give you more details.
>>
>>
>> Cheers,
>> David
>>
>
> Thanks fot hints - I finally managed to make it work using ctest scripting. 
> Basic setup was quite easy, but for a longer while I coudn't find a way to 
> have the BuildName and Site name being set - instead they were void. This 
> resulted in having separate entries being shown in CDash for all three 
> stages: configure, build and test. As suggested by wiki entries I tried 
> playing with setting initial cache but it did not work. After few hours I 
> found out that I need to set variables CTEST_BUILD_NAME and CTEST_SITE in the 
> CTestConfig.cmake file. Once I did that the CDash entries were non-void and 
> the submissions were merged together.
>
> With CTest -S working now I have a system with subprojects, and with labels 
> not assigned as subprojects as well, what by the means of filtering feature 
> gives me a very nice possibility to browse submissions by labels, something I 
> asked about in one of my recent posts.
>
> Thanks,
>
> Wojtek
>
> --
> Szukasz pracy? Możemy Ci ją dać!
> Sprawdź >> http://linkint.pl/f288d
>
>


You should set CTEST_BUILD_NAME and CTEST_SITE directly in your ctest
script for a given machine. They should not be in CTestConfig.cmake
because that file is read on all machines, and only
machine-independent variables should be set in there.

Glad you got it working.


David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Simultaneous --build-and-test and CDash submission

[Wojciech Migda]

> 
> You can do it all in one step with ctest, but you have to write a
> ctest -S script, and call that... Inside it, you can do a "configure
> from scratch" using the ctest_configure(...) command. Then you'll see
> all the configure output submitted to the dashboard.
> 
> Poke around the wiki and the mailing list for ctest -S script
> documentation. (Go with a new style script that uses the commands
> 'ctest_configure' and 'ctest_build' and 'ctest_test'.) Maybe somebody
> else has time to chime in and give you more details.
> 
> 
> Cheers,
> David
> 

Thanks fot hints - I finally managed to make it work using ctest scripting. 
Basic setup was quite easy, but for a longer while I coudn't find a way to have 
the BuildName and Site name being set - instead they were void. This resulted 
in having separate entries being shown in CDash for all three stages: 
configure, build and test. As suggested by wiki entries I tried playing with 
setting initial cache but it did not work. After few hours I found out that I 
need to set variables CTEST_BUILD_NAME and CTEST_SITE in the CTestConfig.cmake 
file. Once I did that the CDash entries were non-void and the submissions were 
merged together.

With CTest -S working now I have a system with subprojects, and with labels not 
assigned as subprojects as well, what by the means of filtering feature gives 
me a very nice possibility to browse submissions by labels, something I asked 
about in one of my recent posts.

Thanks,

Wojtek

--
Szukasz pracy? Możemy Ci ją dać!
Sprawdź >> http://linkint.pl/f288d 

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake bug tracker discussion

[Bill Hoffman]

There are a few things we have already started to do that should help 
with the bug tracker issue.


1. We hare having 4 releases of CMake each year.   After each release we 
post to the list and ask people to "vote" for bugs they would like fixed 
in the next release.


2. We are now sending all new bugs to the cmake-developer list.  This 
way any CMake developer can start working on them or at least know about 
them when the are opened.


I have a third idea that we have not yet tried:

What do people think of automatically closing bugs if they are not 
modified for some period of time (say 6 months).   They can always be 
reopened if the closed.   By closing them, it will notify those that 
have expressed interest in the bug.  We could send the closed bugs to 
the cmake-developer list just like the new ones.  That way all 
developers will know that they are being closed.


-Bill
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] R: CMake 2.8.4 release scheduled for next month

[Bill Hoffman]

On 12/9/2010 5:42 PM, Marco Atzeri wrote:


any hope to solve
http://public.kitware.com/Bug/view.php?id=10122

with the discussed change of policy for cygwin ?



Yes, I have put that on the roadmap.  I hope to have time to create the 
policy before the release. Thanks for the reminder.


-Bill
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Howto let FIND_LIBRARY prefer static over shared libraries

[Brad King]

On 12/10/2010 06:36 AM, Marcel Loose wrote:
> Is there a way to let FIND_LIBRARY prefer static over shared
> libraries?
> I know of one, but that's a bit hack-ish: 
> 
>   SET(CMAKE_FIND_LIBRARY_SUFFIXES .a)
> 
> Are there other options? 
> Ideally, I would like to be able to specify this per library search,
> i.e. as an option to FIND_LIBRARY.

Just ask for the archive name first:

  find_library(MYLIB NAMES libmylib.a mylib)

-Brad
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake 2.8.4 release scheduled for next month

[NoRulez]

This are great news, thank you very much

-Ursprüngliche Nachricht-
Von: David Cole [mailto:david.c...@kitware.com] 
Gesendet: Donnerstag, 09. Dezember 2010 22:10
An: Roman Wüger
Cc: CMake MailingList
Betreff: Re: [CMake] CMake 2.8.4 release scheduled for next month

That one is assigned to Bill Hoffman and he will be looking at it
sometime before Jan. 10.


On Thu, Dec 9, 2010 at 4:04 PM, Roman Wüger  wrote:
> Is the fix for the following bug included:
> http://www.cmake.org/Bug/view.php?id=4068
>
> If not, when would this bug fixed, because a fix is already attached and
the bug is open since 2006-11-23
>
> Thanks in advance
>
> Best Regards
> NoRulez
>
> Am 09.12.2010 um 21:57 schrieb Tyler Roscoe :
>
>> So are you ready to start collecting candidate bugs for 2.8.4? I
>> nominate this one!
>>
>> http://www.vtk.org/Bug/view.php?id=11561
>>
>> Thanks,
>> tyler
>>
>> On Thu, Dec 09, 2010 at 03:37:16PM -0500, David Cole wrote:
>>> We are still planning to start the release candidate cycle for CMake
>>> 2.8.4 on Wed. Jan. 12, 2011. Because of that, all changes to be
>>> considered for inclusion in the -rc1 build should be pushed to the
>>> stage and merged to 'next' before the nightly start time on the
>>> evening of Mon. Jan. 10, 2011.
>>
>> ___
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Howto let FIND_LIBRARY prefer static over shared libraries

[Marcel Loose]

Hi all,

Is there a way to let FIND_LIBRARY prefer static over shared
libraries?
I know of one, but that's a bit hack-ish: 

  SET(CMAKE_FIND_LIBRARY_SUFFIXES .a)

Are there other options? 
Ideally, I would like to be able to specify this per library search,
i.e. as an option to FIND_LIBRARY.

Best regards,
Marcel Loose.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Add custom command problem ?

[Robert Bielik]

Michael Wild skrev 2010-12-10 10:28:


1. Always use absolute paths (e.g. using CMAKE_CURRENT_SOURCE_DIR and
CMAKE_CURRENT_BINARY_DIR).

2. Never create output in the source tree.


Thanks, I'll try that.

/Rob
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Add custom command problem ?

[Michael Wild]

On 12/10/2010 09:23 AM, Robert Bielik wrote:
> Hi all,
> 
> Using 2.8.2 I'm trying to make a rule to create a timestamp header, but
> only if a certain file has changed, like so:
> 
> ADD_CUSTOM_COMMAND(
>   OUTPUT src/timestamp.h
>   COMMAND tools/win32/timestamper
>   ARGS src/timestamp.h
>   DEPENDS Version.cmake
>   WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
>   COMMENT "Generating timestamp header..."
> )
> 
> but the rule is always executed, even if the Version.cmake file has not
> changed. What am I doing wrong ?
> 
> TIA
> /Rob

1. Always use absolute paths (e.g. using CMAKE_CURRENT_SOURCE_DIR and
CMAKE_CURRENT_BINARY_DIR).

2. Never create output in the source tree.

HTH

Michael
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Add custom command problem ?

[Robert Bielik]

Hi all,

Using 2.8.2 I'm trying to make a rule to create a timestamp header, but only if 
a certain file has changed, like so:

ADD_CUSTOM_COMMAND(
  OUTPUT src/timestamp.h
  COMMAND tools/win32/timestamper
  ARGS src/timestamp.h
  DEPENDS Version.cmake
  WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
  COMMENT "Generating timestamp header..."
)

but the rule is always executed, even if the Version.cmake file has not 
changed. What am I doing wrong ?

TIA
/Rob
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake