Re: [cmake-developers] [CMake] 2.8.11-rc3 generator expression error

2013-04-29 Thread Stephen Kelly
Stephen Kelly wrote:

 It can probably be refactored to bypass the genex evaluation though.

The refactoring I described can be done in the future I think, but doesn't 
really solve the bug anyway, because it is evaluation of the generator 
expression for the target itself which is causing problems here. 

I've force-pushed the fix-multi-config-tll-include-dirs branch with a more-
simple fix for this issue to my clone.

Thanks,

Steve.

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0014119]: infinite loop compiler chancged: change error message to delete CMakeFiles folder to try fix this

2013-04-29 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=14119 
== 
Reported By:Shimon Doodkin
Assigned To:
== 
Project:CMake
Issue ID:   14119
Category:   (No Category)
Reproducibility:have not tried
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-04-29 07:06 EDT
Last Modified:  2013-04-29 07:06 EDT
== 
Summary:infinite loop compiler chancged: change error
message to delete CMakeFiles folder to try fix this
Description: 
http://www.mail-archive.com/cmake@cmake.org/msg44765.html

http://public.kitware.com/Bug/view.php?id=13756

change the error message:
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:

add to it:
 Delete CMakeFiles folder to try fix this (not CMakeCache.txt)

solution was: After this behavior, you have to manually delete the CMakeFiles
directory (not CMakeCache.txt) to recover.

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-04-29 07:06 Shimon Doodkin New Issue
==

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] Code Changes to support C++ Windows Forms

2013-04-29 Thread john . farrier
I created a topic called WindowsFormsResx following the developer 
guide instructions and have committed my staged changes and a test 
project.  I don't know how to send out a link to this, but would be 
happy to do so if someone pointed me in the right direction.


- John


On 2013-04-28 20:46, Jean-Christophe Fillion-Robin wrote:

Hi John, 

Seems you forgot to send a link to the associated topic.

Jc

On Sun, Apr 28, 2013 at 10:20 PM, 
john.farr...@helleboreconsulting.com wrote:



Hello all!  New CMake developer here!

I have modified the latest version of CMake from Git to be able to 
use .resx files and integrate them into Visual Studio, perform the 
correct associations, and enable use of the Visual Studio designer for 
Windows Forms applications after a solution and projects are 
configured by CMake.  The changes were fairly minimal, but really help 
me out!  I have a project that is mostly cross-platform, but there are 
a few plugins that are windows-specific.  I wanted to use CMake to 
build and manage the project, but when CMake configured the windows 
GUI's, I would lose all of the designer information, which is totally 
unacceptable for ever having to make a change to the GUI.  This change 
is targeted specifically at C++ Windows Forms applications using CLI. 
 I'd like to push these changes up, so feedback is welcome!


- John Farrier

--

Powered by www.kitware.com [1]

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


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


Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers 
[4]


--
+1 919 869 8849


Links:
--
[1] http://www.kitware.com
[2] http://www.kitware.com/opensource/opensource.html
[3] http://www.cmake.org/Wiki/CMake_FAQ
[4] 
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] 2.8.11-rc3 generator expression error

2013-04-29 Thread Brad King
On 04/29/2013 06:29 AM, Stephen Kelly wrote:
 I've force-pushed the fix-multi-config-tll-include-dirs branch with a more-
 simple fix for this issue to my clone.

Okay, that looks good.  Please rebase on the partial fix I merged last
week so we can test it in 'next'.  I'll squash all that together later.

Also I realized my local topic using GetLinkInformation is wrong because
it includes usage requirements from everything linked, not just from
the link *interface* closure.  I'll drop that one in favor of yours.

While working through all of the above I realized that AppendTllIncludes
and LinkInterfaceIncludeDirectoriesEntries are not safe.  Users can
re-write the LINK_LIBRARIES property and those other structures will
not be updated.  IIUC they only exist to provide a backtrace for
include directory entries.  Please drop them for now at the expense of
the backtraces which can be restored later by tracking the backtraces
of all tll() link information (similar to tid() now).

Thanks,
-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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] Code Changes to support C++ Windows Forms

2013-04-29 Thread Jean-Christophe Fillion-Robin
Hi John,

Seems your topic isn't available on the CMake stage:
http://cmake.org/gitweb?p=stage/cmake.git

I would suggest you push your topic on github instead. The stage is used by
module maintainer or CMake core developers [1]

Hth
Jc

[1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer


On Mon, Apr 29, 2013 at 8:36 AM, john.farr...@helleboreconsulting.comwrote:

 I created a topic called WindowsFormsResx following the developer guide
 instructions and have committed my staged changes and a test project.  I
 don't know how to send out a link to this, but would be happy to do so if
 someone pointed me in the right direction.

 - John



 On 2013-04-28 20:46, Jean-Christophe Fillion-Robin wrote:

 Hi John,

 Seems you forgot to send a link to the associated topic.

 Jc

 On Sun, Apr 28, 2013 at 10:20 PM, 
 john.farrier@**helleboreconsulting.comjohn.farr...@helleboreconsulting.com
 wrote:

  Hello all!  New CMake developer here!

 I have modified the latest version of CMake from Git to be able to use
 .resx files and integrate them into Visual Studio, perform the correct
 associations, and enable use of the Visual Studio designer for Windows
 Forms applications after a solution and projects are configured by CMake.
  The changes were fairly minimal, but really help me out!  I have a project
 that is mostly cross-platform, but there are a few plugins that are
 windows-specific.  I wanted to use CMake to build and manage the project,
 but when CMake configured the windows GUI's, I would lose all of the
 designer information, which is totally unacceptable for ever having to make
 a change to the GUI.  This change is targeted specifically at C++ Windows
 Forms applications using CLI.  I'd like to push these changes up, so
 feedback is welcome!

 - John Farrier

 --

 Powered by www.kitware.com [1]

 Visit other Kitware open-source projects at http://www.kitware.com/**
 opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html[2]

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


 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers[4]


 --
 +1 919 869 8849


 Links:
 --
 [1] http://www.kitware.com
 [2] 
 http://www.kitware.com/**opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html
 [3] 
 http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
 [4] http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**
 developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Code Changes to support C++ Windows Forms

2013-04-29 Thread john . farrier
Done and Pull Request sent.  Visual Studio C++ Windows Forms Designer 
Support


Thanks.  I look forward to helping this get into the CMake baseline!

- John



On 2013-04-29 08:08, Jean-Christophe Fillion-Robin wrote:

Hi John, 

Seems your topic isn't available on the CMake
stage: http://cmake.org/gitweb?p=stage/cmake.git [6]

 I would suggest you push your topic on github instead. The stage is
used by module maintainer or CMake core developers [1]

Hth
Jc

 [1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer 
[7]


On Mon, Apr 29, 2013 at 8:36 AM, 
john.farr...@helleboreconsulting.com wrote:


I created a topic called WindowsFormsResx following the developer 
guide instructions and have committed my staged changes and a test 
project.  I don't know how to send out a link to this, but would be 
happy to do so if someone pointed me in the right direction.


- John

On 2013-04-28 20:46, Jean-Christophe Fillion-Robin wrote:


Hi John, 

Seems you forgot to send a link to the associated topic.

Jc

On Sun, Apr 28, 2013 at 10:20 PM, 
john.farr...@helleboreconsulting.com wrote:



Hello all!  New CMake developer here!

I have modified the latest version of CMake from Git to be able to 
use .resx files and integrate them into Visual Studio, perform the 
correct associations, and enable use of the Visual Studio designer 
for Windows Forms applications after a solution and projects are 
configured by CMake.  The changes were fairly minimal, but really 
help me out!  I have a project that is mostly cross-platform, but 
there are a few plugins that are windows-specific.  I wanted to use 
CMake to build and manage the project, but when CMake configured the 
windows GUI's, I would lose all of the designer information, which 
is totally unacceptable for ever having to make a change to the GUI. 
 This change is targeted specifically at C++ Windows Forms 
applications using CLI.  I'd like to push these changes up, so 
feedback is welcome!


- John Farrier

--

Powered by www.kitware.com [1] [1]

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


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


Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers 
[4] [4]


--
+1 919 869 8849 [5]

Links:
--
[1] http://www.kitware.com [1]
[2] http://www.kitware.com/opensource/opensource.html [2]
[3] http://www.cmake.org/Wiki/CMake_FAQ [3]
[4] 
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers 
[4]


--
+1 919 869 8849


Links:
--
[1] http://www.kitware.com
[2] http://www.kitware.com/opensource/opensource.html
[3] http://www.cmake.org/Wiki/CMake_FAQ
[4] 
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[5] tel:%2B1%20919%20869%208849
[6] http://cmake.org/gitweb?p=stage/cmake.git
[7] http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Please review CXXFeatures.cmake

2013-04-29 Thread Alexander Neundorf
On Sunday 28 April 2013, Rolf Eike Beer wrote:
 One question I see increasingly often is how do I test for C++11 support
 or for specific parts of that. For 2.8.12 I plan to include the check
 module I wrote for that a while back, and that I have reworked in the last
 weeks. You can find the current state in the rework branch of this
 repository:
 
 git://anongit.kde.org/scratch/dakon/cmake-cxx11

Line 75: if (CROSS_COMPILING)

Do you mean if(CMAKE_CROSSCOMPILING) ?

Is the try_run() in all cases necessary ?
It would be better if a try_compile() would suffice, that's faster and then it 
works the same way when cross-compiling and when not.


Line 139:
if (NOT CXXFEATURES_FIND_COMPONENTS)
set(CXXFEATURES_FIND_COMPONENTS ${_CXX_ALL_FEATURES})
endif ()

foreach (_cxx_feature IN LISTS _CXX_ALL_FEATURES)
cxx_check_feature(${_cxx_feature} ${FEATURE_NAME})
endforeach (_cxx_feature)


Is this how it is supposed to be or should the foreach() loop run over 
CXXFEATURES_FIND_COMPONENTS ?


I didn't try, but it seems it can fail if I give an unknown component. Is 
there a check that only known components (CXX features) are requested ?


Alex
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] RFC: pretty/HTML output in test logs in ctest/cdash

2013-04-29 Thread Alexander Neundorf
On Thursday 18 April 2013, Alexander Neundorf wrote:
 Hi,
 
 attached are two patches for ctest and cdash from Volkan (on CC).
 They are not ready for inclusion, but before we continue to work in this,
 we'd like to get some comments whether this is a good idea, the right
 approach, etc.
 So, here we go.
 
 We are using cdash a lot, and for many of our tests the log is quite
 verbose and somewhat hard to read. When looking for the reason why a test
 failed, it can be somewhat hard to find the line which contains ERROR.
 Also, a lot of stuff is repeated every line, which also makes the log
 harder to read, e.g. the directory part of the file where the log came
 from:
 
 timestamp /some/where/deep/in/a/subdir/test.py: Something...
 timestamp /some/where/deep/in/a/subdir/test.py: happend...
 timestamp /some/where/deep/in/a/subdir/test.py: here...
 timestamp /some/where/deep/in/a/subdir/test.py: ...
 
 The directory part is actually so wide that we have to scroll to see actual
 text.
 
 
 So, to help with this, we came up with the idea to use HTML to format the
 log so that it becomes easier to read.
 
 The attached patch for ctest adds a new test property GENERATE_HTML, and if
 this is enabled, ctest generates HTML. It searches the lines which made the
 test fail and colors them red, and the lines which make a test pass are
 colored green.
 This makes it easier to find the fail/succeed lines.
 
 (In the patch the fail strings are still hardcoded, this would have to use
 the respective test property.)
 
 On the cdash side, if /span is found in the log, it is considered HTML
 and not escaped. I guess this should be done in a different way, which
 does not involve parsing the log text.
 
 Comments so far ?
 
 
 For making our log lines shorter, we are not sure yet how to do that.
 We could add support for squish XML to ctest, so that ctest reads the
 squish XML and converts it to HTML which is in some way shorter, maybe a
 HTML table, or something.
 Or we could add a test property with a regular expression, if that regexp
 matches, ctest replaces it with a shorter version or something.
 Or we could modify our test scripts so that they already generate the
 pretty HTML, which ctest then simply sends to cdash.
 That's the ideas we have so far, but it doesn't feel quite right yet.
 
 So, what do you think ?

Any comments ?

Alex
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] ADDITIONAL_MAKE_CLEAN_FILES only works in Makefile generators / automoc cleaning problem

2013-04-29 Thread Alexander Neundorf
Hi,

in automoc, for every target foo a foo_automoc target is created, and for each 
of those a file foo_automoc.cpp is created.
When this file does not exist, automoc reruns and all moc files should be 
regenerated.
To achieve this, I added this file in cmQtAutomoc.cxx to the 
ADDITIONAL_MAKE_CLEAN_FILES property, so it is removed on make clean.

Now after some emails on the cmake list, it seems ADDITIONAL_MAKE_CLEAN_FILES 
is used only by the Makefile-generators, but not by e.g. the VS generators ?

The target is created using cmMakefile::AddUtilityCommand(). What would be the 
recommended way to add a generated file, so that it is removed when cleaning ?
Do I need to create a cmSourceFile and set it to GENERATED ?

Alex
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] ADDITIONAL_MAKE_CLEAN_FILES only works in Makefile generators / automoc cleaning problem

2013-04-29 Thread Brad King
On 04/29/2013 03:05 PM, Alexander Neundorf wrote:
 Now after some emails on the cmake list, it seems ADDITIONAL_MAKE_CLEAN_FILES 
 is used only by the Makefile-generators, but not by e.g. the VS generators ?

VS does its own cleaning of the build outputs it knows.

 The target is created using cmMakefile::AddUtilityCommand(). What would be 
 the 
 recommended way to add a generated file, so that it is removed when cleaning ?
 Do I need to create a cmSourceFile and set it to GENERATED ?

VS needs to know that the file is the output of a custom command.
In order for CMake to tell VS about this, the file needs to be
listed as an OUTPUT in add_custom_command.

-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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] Please review CXXFeatures.cmake

2013-04-29 Thread Rolf Eike Beer
Alexander Neundorf wrote:
 On Sunday 28 April 2013, Rolf Eike Beer wrote:
  One question I see increasingly often is how do I test for C++11 support
  or for specific parts of that. For 2.8.12 I plan to include the check
  module I wrote for that a while back, and that I have reworked in the last
  weeks. You can find the current state in the rework branch of this
  repository:
  
  git://anongit.kde.org/scratch/dakon/cmake-cxx11

 Is the try_run() in all cases necessary ?
 It would be better if a try_compile() would suffice, that's faster and then
 it works the same way when cross-compiling and when not.

I'm not sure about this, but the other ones I consider real bugs. Thanks for 
catching them, will fix soon.

Eike
-- 

signature.asc
Description: This is a digitally signed message part.
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Please review CXXFeatures.cmake

2013-04-29 Thread Alexander Neundorf
On Monday 29 April 2013, Rolf Eike Beer wrote:
 Alexander Neundorf wrote:
  On Sunday 28 April 2013, Rolf Eike Beer wrote:
   One question I see increasingly often is how do I test for C++11
   support or for specific parts of that. For 2.8.12 I plan to include
   the check module I wrote for that a while back, and that I have
   reworked in the last weeks. You can find the current state in the
   rework branch of this repository:
   
   git://anongit.kde.org/scratch/dakon/cmake-cxx11
  
  Is the try_run() in all cases necessary ?
  It would be better if a try_compile() would suffice, that's faster and
  then it works the same way when cross-compiling and when not.
 
 I'm not sure about this, but the other ones I consider real bugs. Thanks
 for catching them, will fix soon.

Or IOW: if possible at all, try really hard to get away with only 
try_compile(), i.e. avoid try_run().

Alex
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0014121]: Custom command errors are hidden when CTest launchers are used with Ninja

2013-04-29 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14121 
== 
Reported By:Nils Gladitz
Assigned To:
== 
Project:CMake
Issue ID:   14121
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-04-29 16:51 EDT
Last Modified:  2013-04-29 16:51 EDT
== 
Summary:Custom command errors are hidden when CTest
launchers are used with Ninja
Description: 
I couldn't get any build errors from custom commands on my CDash dashboard when
using Ninja with CTest launchers.

Neither are there errors from custom commands with failure exit status nor from
those with output matched by CTEST_CUSTOM_ERROR_MATCH.

Steps to Reproduce: 
I've set up a test project for which I tested make and ninja with and without
launchers.

CTEST_CUSTOM_ERROR_MATCH is set to FooBar.

The project contains three custom commands with the following outputs and exit
codes:

CustomCommand1: this is a FooBar message (exit success)
CustomCommand2: this is a fatal error (exit failure)
CustomCommand3: this is a FooBar fatal error (exit failure)

These are the results that I got (numbers in braces indicate which custom
commands produce output visible on CDash):

Ninja (Launchers enabled): 0 Build Errors
Ninja (Launchers disabled): 4 Build Errors (1, 2, 3)

Unix Makefiles (Launchers enabled): 2 Build Errors (2, 3)
Unix Makefiles (Launchers disabled): 4 Build Errors (1, 2, 3)

CTEST_CUSTOM_ERROR_MATCH seems to only work with launchers disabled with
Makefiles as well so I assume this is by design (though unexpected).

At the very least the exit status in the Ninja + Launchers case should be
evaluated as it is with Makefiles.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-04-29 16:51 Nils Gladitz   New Issue
==

--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] ADDITIONAL_MAKE_CLEAN_FILES only works in Makefile generators / automoc cleaning problem

2013-04-29 Thread Alexander Neundorf
On Monday 29 April 2013, Brad King wrote:
 On 04/29/2013 03:05 PM, Alexander Neundorf wrote:
  Now after some emails on the cmake list, it seems
  ADDITIONAL_MAKE_CLEAN_FILES is used only by the Makefile-generators, but
  not by e.g. the VS generators ?
 
 VS does its own cleaning of the build outputs it knows.
 
  The target is created using cmMakefile::AddUtilityCommand(). What would
  be the recommended way to add a generated file, so that it is removed
  when cleaning ? Do I need to create a cmSourceFile and set it to
  GENERATED ?
 
 VS needs to know that the file is the output of a custom command.
 In order for CMake to tell VS about this, the file needs to be
 listed as an OUTPUT in add_custom_command.

This is now in the AutomocFixCleaningHandling branch.
It would be nice if you could have a look at it.

Thanks
Alex
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[CMake] Intel compiler with Visual Studio

2013-04-29 Thread Wilkinson, John (Software)
Hello, we want to use the Visual Studio IDE with the Intel C++ compiler. The 
Intel compiler integrates neatly with the IDE, you right click on a project or 
solution and select use Intel C++ or use Visual C++ to switch between 
compilers. I have added the following option to our CMake file:

option( INTEL_COMPILER Use the Intel compiler. ON )

Currently I use this flag to decide which set of boost libraries to link to. I 
also want to use this flag to tell the IDE which compiler to use however I 
cannot find a way to do this. It is not nice to have to remember to manually 
switch to the Intel compiler after running CMake, especially as this does a 
clean of your solution. Does anyone know please a way to get CMake to tell 
Visual Studio which complier to use?

Note when you select the Intel complier for a particular project in the IDE a 
PlatformToolsetIntel C++ Compiler XE 13.0/PlatformToolset get added to 
the PropertyGroup sections of the project's .vcxproj file.

Thank you,
John W

E-mail confidentiality.

This e-mail contains confidential and / or privileged information belonging to 
Spirent Communications plc, its affiliates and / or subsidiaries. If you are 
not the intended recipient, you are hereby notified that any disclosure, 
copying, distribution and / or the taking of any action based upon reliance on 
the contents of this transmission is strictly forbidden. If you have received 
this message in error please notify the sender by return e-mail and delete it 
from your system.

Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677

Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, 
United Kingdom.

Or if within the US,

Spirent Communications,
26750 Agoura Road, Calabasas, CA, 91302, USA.
Tel No. 1-818-676- 2300
--

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] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned

2013-04-29 Thread Glenn Coombs
I added these lines:

set_directory_properties(
PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
${CMAKE_CURRENT_BINARY_DIR}/abc.txt
)

# check the location where abc.txt is supposed to be deleted from
message(CURRENT_BINARY_DIR: ${CMAKE_CURRENT_BINARY_DIR})

to the end of my CMakeLists.txt and then created abc.txt in the cmake build
directory.  I can confirm that the abc.txt file was not deleted by a clean
solution.  I tried this with Visual Studio 2012 and Visual Studio 2008
(both installs are the Express editions) and the results were identical.

--
Glenn


On 28 April 2013 11:53, Alexander Neundorf a.neundorf-w...@gmx.net wrote:

 On Sunday 28 April 2013, Glenn Coombs wrote:
  No, cleaning the project didn't remove that file.

 Can you manually set the ADDITIONAL_MAKE_CLEAN_FILES directory property to
 some file and check whether this file is deleted when you clean ?

 Something like

 set_directory_properties(PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
 ${CMAKE_CURRENT_BINARY_DIR}/abc.txt )


 then just create such a file in the build dir, and clean.
 It should be removed then.
 If it is not, then this is the reason why clean doesn't clean automoc
 properly.

 Alex

--

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] FindCUDA fails to find libcuda.so

2013-04-29 Thread Marcel Loose

Hi all,

I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two 
different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager 
v5.2. I can persuade FindCUDA.cmake to search for this library by 
explicitly setting the environment variable CUDA_LIB_PATH, and then it 
finds it. However, IMHO, using this trick should only be necessary as a 
last resort. Is this a bug?


Best regards,
Marcel Loose.




attachment: loose.vcf--

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] FindCUDA fails to find libcuda.so

2013-04-29 Thread Robert Maynard
Can you provide what Cuda version FindCuda is failing to find, and
where Cluster Manager is installing the CUDA toolkit and library?

On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote:
 Hi all,

 I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two
 different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager v5.2.
 I can persuade FindCUDA.cmake to search for this library by explicitly
 setting the environment variable CUDA_LIB_PATH, and then it finds it.
 However, IMHO, using this trick should only be necessary as a last resort.
 Is this a bug?

 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
--

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] FindCUDA fails to find libcuda.so

2013-04-29 Thread Marcel Loose

Hi,

It fails to find CUDA 5.0. See below.

$ env | grep CUDA
CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35
CUDA_CACHE_DISABLE=1
CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_ROOT=/cm/local/apps/cuda50/libs/304.54

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(CheckCUDALibs)
find_package(CUDA)
message(STATUS CUDA_LIBRARIES = ${CUDA_LIBRARIES})

$ cmake ..
-- 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 compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found CUDA: /cm/shared/apps/cuda50/toolkit/5.0.35 (found version 5.0)
-- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/loose/temp/cmake/cuda/build

$ CUDA_LIB_PATH=$CUDA_ROOT/lib cmake ..
-- CUDA_LIBRARIES = 
/cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so;/cm/local/apps/cuda50/libs/304.54/lib64/libcuda.so

-- Configuring done
-- Generating done
-- Build files have been written to: /home/loose/temp/cmake/cuda/build

Only when explicitly setting CUDA_LIB_PATH, libcuda.so is found.

BTW: On Ubuntu I also need to set CUDA_LIB_PATH, but then to 
/usr/lib/nvidia-current.


Regards,
Marcel Loose.


On 29/04/13 15:36, Robert Maynard wrote:

Can you provide what Cuda version FindCuda is failing to find, and
where Cluster Manager is installing the CUDA toolkit and library?

On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote:

Hi all,

I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two
different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager v5.2.
I can persuade FindCUDA.cmake to search for this library by explicitly
setting the environment variable CUDA_LIB_PATH, and then it finds it.
However, IMHO, using this trick should only be necessary as a last resort.
Is this a bug?

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


attachment: loose.vcf--

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] Problem with get_filename_component() and CMAKE_CXX_COMPILER when finding Qt4

2013-04-29 Thread Petr Kmoch
Any idea on this? Or should I file a bug report?


On Mon, Apr 22, 2013 at 3:15 PM, Petr Kmoch petr.km...@gmail.com wrote:

 If you look at the trace, you'll see the following few lines before the
 error:

 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/FindQt4.cmake(738):
 set(CMAKE_REQUIRED_INCLUDES_SAVE ${CMAKE_REQUIRED_INCLUDES} )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/FindQt4.cmake(739):
 set(CMAKE_REQUIRED_FLAGS_SAVE ${CMAKE_REQUIRED_FLAGS} )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/FindQt4.cmake(741):
 set(CMAKE_REQUIRED_INCLUDES ${CMAKE_REQUIRED_INCLUDES};${QT_INCLUDE_DIR} )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/FindQt4.cmake(743):
 CHECK_CXX_SYMBOL_EXISTS(Q_WS_X11 QtCore/qglobal.h Q_WS_X11 )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckCXXSymbolExists.cmake(41):
 _CHECK_SYMBOL_EXISTS(${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/CheckSymbolExists.cxx
 Q_WS_X11 QtCore/qglobal.h Q_WS_X11 )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(46):  if(Q_WS_X11
 MATCHES ^Q_WS_X11$ )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(47):
 set(CMAKE_CONFIGURABLE_FILE_CONTENT /* */\n )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(48):
 set(MACRO_CHECK_SYMBOL_EXISTS_FLAGS ${CMAKE_REQUIRED_FLAGS} )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(49):
 if(CMAKE_REQUIRED_LIBRARIES )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(54):  else()
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(55):
 set(CHECK_SYMBOL_EXISTS_LIBS )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(57):
 if(CMAKE_REQUIRED_INCLUDES )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(58):
 set(CMAKE_SYMBOL_EXISTS_INCLUDES
 -DINCLUDE_DIRECTORIES:STRING=${CMAKE_REQUIRED_INCLUDES} )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(63):  foreach(FILE
 QtCore/qglobal.h )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(64):
 set(CMAKE_CONFIGURABLE_FILE_CONTENT
 ${CMAKE_CONFIGURABLE_FILE_CONTENT}#include ${FILE}\n )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(67):
 set(CMAKE_CONFIGURABLE_FILE_CONTENT ${CMAKE_CONFIGURABLE_FILE_CONTENT}\nint
 main(int argc, char** argv)\n{\n  (void)argv;\n#ifndef Q_WS_X11\n  return
 ((int*)(Q_WS_X11))[argc];\n#else\n  (void)argc;\n  return 0;\n#endif\n}\n )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(70):
 configure_file(${CMAKE_ROOT}/Modules/CMakeConfigurableFile.in
 D:/Tmp/cmake/bld/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx @ONLY IMMEDIATE )
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(73):  message(STATUS
 Looking for Q_WS_X11 )
 -- Looking for Q_WS_X11
 C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CheckSymbolExists.cmake(74):
 try_compile(Q_WS_X11 ${CMAKE_BINARY_DIR}
 D:/Tmp/cmake/bld/CMakeFiles/CMakeTmp/CheckSymbolExists.cxx
 COMPILE_DEFINITIONS ${CMAKE_REQUIRED_DEFINITIONS} CMAKE_FLAGS
 -DCOMPILE_DEFINITIONS:STRING=${MACRO_CHECK_SYMBOL_EXISTS_FLAGS}
 ${CHECK_SYMBOL_EXISTS_LIBS} ${CMAKE_SYMBOL_EXISTS_INCLUDES} OUTPUT_VARIABLE
 OUTPUT )

 CMake Error at C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/CMakeCXXInformation.cmake:37
 (get_filename_component):
   get_filename_component called with incorrect number of arguments
 Call Stack (most recent call first):
   CMakeLists.txt:2 (PROJECT)




 On Mon, Apr 22, 2013 at 3:05 PM, Rolf Eike Beer e...@sf-mail.de wrote:

 Am 22.04.2013 14:26, schrieb Petr Kmoch:

  Hi all.

 I'm using CMake 2.8.10.2 to do a Visual Studio 2010 64-bit build, and I
 encountered a weird problem with the CMake configure step failing, with
 the
 following output:

 CMake Error at C:/Program Files (x86)/CMake
 2.8/share/cmake-2.8/Modules/**CMakeCXXInformation.cmake:37
 (get_filename_component):
   get_filename_component called with incorrect number of arguments
 Call Stack (most recent call first):
   CMakeLists.txt:2 (PROJECT)


 CMAKE_CXX_COMPILER is empty at that point.


  I managed to pinpoint this to an issue with try_compile in FindQt4. I am
 attaching a minimal test case as well as output of cmake --trace. The
 CMakeList is just this:


 I don't see a try_compile in FindQt4.

 Eike

 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 

Re: [CMake] Cannot restore timestamp error on Windows

2013-04-29 Thread Raffi Enficiaud
Hi,

I read the content of the change in the link you provided, and I have a
newbie question: 
Why not using one timestamp (different filename) per library/binary/project
? 

Looking forward to having this issue solved in the next official release!

Best,
Raffi Enficiaud



--
View this message in context: 
http://cmake.3232098.n2.nabble.com/Cannot-restore-timestamp-error-on-Windows-tp7584120p7584273.html
Sent from the CMake mailing list archive at Nabble.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] FindCUDA fails to find libcuda.so

2013-04-29 Thread Robert Maynard
You have a nonstandard install path that will require you to use
CUDA_PATH / CUDA_BIN_PATH and CUDA_LIB_PATH.

On Mon, Apr 29, 2013 at 10:10 AM, Marcel Loose lo...@astron.nl wrote:
 Hi,

 It fails to find CUDA 5.0. See below.

 $ env | grep CUDA
 CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
 CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
 CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35
 CUDA_CACHE_DISABLE=1
 CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
 CUDA_ROOT=/cm/local/apps/cuda50/libs/304.54

 $ cat ../CMakeLists.txt
 cmake_minimum_required(VERSION 2.8)
 project(CheckCUDALibs)
 find_package(CUDA)
 message(STATUS CUDA_LIBRARIES = ${CUDA_LIBRARIES})

 $ cmake ..
 -- 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 compiler: /usr/bin/c++
 -- Check for working CXX compiler: /usr/bin/c++ -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 -- Found CUDA: /cm/shared/apps/cuda50/toolkit/5.0.35 (found version 5.0)
 -- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so
 -- Configuring done
 -- Generating done
 -- Build files have been written to: /home/loose/temp/cmake/cuda/build

 $ CUDA_LIB_PATH=$CUDA_ROOT/lib cmake ..
 -- CUDA_LIBRARIES =
 /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so;/cm/local/apps/cuda50/libs/304.54/lib64/libcuda.so
 -- Configuring done
 -- Generating done
 -- Build files have been written to: /home/loose/temp/cmake/cuda/build

 Only when explicitly setting CUDA_LIB_PATH, libcuda.so is found.

 BTW: On Ubuntu I also need to set CUDA_LIB_PATH, but then to
 /usr/lib/nvidia-current.

 Regards,
 Marcel Loose.



 On 29/04/13 15:36, Robert Maynard wrote:

 Can you provide what Cuda version FindCuda is failing to find, and
 where Cluster Manager is installing the CUDA toolkit and library?

 On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote:

 Hi all,

 I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two
 different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager
 v5.2.
 I can persuade FindCUDA.cmake to search for this library by explicitly
 setting the environment variable CUDA_LIB_PATH, and then it finds it.
 However, IMHO, using this trick should only be necessary as a last
 resort.
 Is this a bug?

 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


--

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] FindCUDA fails to find libcuda.so

2013-04-29 Thread Marcel Loose

Hi Robert,

I agree that on the CentOS machine the install paths are non-standard. 
For the Ubuntu system, on the other hand, I have to disagree with that 
statement. It is a *standard* Ubuntu 12.10 system, so IMHO 
FindCUDA.cmake should be able to locate libcuda.so on that system.


Regards,
Marcel Loose.

On 29/04/13 16:54, Robert Maynard wrote:

You have a nonstandard install path that will require you to use
CUDA_PATH / CUDA_BIN_PATH and CUDA_LIB_PATH.

On Mon, Apr 29, 2013 at 10:10 AM, Marcel Loose lo...@astron.nl wrote:

Hi,

It fails to find CUDA 5.0. See below.

$ env | grep CUDA
CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35
CUDA_CACHE_DISABLE=1
CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
CUDA_ROOT=/cm/local/apps/cuda50/libs/304.54

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(CheckCUDALibs)
find_package(CUDA)
message(STATUS CUDA_LIBRARIES = ${CUDA_LIBRARIES})

$ cmake ..
-- 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 compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found CUDA: /cm/shared/apps/cuda50/toolkit/5.0.35 (found version 5.0)
-- CUDA_LIBRARIES = /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/loose/temp/cmake/cuda/build

$ CUDA_LIB_PATH=$CUDA_ROOT/lib cmake ..
-- CUDA_LIBRARIES =
/cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so;/cm/local/apps/cuda50/libs/304.54/lib64/libcuda.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/loose/temp/cmake/cuda/build

Only when explicitly setting CUDA_LIB_PATH, libcuda.so is found.

BTW: On Ubuntu I also need to set CUDA_LIB_PATH, but then to
/usr/lib/nvidia-current.

Regards,
Marcel Loose.



On 29/04/13 15:36, Robert Maynard wrote:

Can you provide what Cuda version FindCuda is failing to find, and
where Cluster Manager is installing the CUDA toolkit and library?

On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote:

Hi all,

I noticed that FindCUDA.cmake fails to locate libcuda.so on at least two
different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager
v5.2.
I can persuade FindCUDA.cmake to search for this library by explicitly
setting the environment variable CUDA_LIB_PATH, and then it finds it.
However, IMHO, using this trick should only be necessary as a last
resort.
Is this a bug?

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




attachment: loose.vcf--

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] FindCUDA fails to find libcuda.so

2013-04-29 Thread Robert Maynard
I have had no problem with Ubuntu 12.10 and Cuda 5; findCuda is able
to find cuda in /usr/lib.  Can you run CMake --debug-output output
enable and see where findCuda is searching?

On Mon, Apr 29, 2013 at 11:52 AM, Marcel Loose lo...@astron.nl wrote:
 Hi Robert,

 I agree that on the CentOS machine the install paths are non-standard. For
 the Ubuntu system, on the other hand, I have to disagree with that
 statement. It is a *standard* Ubuntu 12.10 system, so IMHO FindCUDA.cmake
 should be able to locate libcuda.so on that system.

 Regards,
 Marcel Loose.


 On 29/04/13 16:54, Robert Maynard wrote:

 You have a nonstandard install path that will require you to use
 CUDA_PATH / CUDA_BIN_PATH and CUDA_LIB_PATH.

 On Mon, Apr 29, 2013 at 10:10 AM, Marcel Loose lo...@astron.nl wrote:

 Hi,

 It fails to find CUDA 5.0. See below.

 $ env | grep CUDA
 CUDA_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
 CUDA_INC_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
 CUDA_SDK=/cm/shared/apps/cuda50/sdk/5.0.35
 CUDA_CACHE_DISABLE=1
 CUDA_INSTALL_PATH=/cm/shared/apps/cuda50/toolkit/5.0.35
 CUDA_ROOT=/cm/local/apps/cuda50/libs/304.54

 $ cat ../CMakeLists.txt
 cmake_minimum_required(VERSION 2.8)
 project(CheckCUDALibs)
 find_package(CUDA)
 message(STATUS CUDA_LIBRARIES = ${CUDA_LIBRARIES})

 $ cmake ..
 -- 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 compiler: /usr/bin/c++
 -- Check for working CXX compiler: /usr/bin/c++ -- works
 -- Detecting CXX compiler ABI info
 -- Detecting CXX compiler ABI info - done
 -- Found CUDA: /cm/shared/apps/cuda50/toolkit/5.0.35 (found version
 5.0)
 -- CUDA_LIBRARIES =
 /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so
 -- Configuring done
 -- Generating done
 -- Build files have been written to: /home/loose/temp/cmake/cuda/build

 $ CUDA_LIB_PATH=$CUDA_ROOT/lib cmake ..
 -- CUDA_LIBRARIES =

 /cm/shared/apps/cuda50/toolkit/5.0.35/lib64/libcudart.so;/cm/local/apps/cuda50/libs/304.54/lib64/libcuda.so
 -- Configuring done
 -- Generating done
 -- Build files have been written to: /home/loose/temp/cmake/cuda/build

 Only when explicitly setting CUDA_LIB_PATH, libcuda.so is found.

 BTW: On Ubuntu I also need to set CUDA_LIB_PATH, but then to
 /usr/lib/nvidia-current.

 Regards,
 Marcel Loose.



 On 29/04/13 15:36, Robert Maynard wrote:

 Can you provide what Cuda version FindCuda is failing to find, and
 where Cluster Manager is installing the CUDA toolkit and library?

 On Mon, Apr 29, 2013 at 7:38 AM, Marcel Loose lo...@astron.nl wrote:

 Hi all,

 I noticed that FindCUDA.cmake fails to locate libcuda.so on at least
 two
 different platforms: Ubuntu 12.10 and CentOS 6.3 using Cluster Manager
 v5.2.
 I can persuade FindCUDA.cmake to search for this library by explicitly
 setting the environment variable CUDA_LIB_PATH, and then it finds it.
 However, IMHO, using this trick should only be necessary as a last
 resort.
 Is this a bug?

 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



--

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] Problem with CMAKE_AUTOMOC files not being regenerated or cleaned

2013-04-29 Thread Alexander Neundorf
On Monday 29 April 2013, Glenn Coombs wrote:
 I added these lines:
 
 set_directory_properties(
 PROPERTIES ADDITIONAL_MAKE_CLEAN_FILES
 ${CMAKE_CURRENT_BINARY_DIR}/abc.txt
 )
 
 # check the location where abc.txt is supposed to be deleted from
 message(CURRENT_BINARY_DIR: ${CMAKE_CURRENT_BINARY_DIR})
 
 to the end of my CMakeLists.txt and then created abc.txt in the cmake build
 directory.  I can confirm that the abc.txt file was not deleted by a clean
 solution.  I tried this with Visual Studio 2012 and Visual Studio 2008
 (both installs are the Express editions) and the results were identical.

I don't have Windows here so this is kind of hard for me...
Did you do a complete clean or just a clean of some part of the whole 
project ?

Alex
--

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] Cannot restore timestamp error on Windows

2013-04-29 Thread Brad King
On 04/29/2013 10:53 AM, Raffi Enficiaud wrote:
 I read the content of the change in the link you provided, and I have a
 newbie question: 
 Why not using one timestamp (different filename) per library/binary/project? 

The current approach evolved historically.  A per-target approach would
probably work too but things should be working now anyway.

 Looking forward to having this issue solved in the next official release!

It is already solved in 2.8.11-rc*.

-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.11-rc3 ready for testing!

2013-04-29 Thread Alexander Neundorf
Hi,

On Friday 19 April 2013, Robert Maynard wrote:
 The CMake 2.8.11 release candidate continues. This is the last RC
 unless a critical, must-fix issue is found. You can find the source
 and binaries here:
 http://www.cmake.org/files/v2.8/?C=M;O=D

what is the current plan, will there be another rc or will the next be the 
final, and if so, when ?

Alex
--

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] portable way of linking (external) libs statically/dynamically/for dlopen

2013-04-29 Thread Philippe Cerfon
Hi.

I've always thought one of the main objectives of cmake was being
portable, right?
So I was looking for a way to let the user (i.e. the person building a
project) choose how he wan't to link each external library (i.e. not
the ones built as targets by my project), depending on what that lib
supports and (when my own code supports it:) dynamically loaded via
e.g. dlopen.

But it seems that I cannot even tell CMake (in a portable way) that it
should use static or dynamic linking for some external lib (not to
talk about the core libs like libc or libstdc++).
Of course I can work around this any manually search for e.g. .so and
.a files... but that woudln't be portable anymore... not to talk about
different linkage options per linker... so ideally CMake should (IMHO)
take care of all this (for each supported platform/linker).


Am I missing something? Or is that just som major deficiency in the
portable-part?


Cheers,
Phil
--

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] portable way of linking (external) libs statically/dynamically/for dlopen

2013-04-29 Thread Ian Monroe
On Mon, Apr 29, 2013 at 11:13 AM, Philippe Cerfon philc...@gmail.comwrote:

 Hi.

 I've always thought one of the main objectives of cmake was being
 portable, right?
 So I was looking for a way to let the user (i.e. the person building a
 project) choose how he wan't to link each external library (i.e. not
 the ones built as targets by my project), depending on what that lib
 supports and (when my own code supports it:) dynamically loaded via
 e.g. dlopen.

 But it seems that I cannot even tell CMake (in a portable way) that it
 should use static or dynamic linking for some external lib (not to
 talk about the core libs like libc or libstdc++).
 Of course I can work around this any manually search for e.g. .so and
 .a files... but that woudln't be portable anymore... not to talk about
 different linkage options per linker... so ideally CMake should (IMHO)
 take care of all this (for each supported platform/linker).


 Am I missing something? Or is that just som major deficiency in the
 portable-part?


Static linking of external libraries is just a weird thing to do.

Ian
--

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.11-rc3 ready for testing!

2013-04-29 Thread Robert Maynard
Hi,

We found a bug in rc3 and are waiting for the fix to be finalized
before we make rc4. You can
track the bug by following the 2.8.11-rc3 generator expression error thread.

On Mon, Apr 29, 2013 at 2:00 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
 Hi,

 On Friday 19 April 2013, Robert Maynard wrote:
 The CMake 2.8.11 release candidate continues. This is the last RC
 unless a critical, must-fix issue is found. You can find the source
 and binaries here:
 http://www.cmake.org/files/v2.8/?C=M;O=D

 what is the current plan, will there be another rc or will the next be the
 final, and if so, when ?

 Alex
--

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.11-rc3 ready for testing!

2013-04-29 Thread Paul Smith
On Mon, 2013-04-29 at 14:53 -0400, Robert Maynard wrote:
 We found a bug in rc3 and are waiting for the fix to be finalized
 before we make rc4. You can track the bug by following the 2.8.11-rc3
 generator expression error thread.

I haven't seen any action on that thread since Thursday... the last I
heard it seemed Steve and Brad had a fix available.  No one is waiting
on me (for testing etc.) I hope?

Cheers!

--

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] portable way of linking (external) libs statically/dynamically/for dlopen

2013-04-29 Thread Philippe Cerfon
On Mon, Apr 29, 2013 at 8:30 PM, Ian Monroe i...@monroe.nu wrote:
 Static linking of external libraries is just a weird thing to do.
And I thought this wasn’t lkml, where it’s perfectly fine that people,
instead of answering the question (if they choose to answer at all)
tell you your use case would be invalid ;-)

Well I'm perfectly aware of the advantages/disadvantages of static
linking... but there quite some circumstances where users may prefer
it over dynamic linking :)

Cheers!
--

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] portable way of linking (external) libs statically/dynamically/for dlopen

2013-04-29 Thread Alexander Neundorf
On Monday 29 April 2013, Philippe Cerfon wrote:
 Hi.
 
 I've always thought one of the main objectives of cmake was being
 portable, right?
 So I was looking for a way to let the user (i.e. the person building a
 project) choose how he wan't to link each external library (i.e. not
 the ones built as targets by my project), depending on what that lib
 supports and (when my own code supports it:) dynamically loaded via
 e.g. dlopen.
 
 But it seems that I cannot even tell CMake (in a portable way) that it
 should use static or dynamic linking for some external lib (not to
 talk about the core libs like libc or libstdc++).
 Of course I can work around this any manually search for e.g. .so and
 .a files... but that woudln't be portable anymore... not to talk about
 different linkage options per linker... so ideally CMake should (IMHO)
 take care of all this (for each supported platform/linker).
 
 
 Am I missing something? Or is that just som major deficiency in the
 portable-part?

If cmake finds the static version of the library, it should properly use that 
one.
Making cmake find the static version instead of the dynamic version is kind of 
hard, AFAIK the only way to do this is to give the full filename of the static 
lib.

Alex
--

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] Cannot restore timestamp error on Windows

2013-04-29 Thread Raffi Enficiaud
Hi Brad,

Thank you for your reply. 
As you pointed out, the problem seems to come from a race condition on the
file generate.stamp. Now the operations being atomic, the problem should
be solved, in practice.

However, I do not fully understand in what extent the atomicity of renaming
a file would solve this. The log says:
Write the stamp file to a random temporary name and then atomically rename
it to the real stamp file.

The operations take basically less time; hence the problem should occur
less. However:
- process 1 is accessing generate.stamp for reading
- process 2 is moving some tmpfile to generate.stamp - race

The probability of race increases with the number of projects in
CMakeList.txt (since they share generate.stamp) and the number of cores
used for building (and of course the structure and dependencies among the
projects). 

What if, in .\Source\cmLocalVisualStudio7Generator.cxx, we replace:

cmSourceFile* cmLocalVisualStudio7Generator::CreateVCProjBuildRule()
{
  std::string stampName = this-Makefile-GetCurrentOutputDirectory();
  stampName += /;
  stampName += cmake::GetCMakeFilesDirectoryPostSlash();
  stampName += generate.stamp;
  const char* dsprule =
this-Makefile-GetRequiredDefinition(CMAKE_COMMAND);

by

cmSourceFile* cmLocalVisualStudio7Generator::CreateVCProjBuildRule()
{
  std::string stampName = this-Makefile-GetCurrentOutputDirectory();
  stampName += /;
  stampName += cmake::GetCMakeFilesDirectoryPostSlash();
  stampName += std::string(this-Makefile-GetProjectName()) +
_generate.stamp;
  const char* dsprule =
this-Makefile-GetRequiredDefinition(CMAKE_COMMAND);


I do not know the code that much, but I guess Makefile::SetProjectName is
called much earlier than
cmLocalVisualStudio7Generator::CreateVCProjBuildRule, right?
What do you think?

Best,
Raffi Enficiaud


-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: lundi 29 avril 2013 18:56
To: Raffi Enficiaud
Cc: cmake@cmake.org
Subject: Re: [CMake] Cannot restore timestamp error on Windows

On 04/29/2013 10:53 AM, Raffi Enficiaud wrote:
 I read the content of the change in the link you provided, and I have 
 a newbie question:
 Why not using one timestamp (different filename) per
library/binary/project? 

The current approach evolved historically.  A per-target approach would
probably work too but things should be working now anyway.

 Looking forward to having this issue solved in the next official release!

It is already solved in 2.8.11-rc*.

-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] portable way of linking (external) libs statically/dynamically/for dlopen

2013-04-29 Thread Jean-Christophe Fillion-Robin
For example:
https://github.com/commontk/CTK/blob/ac13c32312c9160190b80bd3a03d012782eff40c/Libs/Core/CMake/ctkMacroBFDCheck.cmake#L33-43

Hth
Jc


On Mon, Apr 29, 2013 at 4:36 PM, Alexander Neundorf a.neundorf-w...@gmx.net
 wrote:

 On Monday 29 April 2013, Philippe Cerfon wrote:
  Hi.
 
  I've always thought one of the main objectives of cmake was being
  portable, right?
  So I was looking for a way to let the user (i.e. the person building a
  project) choose how he wan't to link each external library (i.e. not
  the ones built as targets by my project), depending on what that lib
  supports and (when my own code supports it:) dynamically loaded via
  e.g. dlopen.
 
  But it seems that I cannot even tell CMake (in a portable way) that it
  should use static or dynamic linking for some external lib (not to
  talk about the core libs like libc or libstdc++).
  Of course I can work around this any manually search for e.g. .so and
  .a files... but that woudln't be portable anymore... not to talk about
  different linkage options per linker... so ideally CMake should (IMHO)
  take care of all this (for each supported platform/linker).
 
 
  Am I missing something? Or is that just som major deficiency in the
  portable-part?

 If cmake finds the static version of the library, it should properly use
 that
 one.
 Making cmake find the static version instead of the dynamic version is
 kind of
 hard, AFAIK the only way to do this is to give the full filename of the
 static
 lib.

 Alex
 --

 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




-- 
+1 919 869 8849
--

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] Cannot restore timestamp error on Windows

2013-04-29 Thread Brad King
On 04/29/2013 04:37 PM, Raffi Enficiaud wrote:
 - process 1 is accessing generate.stamp for reading

Nothing ever reads the file.  Only its existence and modification
time matter.

 - process 2 is moving some tmpfile to generate.stamp - race

The only race was for multiple processes simultaneously deciding
they need to create the (currently missing) file and then trying
to open the file for write at the same time.  That race is gone
because replacement is now atomic.

   stampName += std::string(this-Makefile-GetProjectName())

CMake has a different meaning for project than .vcxproj so this
will still be the same name for all targets in a directory.  Each
.vcxproj file corresponds to what CMake calls a target.

In order to use a different stamp file for each .vcxproj file then
the custom command produced by CreateVCProjBuildRule would not be
able to be re-used across multiple targets.  Instead each generator
would have to hand-code the custom command for its own .vcxproj file.

While possible it is a lot of work and this bug has already been
solved.

-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] Can't get CTEST_CUSTOM_ERROR_MATCH to work with CTest launchers

2013-04-29 Thread Nils Gladitz

For reference I have opened a new issue:
http://public.kitware.com/Bug/view.php?id=14121

Nils

On 04/25/2013 10:00 PM, Nils Gladitz wrote:
I was able to reproduce the problem with Ninja on Ubuntu and CMake 
2.8.11-rc2.


I set up a test project for which I set CTEST_CUSTOM_ERROR_MATCH to 
FooBar.


It has three custom commands with different outputs and exit codes:

CustomCommand1: this is a FooBar message (exit success)
CustomCommand2: this is a fatal error (exit failure)
CustomCommand3: this is a FooBar fatal error (exit failure)

These are the results that I got (numbers in braces indicate which 
custom commands produce output visible on CDash):


Ninja (Launchers enabled): 0 Build Errors
Ninja (Launchers disabled): 4 Build Errors (1, 2, 3)

Unix Makefiles (Launchers enabled): 2 Build Errors (2, 3)
Unix Makefiles (Launchers disabled): 4 Build Errors (1, 2, 3)

For Unix Makefiles this seems to work better though not quite as I 
expected either.
(I expected CustomCommand1 to trigger an error even though the exit 
code is 0 due to it having FooBar in the output).


But if this is by design it would be nice to have at least the 
commands with failed exit status show up with Ninja like they do with 
Makefiles.


Hope this helps to diagnose the problem.

Nils

On 04/25/2013 07:04 PM, Jean-Christophe Fillion-Robin wrote:

This is probably caused by commit 965358fcf [1]

Can the problem be reproduced using Ninja on Unix platform ?

[1] 
https://github.com/Kitware/CMake/commit/965358fcf64cf1a3693bcdd66f723729e0614ef6



On Thu, Apr 25, 2013 at 12:41 PM, Nils Gladitz glad...@sci-vis.de 
mailto:glad...@sci-vis.de wrote:


Hey Jean-Christophe,

I currently use CMake 2.8.11-rc3 with the Ninja generator on windows.

Nils


On 25.04.2013 17 tel:25.04.2013%2017:30, Jean-Christophe
Fillion-Robin wrote:

Hi Nils,

Since CTEST_USE_LAUNCHERS is ignored when used with generator
different from Make or Ninja  [1], it seems strange that it
impacts your windows build. Which generator are you using ?

Hth
Jc

[1]

https://github.com/Kitware/CMake/blob/master/Modules/CTestUseLaunchers.cmake#L38-40


On Thu, Apr 25, 2013 at 4:44 AM, Nils Gladitz
glad...@sci-vis.de mailto:glad...@sci-vis.de wrote:

One list entry in my CTEST_CUSTOM_ERROR_MATCH is FAILED: 
(in my CTestCustom.cmake.in http://CTestCustom.cmake.in
which is used to generate CTestCustom.cmake in the build
directory).

With CTEST_USE_LAUNCHERS enabled this does not seem to match
errors from custom commands e.g.:
FAILED: cmd.exe /c  [...]

On my CDash installation I see 0 build errors.

When I disable CTEST_USE_LAUNCHERS the error shows up on the
dashboard and the FAILED:  line is highlighted indicating
that a match has been made.

Is this by design (e.g. not implemented for launchers) or
may I be missing something?
Is there e.g. extra work required for
CTEST_CUSTOM_ERROR_MATCH to reach the launcher?

Nils

-- 
Nils Gladitz, B.Sc.

DICOM, Konnektivität und Entwicklung

Scivis wissenschaftliche Bildverarbeitung GmbH
Bertha-von-Suttner-Str. 5
D-37085 Göttingen
GERMANY
Handelsregister Nr. / Trade Register No. B3100 Göttingen
Geschäftsführer / Managing Directors Dr. Gernot Ebel, Dr.
Uwe Engeland

Tel: 0049 (0)551 634181-28
E-Mail: glad...@scivis.de mailto:glad...@scivis.de
Web: www.scivis.de http://www.scivis.de

--

Powered by www.kitware.com http://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




-- 
+1 919 869 8849 tel:%2B1%20919%20869%208849





--
+1 919 869 8849




--

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] 'AUTOMOC' feature skips sources of executable targets?

2013-04-29 Thread Haroogan
Have a look at my post on StackOverflow 
http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-sources-of-executable-targets 
for details.
http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-sources-of-executable-targets 

--

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] 'AUTOMOC' feature skips sources of executable targets?

2013-04-29 Thread Alexander Neundorf
On Monday 29 April 2013, Haroogan wrote:
 Have a look at my post on StackOverflow
 http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so
 urces-of-executable-targets for details.
 http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so
 urces-of-executable-targets

can you please create a small testcase and post it here, or create an entry on 
http://public.kitware.com/Bug and attach it there ?

It should work.

Alex

--

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] portable way of linking (external) libs statically/dynamically/for dlopen

2013-04-29 Thread Philippe Cerfon
On Mon, Apr 29, 2013 at 10:36 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
 If cmake finds the static version of the library, it should properly use that
 one.
I thought it would use the shared one per default?

 Making cmake find the static version instead of the dynamic version is kind of
 hard, AFAIK the only way to do this is to give the full filename of the static
 lib.
In other words: not portable. :(
--

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] portable way of linking (external) libs statically/dynamically/for dlopen

2013-04-29 Thread Philippe Cerfon
On Mon, Apr 29, 2013 at 10:40 PM, Jean-Christophe Fillion-Robin
jchris.filli...@kitware.com wrote:
 For example:
 https://github.com/commontk/CTK/blob/ac13c32312c9160190b80bd3a03d012782eff40c/Libs/Core/CMake/ctkMacroBFDCheck.cmake#L33-43
I'm not sure whether I understand this correctly, or whether it is
what I want ;)
You still seem to hardcode the static library name (= not portable)
--

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] 'AUTOMOC' feature skips sources of executable targets?

2013-04-29 Thread Haroogan

On 29-Apr-13 23:27, Alexander Neundorf wrote:

On Monday 29 April 2013, Haroogan wrote:

Have a look at my post on StackOverflow
http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so
urces-of-executable-targets for details.
http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so
urces-of-executable-targets

can you please create a small testcase and post it here, or create an entry on
http://public.kitware.com/Bug and attach it there ?

It should work.

Alex

Just tried a simple test case, involving bare executable, and that 
indeed works. As I said in the real project, this executable links with 
several shared libraries. How can that affect the fact that 'AUTOMOC' 
should be carried out for executable's sources? Nothing else changes, I 
promise. Unfortunately, it would be very cumbersome to create an example 
since we depend on 3rd party framework, which has to be built and 
properly incorporated into the project, and I wouldn't impose such a 
burden on you. What could be the potential problem?
--

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] 'AUTOMOC' feature skips sources of executable targets?

2013-04-29 Thread Alexander Neundorf
On Monday 29 April 2013, Haroogan wrote:
 On 29-Apr-13 23:27, Alexander Neundorf wrote:
  On Monday 29 April 2013, Haroogan wrote:
  Have a look at my post on StackOverflow
  http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips
  -so urces-of-executable-targets for details.
  http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips
  -so urces-of-executable-targets
  
  can you please create a small testcase and post it here, or create an
  entry on http://public.kitware.com/Bug and attach it there ?
  
  It should work.
  
  Alex
 
 Just tried a simple test case, involving bare executable, and that
 indeed works. As I said in the real project, this executable links with
 several shared libraries. How can that affect the fact that 'AUTOMOC'
 should be carried out for executable's sources? Nothing else changes, I
 promise. Unfortunately, it would be very cumbersome to create an example
 since we depend on 3rd party framework, which has to be built and
 properly incorporated into the project, and I wouldn't impose such a
 burden on you. What could be the potential problem?

Not much.
The cmake variable QT_VERSION_MAJOR must be set.
That's more or less the only thing I can think of.

Alex


--

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] 'AUTOMOC' feature skips sources of executable targets?

2013-04-29 Thread Haroogan

On 29-Apr-13 23:27, Alexander Neundorf wrote:

On Monday 29 April 2013, Haroogan wrote:

Have a look at my post on StackOverflow
http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so
urces-of-executable-targets for details.
http://stackoverflow.com/questions/16286872/cmake-automoc-feature-skips-so
urces-of-executable-targets

can you please create a small testcase and post it here, or create an entry on
http://public.kitware.com/Bug and attach it there ?

It should work.

Alex

I've found the cause, and I think that's very confusing behavior. I'll 
try to do my best explaining it.


Let's begin with top 'CMakeLists.txt':

...

set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_AUTOMOC ON)

...

# NOTE: Order matters (the most independent ones go first)
# because some libraries expose variables through cache (see below).
add_subdirectory(components/B)
add_subdirectory(components/A)

add_subdirectory(components/Executable)

So imagine that we have the 'FindMyPrecious.cmake' custom CMake module 
to locate 3rd party framework MyPrecious:


find_package(Qt4
 4.7.4
 COMPONENTS QtCore
QtGui
QtXml
 REQUIRED)

find_path(MyPrecious_INCLUDE_DIR...)

find_library(MyPrecious_LIBRARY_DEBUG...)

find_library(MyPrecious_LIBRARY_RELEASE...)

set(QT_DEFINITIONS ${QT_DEFINITIONS}
   -DQT_CORE_LIB
   -DQT_GUI_LIB
   -DQT_XML_LIB)

if (CMAKE_BUILD_TYPE MATCHES [Dd][Ee][Bb][Uu][Gg])
  set(QT_DEFINITIONS ${QT_DEFINITIONS}
 -DQT_DEBUG)
else ()
  set(QT_DEFINITIONS ${QT_DEFINITIONS}
 -DQT_NO_DEBUG)
endif ()

set(MyPrecious_DEFINITIONS ${QT_DEFINITIONS})

set(MyPrecious_INCLUDE_DIRS ${MyPrecious_INCLUDE_DIR}
${QT_INCLUDE_DIR}
${QT_QTCORE_INCLUDE_DIR}
${QT_QTGUI_INCLUDE_DIR}
${QT_QTXML_INCLUDE_DIR})

set(MyPrecious_LIBRARY debug ${MyPrecious_LIBRARY_DEBUG}
   optimized ${MyPrecious_LIBRARY_RELEASE})

set(MyPrecious_LIBRARIES ${MyPrecious_LIBRARY}
 ${QT_QTCORE_LIBRARY}
 ${QT_QTGUI_LIBRARY}
 ${QT_QTXML_LIBRARY})

include(FindPackageHandleStandardArgs)

find_package_handle_standard_args(MyPrecious
  DEFAULT_MSG
MyPrecious_INCLUDE_DIR
MyPrecious_LIBRARY
MyPrecious_LIBRARY_DEBUG
MyPrecious_LIBRARY_RELEASE)

mark_as_advanced(MyPrecious_INCLUDE_DIR
MyPrecious_LIBRARY
MyPrecious_LIBRARY_DEBUG
MyPrecious_LIBRARY_RELEASE)

Everything is cool so far. One thing to note is that since MyPrecious 
depends on Qt we are employing transitive dependency strategy as 
recommended on CMake Wiki.


Now let's move to the shared library A (from our project) which 
depends on MyPrecious:


cmake_minimum_required(VERSION 2.8.10)

project(A C CXX)

find_package(MyPrecious REQUIRED)

file(GLOB CPP_FILES sources/*.cpp)

add_definitions(${MyPrecious_DEFINITIONS})

include_directories(${B_INCLUDE_DIRS}# some other library B (in this 
case header-only); B exposed includes with the same strategy

${MyPrecious_INCLUDE_DIRS})

add_library(${PROJECT_NAME} SHARED ${CPP_FILES})

target_link_libraries(${PROJECT_NAME} ${MyPrecious_LIBRARIES})

# Pay attention here, we want to make definitions and includes visible 
(through cache) to the executable since it is going to link against this 
library A

set(${PROJECT_NAME}_DEFINITIONS ${MyPrecious_DEFINITIONS}
CACHE INTERNAL ${PROJECT_NAME}: Definitions FORCE)

set(${PROJECT_NAME}_INCLUDE_DIRS ${PROJECT_SOURCE_DIR}/includes
 ${B_INCLUDE_DIRS}# some other library 
B (in this case header-only);B exposed includes with the same strategy

 ${MyPrecious_INCLUDE_DIRS}
CACHE INTERNAL ${PROJECT_NAME}: Include Directories FORCE)

Finally, let's move to the executable project:

cmake_minimum_required(VERSION 2.8.10)

project(Executable C CXX)

# ---
# ATTENTION: Theoretically, I don't have to add the line below.
# ---
# find_package(MyPrecious REQUIRED)
# ---
# Furthermore, as I said if I use plain old 'qt4_wrap_cpp', I don't add 
it and everything builds fine indeed.
# However, now when using 'AUTOMOC' approach it turns out that without 
this line CMake does not create 'AUTOMOC' target for sources of this 
project.
# The above line simply finds MyPrecious, which you can see is not 
even used any further. I.e. all the definitions and includes of Qt, 
MyPrecious, B, and A are
# obtained transitively through the cache variables (see below/above). 
However, we know that the above line finds Qt too.
# So the only logical thing that comes to my mind is that CMakes 
'AUTOMOC' feature works only when one explicitly or implicitly (like in 
this case) finds Qt (with `find_package`)
# for the project which is desired to be 'AUTOMOC'ed. I 

Re: [CMake] Cannot restore timestamp error on Windows

2013-04-29 Thread Raffi Enficiaud
 The only race was for multiple processes simultaneously deciding they need
to create the (currently missing) file and then trying to open the file for 
 write at the same time.

To what I see on the logs, this is not what I observe:

build   26-avr.-2013 13:11:12 CMake does not need to re-run because
XXX\tmp\src\\CMakeFiles\generate.stamp is up-to-date.
build   26-avr.-2013 13:11:12 Building Custom Rule CCC/CMakeLists.txt
build   26-avr.-2013 13:11:12 Building Custom Rule CCC/CMakeLists.txt
build   26-avr.-2013 13:11:12 Building Custom Rule CCC/CMakeLists.txt
build   26-avr.-2013 13:11:12 CMake does not need to re-run because
XXX\tmp\src\\CMakeFiles\generate.stamp is up-to-date.

then
build   26-avr.-2013 13:11:24 Building Custom Rule CCC/CMakeLists.txt
build   26-avr.-2013 13:11:24   CUSTOMBUILD : CMake error : Cannot restore
timestamp XXX\tmp\src\\CMakeFiles\generate.stamp
[XXX\tmp\src\\SSS.vcxproj]


The file XXX\tmp\src\\CMakeFiles\generate.stamp already existed long
before the error, and many projects were built between. But if by missing
you are saying that it is missing because moved to another filename (I am a
bit ignorant of how it works), then we still have a race condition. 


 CMake has a different meaning for project than .vcxproj so this will
still be the same name for all targets in a directory.  
 Each .vcxproj file corresponds to what CMake calls a target.

Indeed, sorry for that mistake. 


 That race is gone because replacement is now atomic
This is true for unices, but does not seem to be true on Windows. There is a
fallback that tries to move the file 5 times before triggering an error.
This is not atomic. 


 In order to use a different stamp file for each .vcxproj file then the
custom command produced by CreateVCProjBuildRule would not be able to be 
 re-used across multiple targets.  Instead each generator would have to
hand-code the custom command for its own .vcxproj file.

 While possible it is a lot of work and this bug has already been solved.

True, and more true now I have a closer look at the code. I do not
understand why it was so (historically), and not understanding that does not
help me to provide you a patch. For instance, in 
cmLocalVisualStudio10Generator::Generate(), all vcxproj are generated, and
then one unique timestamp file is written, hence for the current
CMakeLists.txt. If I understand well, this is the only location (VC10) where
the timestamp is written/made dirty.
cmLocalVisualStudio7Generator::CreateVCProjBuildRule() adds a rule for
checking the timestamp, but I do not understand why this is not a per-target
custom build rule in cmLocalVisualStudio7Generator::AddCMakeListsRules()
(this could easily be done in cmLocalVisualStudio10Generator::Generate()),
nor to what entity the  this-Makefile-AddCustomCommandToOutput (in
cmLocalVisualStudio7Generator::CreateVCProjBuildRule() ) refers to. 

But if we have something like:
void cmLocalVisualStudio7Generator::AddCMakeListsRules()
{
  cmTargets tgts = this-Makefile-GetTargets();
  // Create the regeneration custom rule.
  if(!this-Makefile-IsOn(CMAKE_SUPPRESS_REGENERATION))
  {
// HERE: just returning the files that should be included
if(cmSourceFile* sf = this-Get_CMAKELISTFILENAME()) 
{
  // Add the rule to targets that need it.
  for(cmTargets::iterator l = tgts.begin(); l != tgts.end(); ++l)
  {
if(l-first != CMAKE_CHECK_BUILD_SYSTEM_TARGET)
{
  l-second.AddSourceFile(sf);
  // HERE adding the custom build rule checking the timestamps
  l-ADD_CUSTOM_BUILD_RULE_WITH_STAMPS();
}


this should be closer to what I thought initially. 

For an automatic build daemon, I think setting CMAKE_SUPPRESS_REGENERATION
should be sufficient workaround (until the next true release with the
proposed workaround). 


Best,
Raffi Enficiaud

--

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] portable way of linking (external) libs statically/dynamically/for dlopen

2013-04-29 Thread J Decker
hard coded names aren't so bad, since they can be composed of dynamic
peices...

lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_SHARED_LIBRARY_PREFIX}c${CMAKE_SHARED_LIBRARY_SUFFIX}
or
lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_STATIC_LIBRARY_PREFIX}c${CMAKE_STATIC_LIBRARY_SUFFIX}

to choose lib[64]/libc.so or lib[64]/libc.a  (or it would generate
c.dll/c.lib for windows type compilers)

But, although you can generate portable projects that target lots of
platforms, the scripts still have to have things like

if( WIN32 )
if( UNIX )
etc...



On Mon, Apr 29, 2013 at 2:38 PM, Philippe Cerfon philc...@gmail.com wrote:

 On Mon, Apr 29, 2013 at 10:40 PM, Jean-Christophe Fillion-Robin
 jchris.filli...@kitware.com wrote:
  For example:
 
 https://github.com/commontk/CTK/blob/ac13c32312c9160190b80bd3a03d012782eff40c/Libs/Core/CMake/ctkMacroBFDCheck.cmake#L33-43
 I'm not sure whether I understand this correctly, or whether it is
 what I want ;)
 You still seem to hardcode the static library name (= not portable)
 --

 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] portable way of linking (external) libs statically/dynamically/for dlopen

2013-04-29 Thread Philippe Cerfon
On Tue, Apr 30, 2013 at 1:54 AM, J Decker d3c...@gmail.com wrote:
 lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_SHARED_LIBRARY_PREFIX}c${CMAKE_SHARED_LIBRARY_SUFFIX}
 or
 lib${CMAKE_LIBRARY_SUFFIX}/${CMAKE_STATIC_LIBRARY_PREFIX}c${CMAKE_STATIC_LIBRARY_SUFFIX}

 to choose lib[64]/libc.so or lib[64]/libc.a  (or it would generate
 c.dll/c.lib for windows type compilers)

 But, although you can generate portable projects that target lots of
 platforms, the scripts still have to have things like

 if( WIN32 )
 if( UNIX )
 etc...
Well exactly this is what I don't wan to do as it's not portable...
_I_ (the developer) need to take care on any possible platorm, it's
library naming conventions and possibly also on any compiler/linker
suite I want to support...
If the responsibility for this falls back to me, I can also build via
shell script (more or less).

What I'd like to have is:
1) My CMakeLists checks for all dependencies (e.g. lib foo) using the
CMakes functions for that.
These functions should tell me which versions were found (i.e. static
or shared).
2) Depending on (1) I set CMake options cache with reasonable defaults
(i.e. in most cases this will be link lib foo dynamic) for each lib
foo.
For some I might even offer to use dlopen(), depending on whether my
sources support this.
3) The user can then chance that settings per lib in the cache as he likes.
4) When I say target_link_library... I want to set some flag (static
vs. shared) depending on what was chosen in (3) (or not link at all in
case of dlopen()),

Everything else, platform naming conventions, compiler/linker options,
should happen automatically (for all supported platforms +
compilter/linker suites)... that would be portability.


Cheers!
--

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-commits] CMake branch, master, updated. v2.8.10.2-1010-g2ba65cc

2013-04-29 Thread Kitware Robot
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, master has been updated
   via  2ba65cc9d904b634120b1b56eabd046aad33ac75 (commit)
  from  c80594ba1274c3dc44c3f2efd70bd5c3d9066bf5 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2ba65cc9d904b634120b1b56eabd046aad33ac75
commit 2ba65cc9d904b634120b1b56eabd046aad33ac75
Author: Kitware Robot kwro...@kitware.com
AuthorDate: Tue Apr 30 00:01:05 2013 -0400
Commit: Kitware Robot kwro...@kitware.com
CommitDate: Tue Apr 30 00:01:05 2013 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 7133dc9..2293000 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
 set(CMake_VERSION_MAJOR 2)
 set(CMake_VERSION_MINOR 8)
 set(CMake_VERSION_PATCH 10)
-set(CMake_VERSION_TWEAK 20130429)
+set(CMake_VERSION_TWEAK 20130430)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits