Re: [cmake-developers] Two more patches

[Brad King]

On Sat, Mar 3, 2012 at 8:59 AM, Yury G.  Kudryashov urkud.ur...@gmail.com 
wrote:

git://gitorious.org/~urkud1/cmake/urkud-cmake.git, please:
* rename-used-commands;
* remove-unused-members.


Good cleanups.  Applied:


https://gitorious.org/~urkud1/cmake/urkud-cmake/commits/remove-unused-members


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e2665710
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aef248a4


https://gitorious.org/~urkud1/cmake/urkud-cmake/commits/rename-used-commands


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89403bf8

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] target usage requirement properties (was: Convention driven CMAKE_USE_PACKAGE macro)

[Brad King]

On 3/4/2012 5:44 PM, Stephen Kelly wrote:

Nice.  This is exactly the kind of interface I had in mind for the
usage requirements approach Alex and I were discussing elsewhere
in this thread.  We will have to think about how to define transitive
properties of these requirements though.



Is this kind of thing roadmapped in any way? Can we work on getting it into
2.8.9 (Is it too late for 2.8.8) and start designing or brainstorming more
fully?


It is a wish list item.  If you have time to think through the design
further and propose something specific I'd love to review and discuss
it.

-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] Introducing: message(DEBUG)

[Brad King]

On 3/3/2012 5:25 AM, Rolf Eike Beer wrote:

+  else if (*i == DEBUG)
+{

...

+status = true;


Rather than being a conditional version of STATUS I think full stack
information is useful for debugging.  Add to the cmake::MessageType
enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
The output should look like an error or warning but with CMake Debug
as the header instead of CMake Error or CMake Warning.

Once the decision to display the message has a cmListFileBacktrace
instance available for the context then you can have fancier rules
for deciding what messages to display.

-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] Making GUI applications by default

[Clinton Stimpson]

On Mar 4, 2012, at 3:29 PM, Stephen Kelly wrote:

 Stephen Kelly steveire@... writes:
 
 
 Brad King wrote:
 
 The implementation is not what I had in mind when I said implies
 the platform-specific property.  This should be its own property
 that one can set/get normally with no special C++-implemented
 mapping to the other two properties.  The generators should look
 for this property first and only if not set look for the platform-
 specific property.  If either is set the effect is the same.
 
 I see. That's a bit more painful. That will mean touching all generators, 
 and I don't have the easy visual studio or mac access to implement or test 
 them.
 
 I happened to read a little bit about CPack recently
 
 http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview
 
 The recommendation is to not use MACOSX_BUNDLE when using cpack,

I don't see that as a general recommendation for GUI applications on Mac OS X.
Its only true if you use the Bundle generator, which does the equivalent of the 
MACOSX_BUNDLE conversion at cpack time (not install time).  I wouldn't base a 
general statement on a generator where one has a broken make install just to 
make a cpack generator work.

If you use any other cpack generator with a GUI application, you do use 
MACOSX_BUNDLE.

Clint

 so I thought
 maybe that makes it different enough to WIN32_EXECUTABLE that they should be
 different CMAKE_ properties.
 
 set(CMAKE_WIN32_EXECUTABLE ON)
 set(CMAKE_MACOSX_BUNDLE ON)
 
 That would also mean that I can actually submit the patch. I'm not so keen on
 having to change every generator instead. Actually I think the existing patch 
 is
 better than touching every generator anyway (that's at least in part why there
 is an abstraction).
 
 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

--

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] Making GUI applications by default

[Stephen Kelly]

Brad King wrote:

 On 3/4/2012 5:29 PM, Stephen Kelly wrote:
 I happened to read a little bit about CPack recently

 http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview

 The recommendation is to not use MACOSX_BUNDLE when using cpack, so I
 thought maybe that makes it different enough to WIN32_EXECUTABLE that
 they should be different CMAKE_ properties.

 set(CMAKE_WIN32_EXECUTABLE ON)
 set(CMAKE_MACOSX_BUNDLE ON)

 That would also mean that I can actually submit the patch. I'm not so
 keen on having to change every generator instead. Actually I think the
 existing patch is better than touching every generator anyway (that's at
 least in part why there is an abstraction).
 
 That's an argument to not have a generalized property name at all,
 so just SetPropertyDefault for WIN32_EXECUTABLE and MACOSX_BUNDLE
 would be sufficient.

Ok. I have pushed win32_executable-and-macosx_bundle-initializers to stage. 
Can I go ahead and merge that to next?

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

Re: [cmake-developers] Making GUI applications by default

[Brad King]

On 3/5/2012 9:42 AM, Stephen Kelly wrote:

Ok. I have pushed win32_executable-and-macosx_bundle-initializers to stage.


Thanks.


Can I go ahead and merge that to next?


Almost.  This hunk misses spaces after the period:

 - about creation of the Info.plist file for the application bundle.);
 + about creation of the Info.plist file for the application bundle.
 + This property is initialized by the value of the variable 

Fix that and then merge.

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] Making GUI applications by default

[Stephen Kelly]

Brad King wrote:

 Fix that and then merge.
 

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

Re: [cmake-developers] Making GUI applications by default

[Stephen Kelly]

Clinton Stimpson wrote:

 I happened to read a little bit about CPack recently

 http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview

 The recommendation is to not use MACOSX_BUNDLE when using cpack,
 
 I don't see that as a general recommendation for GUI applications on Mac
 OS X. 

Yes, my statement was a little over-general.

 Its only true if you use the Bundle generator, which does the
 equivalent of the MACOSX_BUNDLE conversion at cpack time (not install
 time).  I wouldn't base a general statement on a generator where one has a
 broken make install just to make a cpack generator work.
 
 If you use any other cpack generator with a GUI application, you do use
 MACOSX_BUNDLE.

I imagined that users could set the value of CMAKE_MACOSX_BUNDLE to True by 
default, but False if (${CPACK_GENERATOR} STREQUAL MACOSX_BUNDLE).

Is that realistic? I don't really know much about cpack, bundles or Mac OSX 
in general.

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

Re: [cmake-developers] Making GUI applications by default

[Eric Noulard]

2012/3/5 Stephen Kelly steve...@gmail.com:
 Clinton Stimpson wrote:

 I happened to read a little bit about CPack recently

 http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview

 The recommendation is to not use MACOSX_BUNDLE when using cpack,

 I don't see that as a general recommendation for GUI applications on Mac
 OS X.

 Yes, my statement was a little over-general.

 Its only true if you use the Bundle generator, which does the
 equivalent of the MACOSX_BUNDLE conversion at cpack time (not install
 time).  I wouldn't base a general statement on a generator where one has a
 broken make install just to make a cpack generator work.

 If you use any other cpack generator with a GUI application, you do use
 MACOSX_BUNDLE.

 I imagined that users could set the value of CMAKE_MACOSX_BUNDLE to True by
 default, but False if (${CPACK_GENERATOR} STREQUAL MACOSX_BUNDLE).

 Is that realistic? I don't really know much about cpack, bundles or Mac OSX
 in general.

Not really, you may decide run MacOSXBundle CPack generator outside
CMakeLists.txt
i.e. at CPack time and not at CMake time:

cpack -G OSXX11

I don't know much about this CPack generator but from my point of view
the generator
itself should check whether if the executable have been built properly
and warn/error out
with appropriate message if not.


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Making GUI applications by default

[Stephen Kelly]

Eric Noulard wrote:

 2012/3/5 Stephen Kelly steve...@gmail.com:
 Clinton Stimpson wrote:

 I happened to read a little bit about CPack recently

 http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overview

 The recommendation is to not use MACOSX_BUNDLE when using cpack,

 I don't see that as a general recommendation for GUI applications on Mac
 OS X.

 Yes, my statement was a little over-general.

 Its only true if you use the Bundle generator, which does the
 equivalent of the MACOSX_BUNDLE conversion at cpack time (not install
 time).  I wouldn't base a general statement on a generator where one has
 a broken make install just to make a cpack generator work.

 If you use any other cpack generator with a GUI application, you do use
 MACOSX_BUNDLE.

 I imagined that users could set the value of CMAKE_MACOSX_BUNDLE to True
 by default, but False if (${CPACK_GENERATOR} STREQUAL MACOSX_BUNDLE).

 Is that realistic? I don't really know much about cpack, bundles or Mac
 OSX in general.
 
 Not really, you may decide run MacOSXBundle CPack generator outside
 CMakeLists.txt
 i.e. at CPack time and not at CMake time:
 
 cpack -G OSXX11

Right. Thanks for the info.

At the least, this does provide a hammer for projects to use if wanted 
though, right?

if (NOT MYPROJECT_BUILD_FOR_CPACK_BUNDLE)
  set(CMAKE_MACOSX_BUNDLE True)
endif()

cmake .. -DMYPROJECT_BUILD_FOR_CPACK_BUNDLE=True
cpack 

?

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

Re: [cmake-developers] GenerateExportHeader gcc version test failure?

[David Cole]

On Sun, Mar 4, 2012 at 5:42 PM, Stephen Kelly steve...@gmail.com wrote:
 Stephen Kelly steveire@... writes:
  Any idea what would cause that? It must be one of these:
 
  http://open.cdash.org/viewUpdate.php?buildid=2016288

 Note that the GenerateExportHeader_MinorFix makes the problem go away, but
 doesn't explain why the problem occured in the first place.

 I noticed that the branch was merged.

 Was there no interest in finding out why the determination of the GCC version
 suddenly failed?

I'm interested, but it's at the bottom of the priority list in my
book. In the meantime, the fix is a required one in case that variable
is empty in some situations. So we took it.

If somebody figures it out and can make a fix somewhere else so that
variable is not empty on this dashboard, then we'll take that one too.
--

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] Introducing: message(DEBUG)

[Rolf Eike Beer]

 On 3/3/2012 5:25 AM, Rolf Eike Beer wrote:
 +  else if (*i == DEBUG)
 +{
 ...
 +status = true;

 Rather than being a conditional version of STATUS I think full stack
 information is useful for debugging.  Add to the cmake::MessageType
 enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
 The output should look like an error or warning but with CMake Debug
 as the header instead of CMake Error or CMake Warning.

I would like to have that switchable in some way. E.g. for Boost_DEBUG I
don't have stack traces at the moment, but the contents are the
information I need. Stacktraces are useful, but not always.

 Once the decision to display the message has a cmListFileBacktrace
 instance available for the context then you can have fancier rules
 for deciding what messages to display.

I don't think I fully understand what you are trying to say here.

Eike
--

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] Introducing: message(DEBUG)

[Brad King]

On 3/5/2012 10:22 AM, Rolf Eike Beer wrote:

Rather than being a conditional version of STATUS I think full stack
information is useful for debugging.  Add to the cmake::MessageType
enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
The output should look like an error or warning but with CMake Debug
as the header instead of CMake Error or CMake Warning.


I would like to have that switchable in some way. E.g. for Boost_DEBUG I
don't have stack traces at the moment, but the contents are the
information I need. Stacktraces are useful, but not always.


I'm not opposed to a switch but extra verbosity rarely hurts debug
output IMO.  Even a switch at the call site may be the wrong place
because it is up to the viewer of the message whether the full
context is important.  Perhaps the switch can be based on something
similar to the context filters (see below).


Once the decision to display the message has a cmListFileBacktrace
instance available for the context then you can have fancier rules
for deciding what messages to display.


I don't think I fully understand what you are trying to say here.


Elsewhere in this thread discussion proposed filters on messages
based on their context.  Filters based on the full backtrace
should be possible and would give a lot of control.

-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] Introducing: message(DEBUG)

[Eric Noulard]

2012/3/5 Rolf Eike Beer e...@sf-mail.de:
 On 3/3/2012 5:25 AM, Rolf Eike Beer wrote:
 +  else if (*i == DEBUG)
 +    {
 ...
 +    status = true;

 Rather than being a conditional version of STATUS I think full stack
 information is useful for debugging.  Add to the cmake::MessageType
 enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
 The output should look like an error or warning but with CMake Debug
 as the header instead of CMake Error or CMake Warning.

 I would like to have that switchable in some way. E.g. for Boost_DEBUG I
 don't have stack traces at the moment, but the contents are the
 information I need. Stacktraces are useful, but not always.

Then may be you can have a bunch of control var for that:
CMAKE_DEBUG_MESSAGES_STACKTRACE ON/OFF
CMAKE_DEBUG_MESSAGES_FILEPREFIX  ON/OFF
CMAKE_DEBUG_MESSAGES_USERPREFIX stringvalue

then you display some prefix depending on ON/OFF value and if
USERPREFIX is set.

 Once the decision to display the message has a cmListFileBacktrace
 instance available for the context then you can have fancier rules
 for deciding what messages to display.

 I don't think I fully understand what you are trying to say here.

May be something like my previous proposal?

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Introducing: message(DEBUG)

[Eric Noulard]

2012/3/5 Brad King brad.k...@kitware.com:
 On 3/5/2012 10:22 AM, Rolf Eike Beer wrote:

 Rather than being a conditional version of STATUS I think full stack
 information is useful for debugging.  Add to the cmake::MessageType
 enumeration a DEBUG value and teach cmake::IssueMessage to handle it.
 The output should look like an error or warning but with CMake Debug
 as the header instead of CMake Error or CMake Warning.


 I would like to have that switchable in some way. E.g. for Boost_DEBUG I
 don't have stack traces at the moment, but the contents are the
 information I need. Stacktraces are useful, but not always.


 I'm not opposed to a switch but extra verbosity rarely hurts debug
 output IMO.  Even a switch at the call site may be the wrong place
 because it is up to the viewer of the message whether the full
 context is important.  Perhaps the switch can be based on something
 similar to the context filters (see below).


 Once the decision to display the message has a cmListFileBacktrace
 instance available for the context then you can have fancier rules
 for deciding what messages to display.


 I don't think I fully understand what you are trying to say here.


 Elsewhere in this thread discussion proposed filters on messages
 based on their context.  Filters based on the full backtrace
 should be possible and would give a lot of control.

You mean something like a regex?
So that if the stacktrace and/or prefix (and/or the whole message)
matches the regex it is displayed ?

It may cost a lot at runtime?

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Modifying RPATH feature to run tests uninstalled

[Stephen Kelly]

Brad King wrote:

 On Sun, Mar 4, 2012 at 5:18 PM, Stephen Kelly
 steve...@gmail.com wrote:
 That's a good start.  However I do not think the logic plays well
 with BUILD_WITH_INSTALL_RPATH as currently written.  If that is
 set then the build tree should end up with the install-tree rpath
 which should be empty if SKIP_INSTALL_RPATH is on.  Therefore
 the relink/chrpath paths should not need to return true always
 when SKIP_INSTALL_RPATH is on.

 Sorry this took so long. I have updated the branch (It is now
 e96c16ae23885be2e66d67291344369585ebfece)
 
 -this-Target-GetPropertyAsBool(INSTALL_RPATH_USE_LINK_PATH);
 +this-Target-GetPropertyAsBool(INSTALL_RPATH_USE_LINK_PATH) 
 +!(for_install  this-Makefile-IsOn(CMAKE_SKIP_INSTALL_RPATH));
 
 s/for_install/linking_for_install/ because BUILD_WITH_INSTALL_RPATH
 should cause the build tree to get the install tree rpath which is
 empty when CMAKE_SKIP_INSTALL_RPATH is ON.

linking_for_install is already part of the boolean expression. I just 
removed the for_install in the latest version of this patch.

 
cm-DefineProperty
 +(CMAKE_SKIP_INSTALL_RPATH, cmProperty::VARIABLE,
 + Do not include RPATHs in the install tree.,
 
 Please update the documentation of both this variable and
 CMAKE_SKIP_RPATH so each references the other.  We want packagers
 using CMAKE_SKIP_RPATH to discover CMAKE_SKIP_INSTALL_RPATH.

Done.

 
 +  this-SetPropertyDefault(SKIP_INSTALL_RPATH, 0);
 
 This is unnecessary because it is not a target-level property.  The
 new SKIP variable is supposed to be a packager's hammer so we cannot
 let projects turn it off for some targets but not others.

Done.

 
 @@ -3625,28 +3627,33 @@ bool cmTarget::NeedRelinkBeforeInstall(const
 char* config)
 ...
 +  if(this-Makefile-IsOn(CMAKE_SKIP_INSTALL_RPATH))
 +{
 +return true;
 +}
 +
// If chrpath is going to be used no relinking is needed.
if(this-IsChrpathUsed(config))
  {
  return false;
  }
 ...
 @@ -4013,28 +4021,33 @@ bool cmTarget::IsChrpathUsed(const char* config)
 ...
 +  if(this-Makefile-IsOn(CMAKE_SKIP_INSTALL_RPATH))
 +{
 +return true;
 +}
 +
// Allow the user to disable builtin chrpath explicitly.
if(this-Makefile-IsOn(CMAKE_NO_BUILTIN_CHRPATH))
  {
  return false;
  }
 
 Drop these tests.  These two methods are about deciding how to rewrite
 the RPATH during installation.  The code below these hunks decides
 whether it is even possible to do.
 
 Just changes to
 
   cmComputeLinkInformation::GetRPath
   cmTarget::HaveInstallTreeRPATH
   cmTarget::GetInstallNameDirForInstallTree
 
 should be enough for the rest of the logic to work.

Done.

e1b4fec8dd73cc675b3a20f2e045c6282c47553a in my gitorious clone contains the 
updated state. It behaved as I expected in all combinations I tested.

I can push it to stage/next whenever.

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

Re: [cmake-developers] Introducing: message(DEBUG)

[Brad King]

On 3/5/2012 10:33 AM, Eric Noulard wrote:

2012/3/5 Brad Kingbrad.k...@kitware.com:

Elsewhere in this thread discussion proposed filters on messages
based on their context.  Filters based on the full backtrace
should be possible and would give a lot of control.


You mean something like a regex?


I had no particular interface in mind and was just pointing out
what is possible.


So that if the stacktrace and/or prefix (and/or the whole message)
matches the regex it is displayed ?


That sounds reasonable.


It may cost a lot at runtime?


Possibly, but there should be a fast-path if DEBUG messages are
not turned on at all.  Once they are on then the runtime cost
may be worthwhile for such control.

-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] Modifying RPATH feature to run tests uninstalled

[Brad King]

On 3/5/2012 10:47 AM, Stephen Kelly wrote:

e1b4fec8dd73cc675b3a20f2e045c6282c47553a in my gitorious clone contains the
updated state. It behaved as I expected in all combinations I tested.


Much cleaner, thanks.  Here are some more comments.

  outputRuntime  linking_for_install 
 -this-Target-GetPropertyAsBool(INSTALL_RPATH_USE_LINK_PATH);
 +this-Target-GetPropertyAsBool(INSTALL_RPATH_USE_LINK_PATH) 
 +!this-Makefile-IsOn(CMAKE_SKIP_INSTALL_RPATH);

I think this can be simplified to

  outputRuntime  linking_for_install 
 +!this-Makefile-IsOn(CMAKE_SKIP_INSTALL_RPATH) 
  this-Target-GetPropertyAsBool(INSTALL_RPATH_USE_LINK_PATH);

which is also a more readable order for the logic IMO.

 - This allows for easy running from the build tree.,false,
 + This allows for easy running from the build tree.  To omit RPATH
 + in both the install step, but not the build step, use 
 + CMAKE_SKIP_INSTALL_RPATH,false,

The wording in both the install step looks like a cut-n-paste goober.
Also the sentence should end in a period.

 + is always built with RPATH but installed without RPATH.  This can be 

This is imprecise.  The option installs without RPATH whether or not
the build tree gets an RPATH, but the option does not affect the build
tree by itself.

-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] Modifying RPATH feature to run tests uninstalled

[Stephen Kelly]

Brad King wrote:

 Much cleaner, thanks.  Here are some more comments.

Thanks, I'll try to clean up the remaining messiness later when I can give 
it my full attention. With the remaining goobers, clearly I'm not giving it 
enough at the moment :).

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

Re: [cmake-developers] Convention driven CMAKE_USE_PACKAGE macro

[Alexander Neundorf]

On Monday 05 March 2012, Stephen Kelly wrote:
 Alexander Neundorf wrote:
  The question whether the standard-conforming name is FOO_INCLUDE_DIRS or
  Foo_INCLUDE_DIRS, i.e. ExactCase or UPPERCASE, is not decided.
  readme.txt is ambiguous in this point, since it uses as example
  FindXXX.cmake, i.e. an UPPERCASE package name.
  
  There was a thread here in August 2010:
  http://www.mail-archive.com/cmake-developers-
 
 wchdc6uyxvpytjvyw6y...@public.gmane.org/msg00128.html
 
  and results for what casing is used in cmake and in kdelibs here:
  http://www.mail-archive.com/cmake-developers-
 
 wchdc6uyxvpytjvyw6y...@public.gmane.org/msg00157.html
 
 The concensus seems to be that ExactCase is used. It also makes a lot more
 sense to me for several reasons but that's off topic for this thread. It's
 unfortunate that the ambiguity didn't get resolved in general.

Well, I think we all here agree that we would prefer ExactCase if we would 
start from scratch.

But we are not starting from scratch, and so opinions differ.
Old default is by majority ALL_UPPER_CASE.

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] Modifying RPATH feature to run tests uninstalled

[Stephen Kelly]

Brad King wrote:

 On 3/5/2012 4:26 PM, Stephen Kelly wrote:
 I updated the branch again. It is now
 635bf50c27aef184bfa1698953dd44361e1fb2f9
 
 Great, thanks.  Please merge to 'next' for testing.
 

Done. Thanks for the review.

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

Re: [cmake-developers] Making Config.cmake files easier to write

[Alexander Neundorf]

On Friday 02 March 2012, David Cole wrote:
 Alex,
 
 Brad and I reviewed the MakingConfigFilesEasier_ConfigureMacro topic,
 but have two small additional changes to request before we merge it to
 master.
 
 (1) There's a generated comment referencing
 ConfigureConfigFile.cmake but there is no such file. Please change
 that to CMakePackageConfigHelpers.cmake.

Ok.

 And (2) you are using the PACKAGE_HELPER_ prefix... I thought the
 prefix was intended simply to be PACKAGE_.
 
 After you fix up those two minor points, we'll merge it to 'master' next
 time.

So instead of:

#   @PACKAGE_HELPER_INIT@
#   ...
#   set_and_check(FOO_INCLUDE_DIR @PACKAGE_HELPER_INCLUDE_INSTALL_DIR@)
#   set_and_check(FOO_SYSCONFIG_DIR @PACKAGE_HELPER_SYSCONFIG_INSTALL_DIR@)


you prefer the following ?

#   @PACKAGE_INIT@
#   ...
#   set_and_check(FOO_INCLUDE_DIR @PACKAGE_INCLUDE_INSTALL_DIR@)
#   set_and_check(FOO_SYSCONFIG_DIR @PACKAGE_SYSCONFIG_INSTALL_DIR@)

, i.e. without HELPER for both the INIT as well as for the actual helper 
variables ?

I can do that, but I think at least for the variables the HELPER makes 
sense.

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] Making Config.cmake files easier to write

[Brad King]

On 3/5/2012 5:04 PM, Alexander Neundorf wrote:

So instead of:

#   @PACKAGE_HELPER_INIT@
#   ...
#   set_and_check(FOO_INCLUDE_DIR @PACKAGE_HELPER_INCLUDE_INSTALL_DIR@)
#   set_and_check(FOO_SYSCONFIG_DIR @PACKAGE_HELPER_SYSCONFIG_INSTALL_DIR@)


you prefer the following ?


Yes.


#   @PACKAGE_INIT@
#   ...
#   set_and_check(FOO_INCLUDE_DIR @PACKAGE_INCLUDE_INSTALL_DIR@)
#   set_and_check(FOO_SYSCONFIG_DIR @PACKAGE_SYSCONFIG_INSTALL_DIR@)

I can do that, but I think at least for the variables the HELPER makes
sense.


We've been through this on the thread earlier when it was CONFIG_HELPER.
The information contained in the variables is about the PACKAGE, not about
the HELPER.  It is PACKAGE_INCLUDE_INSTALL_DIR because the include dir
is for the PACKAGE.  Even the _INIT variable contains code that computes
information about the PACKAGe.  There is precedent for this in the
find_package command's interface for package version files.

-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

[cmake-developers] [CMake 0013016]: [patch] CMake does not support setting CompileAsManaged attribute for Visual Studio managed C++ files.

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13016 
== 
Reported By:chris.haverkate
Assigned To:
== 
Project:CMake
Issue ID:   13016
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-03-05 18:32 EST
Last Modified:  2012-03-05 18:32 EST
== 
Summary:[patch] CMake does not support setting
CompileAsManaged attribute for Visual Studio managed C++ files.
Description: 
CMake does not support setting CompileAsManaged attribute for Visual Studio
managed C++ files with the Visual Studio 10 generator.

This is not a very cross-platform feature (unless Mono supports managed C++?)
but it is necessary for Intellisense for managed code.

Steps to Reproduce: 
Create a shared library project with managed C++ files with the Visual Studio 10
generator, and observe the apparent inability to specify whether a file needs to
be compiled as managed C++ in the generated project XML file.

Additional Information: 
The attached patch adds support for the VS_COMPILE_AS_MANAGED file property:

set_source_files_properties(file.cpp PROPERTIES VS_COMPILE_AS_MANAGED false)

I tried to copy the coding style but might not have it quite right, there wasn't
much guidance on the wiki. If there is a better way to introduce these changes,
I'm happy to resubmit.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-03-05 18:32 chris.haverkateNew Issue
2012-03-05 18:32 chris.haverkateFile Added:
VisualStudio10GeneratorAddingCompileAsManagedForSourceFileProperties.patch  
 
==

--

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 0013017]: PackageMaker generator sometimes fails when virus scanner active

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13017 
== 
Reported By:Torsten Rohlfing
Assigned To:
== 
Project:CMake
Issue ID:   13017
Category:   CPack
Reproducibility:sometimes
Severity:   major
Priority:   low
Status: new
== 
Date Submitted: 2012-03-05 19:18 EST
Last Modified:  2012-03-05 19:18 EST
== 
Summary:PackageMaker generator sometimes fails when virus
scanner active
Description: 
CPack using the PackageManager generator sometimes (most of the time, really)
fails on MacOS when a virus scanner is installed.

IMPORTANT - This is not so much a CPack bug report as a hint that others may
potentially find useful when they encounter the same situation (right now Google
is useless for this issue). That said, it might be possible for CPack to
implement a workaround, e.g., repeating hdiutil one or two times if this
condition is encountered.

The exact problem is that when the package file is created, the virus scanner
(mine is Symantec) tries to scan the mounted temporary volume. If the scan is
still running when hdiutil tries to unmount the volume, then unmounting will
fail and as a result, package generation will too.

Workaround - re-run the hdiutil command a couple of times. Eventually the
virus scan will complete within the three unmount retries the hdiutil performs,
and then package creation succeeds.

Steps to Reproduce: 
Run

cpack -G PackageMaker


Sometimes ( 50%) the following results:

Pack Error: Problem running hdiutil command: /usr/bin/hdiutil create -ov
-format UDZO -srcfolder
/Users/torsten/cmtk/release/OSX-10.6/_CPack_Packages/Darwin/PackageMaker/CMTK-2.1.3-MacOSX-10.6-x86_64.mpkg
/Users/torsten/cmtk/release/OSX-10.6/_CPack_Packages/Darwin/PackageMaker/CMTK-2.1.3-MacOSX-10.6-x86_64.dmg
Please check
/Users/torsten/cmtk/release/OSX-10.6/_CPack_Packages/Darwin/PackageMaker/hdiutilOutput.log
for errors
CPack Error: Problem compressing the directory
CPack Error: Error when generating package: CMTK


The error log file contains the following:

detachTempimageFile: synchronous unmount /dev/disk2s1 returned 49153
retrying unmount (http://public.kitware.com/Bug/view.php?id=1)...
detachTempImageFile: synchronous retry
(http://public.kitware.com/Bug/view.php?id=1) unmount
/Volumes/CMTK-2.1.3-MacOSX-10.6-x86_64 (/dev/disk2s1) returned 49153
retrying unmount (http://public.kitware.com/Bug/view.php?id=2)...
detachTempImageFile: synchronous retry
(http://public.kitware.com/Bug/view.php?id=1) unmount
/Volumes/CMTK-2.1.3-MacOSX-10.6-x86_64 (/dev/disk2s1) returned 49153
retrying unmount (http://public.kitware.com/Bug/view.php?id=3)...
detachTempImageFile: synchronous retry
(http://public.kitware.com/Bug/view.php?id=1) unmount
/Volumes/CMTK-2.1.3-MacOSX-10.6-x86_64 (/dev/disk2s1) returned 49153
hdiutil: create failed - Resource busy

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-03-05 19:18 Torsten RohlfingNew 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

[cmake-developers] Doxygen documentation

[Yury G. Kudryashov]

Hi!

I've just found that there are two doxygen configs in cmake source tree:
* cmake/doxygen.config
* cmake/Utilities/Doxygen/* VTK magic

The second one can be enabled by BUILD_DOCUMENTATION but doc_makeall.sh 
references some VTK_* variables.

Which one should I use/fix/..?
-- 
Yury G. Kudryashov,
mailto: ur...@mccme.ru

--

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] Build faild on Darwin? Don't know why?

[Eric Noulard]

2012/2/20 David Cole david.c...@kitware.com:
 The lesson here is:

 - ignore dashboard failures for the BundleGenerator test on Mac machines
 unless it is happening consistently build after build after build

 - also ignore any test failures that contain references to a failed run of
 hdiutil which fails sporadically -- only consider it a real problem with
 the CMake code if it happens consistently

 If anybody can actually figure out a good way for us to work-around or
 really fix these issues on the Mac, so we never see sporadic failures as
 build/test problems on the CMake dashboard, I'll gladly buy you dinner!!

David,

Did you see this bug report:
http://public.kitware.com/Bug/view.php?id=13017
this may explain the sporadic failure on MacOS?

Now I see that there is already a retry loop,
[...]
// since we get random dashboard failures with this one
  // try running it more than once
  int numTries = 4;
  bool res = false;
  while(numTries  0)
[...]

but if anti-virus is the reason for hdiutil failure may be there is
a way to tell the anti-virus to stay away from mounted image?



-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

[CMake] structure in project in vs 2008

[Quân Phạm Minh]

how do in cmake to get visual studio 2008 project file have structure with
some folders below:

project
   + Form Files
   + Generate Files
   + Resource Files
   + Header Files
   + Source Files
--

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] Functions inherit parent variables?

[Johannes Zarl]

On Saturday 03 March 2012, 02:29:05, Robert Dailey wrote:
 Well you're really comparing apples to oranges. C++ nested scoping rules
 really have nothing to do with two separate functions sharing scoped
 variables. It doesn't even really serve as a good analogy, so I can't be
 100% certain what you were trying to tell me ;-)
 
 However I appreciate your response. I really just wanted to make sure this
 isn't a bug, because the way the called function inherits the calling
 function's local variables is an unusual behavior for a language, at least
 in my experience. So I had to think twice about it ;)

As Michael said: This behaviour is not at all unusual for scripting languages, 
but there is not really a One True Way: In Tcl you have to import variables 
explicitly, in bourne shell you overwrite values in the parent scope, ...
It's just a property of the language that you have to know about.

So in the CMake language you should be aware that the parent scope is visible 
inside a function, but the function does not affect the parent scope unless 
explicitly stated:

function( test1 )
  set( var_a var_a inner1 )
  message( test1(): var_a: ${var_a} )
endfunction()

function( test2 )
  set( var_a var_a inner2 PARENT_SCOPE )
  message( test2(): var_a: ${var_a} )
endfunction()

set( var_a var_a outer )
test1()
message( var_a: ${var_a} )
test2()
message( var_a: ${var_a} )

--- Output:
test1(): var_a: var_a inner1


   
var_a: var_a outer  


   
test2(): var_a: var_a outer
var_a: var_a inner2

Disclaimer:  Actually, this was surprising to me. I was thinking that 
PARENT_SCOPE sets the value in the current scope plus the parent scope, not in 
the parent scope only. I guess this could be stated in the documentation more 
clearly...

Johannes
--

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] #include and fortran dependencies

[Arjen Markus]

Hello,

for whatever it is worth, C-style preprocessor commands
are a non-standard feature. The Fortran standard itself
defines only the INCLUDE statement (or directive).
Perhaps you can solve this in a standard way by moving the
logic to the CMakeLists.txt files rather than relying
on (possibly ubiquitous but still non-standard) support
of these C preprocessor commands.

Regards,

Arjen

On Tue, 28 Feb 2012 13:28:19 -0500
 Brad King brad.k...@kitware.com wrote:

On 2/28/2012 11:06 AM, Dirk vanMeeuwen wrote:

#include fpp-Windows-definition.inc
MODULE MSG
...
END MODULE

However, when this module MSG is used, the project build 
order
 generated by CMake is not correct (see attached small 
example).


Fortran dependencies are supported, and the Intel Fortran 
12 compiler

is expected to work with the NMake Makefiles generator.

I was able to reproduce the problem.  If I remove the 
#if logic from
the .inc file then it works.  I think this may be a bug 
in the
Source/cmDependsFortran* files of CMake.  It is not 
handling the #if
logic correctly and tricks itself into thinking that all 
the code
after the #include line is being preprocessed out as if 
in #if 0.

That's why the order of the lines affects the results.

I don't have time to investigate this myself but if 
anyone is
interested then take a look at 
Source/cmDependsFortranParser.y
and Source/cmDependsFortran.cxx for use of the _RuleIf, 
_RuleElse,

and similar functions.

-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






DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

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] FortranCInterface broken when cross-compiling

[D. Barbier]

Hello,

I am trying to cross-compile a project containing C, C++ and Fortran
source files with mingw64 on a Debian host (Linux) with CMake 2.8.7:
  $ cat CMakeLists.txt
  cmake_minimum_required(VERSION 2.8)
  project ( FOO CXX C Fortran )
  include ( FortranCInterface )
  FortranCInterface_HEADER ( FC.h )
  $ cat toolchain-x86_64-w64-mingw32.cmake
  SET(CMAKE_SYSTEM_NAME Windows)
  SET(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)
  SET(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
  SET(CMAKE_Fortran_COMPILER x86_64-w64-mingw32-gfortran)
  SET(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres)
  $ mkdir build  cd build
  $ cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain-x86_64-w64-mingw32.cmake ..
  -- The CXX compiler identification is GNU
  -- The C compiler identification is GNU
  -- The Fortran compiler identification is GNU
  -- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++
  -- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++ -- works
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working C compiler: /usr/bin/x86_64-w64-mingw32-gcc
  -- Check for working C compiler: /usr/bin/x86_64-w64-mingw32-gcc -- works
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working Fortran compiler: /usr/bin/x86_64-w64-mingw32-gfortran
  -- Check for working Fortran compiler:
/usr/bin/x86_64-w64-mingw32-gfortran  -- works
  -- Detecting Fortran compiler ABI info
  -- Detecting Fortran compiler ABI info - done
  -- Checking whether /usr/bin/x86_64-w64-mingw32-gfortran supports Fortran 90
  -- Checking whether /usr/bin/x86_64-w64-mingw32-gfortran supports
Fortran 90 -- yes
  -- Detecting Fortran/C Interface
  -- Detecting Fortran/C Interface - Failed to load sample executable
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /tmp/test-cmake/build

This fails because
/usr/share/cmake-2.8/Modules/FortranCInterface/Detect.cmake builds a
FortranCInterface.exe program with try_compile(), and later
find_program() does not find it because it looks for FortranCInterface
instead of FortranCInterface.exe.
It works after replacing
  find_program(FortranCInterface_EXE
NAMES FortranCInterface
PATHS ${FortranCInterface_BINARY_DIR} ${FortranCInterface_BINARY_DIR}/Debug
NO_DEFAULT_PATH
)
by
  find_program(FortranCInterface_EXE
NAMES FortranCInterface${CMAKE_EXECUTABLE_SUFFIX}
PATHS ${FortranCInterface_BINARY_DIR} ${FortranCInterface_BINARY_DIR}/Debug
NO_DEFAULT_PATH
)
in /usr/share/cmake-2.8/Modules/FortranCInterface/Detect.cmake; but
maybe find_file could be used instead?

Denis
--

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] Install commands/shortcuts for the windows explorer

[David Cole]

This is for menu items in the Windows Start menu. Is that what you mean?


See the file CMakeCPackOptions.cmake.in in CMake's own source tree
that has code in it like this:

if(CPACK_GENERATOR MATCHES NSIS)
  ...
  SET(CPACK_NSIS_MENU_LINKS
# ... pairs of (filenames or urls, text for menu items)

doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cmake-commands.html
CMake Commands Help
doc/cmake-@CMake_VERSION_MAJOR@.@CMake_VERSION_MINOR@/cpack.html
CPack Help
http://www.cmake.org; CMake Web Site
)
  ...
endif(CPACK_GENERATOR MATCHES NSIS)

This file is what's known as a CPACK_PROJECT_CONFIG_FILE. See more
about that on this wiki page:
http://www.vtk.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29


HTH,
David


On Sat, Mar 3, 2012 at 4:50 PM,  noru...@me.com wrote:
 Hi,

 Is there an easy way to add/create a windows context menu entry with 
 CMake/nsis?

 If someone has this already done before, maybe this can be explained.

 Thanks in advance

 Best Regards
 NoRulez
 --

 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] structure in project in vs 2008

[David Cole]

On Mon, Mar 5, 2012 at 3:40 AM, Quân Phạm Minh quanpm4...@gmail.com wrote:
 how do in cmake to get visual studio 2008 project file have structure with
 some folders below:

 project
    + Form Files
    + Generate Files
    + Resource Files
    + Header Files
    + Source Files


With the source_group command:

  http://cmake.org/cmake/help/cmake-2-8-docs.html#command:source_group


HTH,
David
--

Powered by www.kitware.com

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

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

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

[CMake] failing target

[Andrea Crotti]

I'm having the following behaviour, and I can't quite understand the 
error message:


..
Built target psi.utility_install
..
make[3]: *** No rule to make target `psi.utility_install', needed by 
`CMakeFiles/install_all_eggs'.  Stop.

make[2]: *** [CMakeFiles/install_all_eggs.dir/all] Error 2
make[1]: *** [CMakeFiles/unzip_all_eggs.dir/rule] Error 2
make: *** [unzip_all_eggs] Error 2


So first it builds successfully psi.utility_install and then it 
complains that there are no rules to make it.

Who is right then and what could cause such a problem?

This is happening on a strange Linux machine, on Windows with MinGW it's 
working (strangely)..

--

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] MSVC_VERSION for VC11?

[Robert Dailey]

I'm assuming MSVC_VERSION will be 1700 for MSVC11. Is this correct?

-
Robert Dailey
--

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] MSVC_VERSION for VC11?

[David Cole]

Correct. Partial output from 'git grep MSVC_VERSION' in the CMake source tree:

$ git grep MSVC_VERSION
...
Modules/CMakeVS10FindMake.cmake:SET(MSVC_VERSION 1600)
Modules/CMakeVS11FindMake.cmake:SET(MSVC_VERSION 1700)
Modules/CMakeVS6FindMake.cmake:SET(MSVC_VERSION 1200)
Modules/CMakeVS71FindMake.cmake:SET(MSVC_VERSION 1310)
Modules/CMakeVS7FindMake.cmake:SET(MSVC_VERSION 1300)
Modules/CMakeVS8FindMake.cmake:SET(MSVC_VERSION 1400)
Modules/CMakeVS9FindMake.cmake:SET(MSVC_VERSION 1500)
...


On Mon, Mar 5, 2012 at 12:40 PM, Robert Dailey rcdai...@gmail.com wrote:
 I'm assuming MSVC_VERSION will be 1700 for MSVC11. Is this correct?

 -
 Robert Dailey

 --

 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] avoid rebuilding targets depending on generated source files

[Ajay Panyala]

 if(${GrammarSource}/test.g IS_NEWER_THAN ${PROJECT_BINARY_DIR}/test.g)
 ADD_CUSTOM_TARGET(...)
 ADD_CUSTOM_COMMAND(...)

 i.e I am totally avoiding the process of rebuilding the test.g file and
 copying the generated files to build/parser
 *IF* test.g has not been modified.

...and if test.g is once modified, you won't have a custom target which
regenerates the source files and copies them to the parser directory -
I'm pretty sure this is not what you intend. Recall the difference
between configuration time and build time in CMakified projects.

You are right. Once test.g is modified, just running make wont rebuild it.
I have to run cmake again and then make since the IF is evaluated only
when cmake is run.


Thanks
Ajay

On Sun, Mar 4, 2012 at 7:35 PM, Michael Hertling mhertl...@online.dewrote:

 On 03/05/2012 01:59 AM, Ajay Panyala wrote:
  I use cmake version 2.8.3.
 
  If I use CMakeLists from your previous reply, it avoids overwriting files
  when X=0.
  I have attached the output of your script.

 Actually, this is exactly what I was talking about: The second make
 X=0 invocation rewrites the source files - i.e., they receive a new
 timestamp - but their contents do not change. Thus, the destination
 files in the parser directory are *not* touched by the second make
 X=0, and this can be seen clearly by reference to the timestamps.
 It's the subsequent make X=1 which provides for a new content of
 the source files and makes cmake -E copy_if_different copy the
 sources to the destinations. That's why I said everything works
 as expected, but you wrote:

  It does not work. The files are still overwritten.

 So, my question again: What exactly does not work?

 I.e., does cmake -E copy_if_different

 - copy a file although the destination exists
  and has the same content as the source, or

 - not copy a file although the destination does not
  exist or does not have the same content as the source?

  It works for my CMakeLists as well now. What I did now is
 
  if(${GrammarSource}/test.g IS_NEWER_THAN ${PROJECT_BINARY_DIR}/test.g)
  ADD_CUSTOM_TARGET(...)
  ADD_CUSTOM_COMMAND(...)
 
  i.e I am totally avoiding the process of rebuilding the test.g file and
  copying the generated files to build/parser
  *IF* test.g has not been modified.

 ...and if test.g is once modified, you won't have a custom target which
 regenerates the source files and copies them to the parser directory -
 I'm pretty sure this is not what you intend. Recall the difference
 between configuration time and build time in CMakified projects.

  PS: Could you set up your e-mail client so that it marks quoted
 text in some way? Currently, one can't distinguish between
 the lines you are writing and the lines written by others.
 
  Sorry. I did not realize that. I use gmail and when I checked my sent
  emails,
  quoted text appears to be clearly marked. Is the quoted text in this
 email
  marked properly.

 Yes, it is.

 Regards,

 Michael

  On Sun, Mar 4, 2012 at 4:05 PM, Michael Hertling mhertl...@online.de
 wrote:
 
  On 03/04/2012 08:02 PM, Ajay Panyala wrote:
  The following project is a boiled-down version of yours but doesn't
  need any programs except for CMake - that's what I actually meant
  with minimal but complete as I don't have the org.antlr.Tool
  Java program:
 
  I am sorry. I was mainly trying to cleanup the big CMakeLists file
  I had and removed about 10 different targets - all of which were
  rebuilt because the 5 files (test*.*) were overwritten.
 
  If you want to try running the test project on your system
 
  test.g is at http://pastie.org/private/agzor3ibzoa5pom6q31qq
 
  org.antlr.Tool is at www.antlr.org/download/antlr-3.4-complete.jar
 
  After configuration, you can run the target by make X=0 and check the
  timestamps by ls -l --full-time test.tokens parser src. Issuing make
  X=0 again reveals that the copied files aren't rewritten as it happens
  after make X=1. Thus, AFAICS, everything works as expected. Could you
  check if the above-noted example also works on your system?
 
  It does not work. The files are still overwritten.
 
  Could you run the following shell script in a build tree configured
  with the CMakeLists.txt from my previous reply and post the output?
 
  # check.sh:
  make X=0 21  /dev/null
  echo After make X=0 (1):
  echo ---
  echo 
  ls --full-time test.tokens src parser
  echo -ne \n\n
  sleep 3
  make X=0 21  /dev/null
  echo After make X=0 (2):
  echo ---
  echo 
  ls --full-time test.tokens src parser
  echo -ne \n\n
  sleep 3
  make X=1 21  /dev/null
  echo After make X=1:
  echo ---
  echo 
  ls --full-time test.tokens src parser
  # End of check.sh
 
  BTW, which CMake version do you use?
 
  Regards,
 
  Michael
 
  PS: Could you set up your e-mail client so that it marks quoted
 text in some way? Currently, one can't distinguish between
 the lines you are writing and the lines written by 

Re: [CMake] MSVC_VERSION for VC11?

[Eric Noulard]

2012/3/5 Robert Dailey rcdai...@gmail.com:
 The docs aren't updated to reflect this so I just wanted to make sure.

Patch for documentation may be accepted as well :-]

 I didn't have time to run through the source code (you Linux people and your
 fancy 'git grep' commands :P )

You Windows people and your need to check compiler version before trying
to compile a portable piece of code :P !!


-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [CMake] MSVC_VERSION for VC11?

[Andreas Pakulat]

On 05.03.12 14:14:13, Robert Dailey wrote:
 The docs aren't updated to reflect this so I just wanted to make sure. I
 didn't have time to run through the source code (you Linux people and your
 fancy 'git grep' commands :P )

You know git including git grep also works on windows (and no I'm not
talking about cygwin).

Andreas

--

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] Generated library location

[Kevin Nathan]

On Sun, 4 Mar 2012 22:15:52 +0100
Andreas Pakulat ap...@gmx.de wrote:

No, for those three at least you also don't need link_directories. The
find-modules for all 3 provide the absolute paths to the libraries in
CMake variables which you can use with target_link_libraries directly
and it'll just work. 

Thanks, Rolf and Andreas! Like I said, I'm pretty new to CMake and
there is a lot to learn. I will work on that next... :-)


-- 
Kevin Nathan (Arizona, USA)  
http://www.project54.com

Open standards. Open source. Open minds. 
The command line is the front line.
Linux 2.6.37.6-0.11-desktop
 14:34pm  up 19 days 23:53,  13 users,  load average: 1.04, 0.99, 0.76
--

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] How to make package depend on tests?

[Oliver kfsone Smith]

I have test and package configurations on my project, I want:

cmake .
make package

to run force injection of the test target prior to building the 
package target.


Can it be done? How? :)


--

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] POST_BUILD ALL_BUILD

[Christopher Piekarski]

Hello All,

I am trying to attach a custom POST_BUILD command to the ALL_BUILD target.
I've tried adding the following at the bottom of my root CMakeLists.txt
file but the Post Event never shows up in Visual Studio. I have been able
to get it to work for sub projects, just not ALL_BUILD. Has anyone gotten
this to work?

add_custom_command(TARGET ALL_BUILD
POST_BUILD
COMMAND python27.exe brand.py
COMMENT Branding VS debug build
)

Many thanks,
Chris
--

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] recognizing shell in use

[Ajay Panyala]

Hello,

Is there anyway that cmake could figure out the shell (bash,csh,..)
that is being use when cmake is invoked on the command line ?

Thanks
Ajay
--

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] Question regarding source tree structure and how to find libraries easily within that structure

[Michael Hertling]

On 03/04/2012 11:01 AM, Andreas Guther wrote:
 Hello,
 
 thanks for the responses. The problem I have is, that we have more than one 
 application in the directory. So if I put an CMakeLists.txt in the Src 
 directory I do not have the choice (only by options). I would prefer a 
 solution where I change into the application directory I want to build and 
 create workspace etc. from there. The created workspace should then also 
 build all necessary libraries for the application.
 
 Any ideas on this?

In Application_1/CMakeLists.txt, e.g., do:

SET(Library_1_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/../Library_1
CACHE PATH Library_1 source directory)
...
ADD_SUBDIRECTORY(${Library_1_SOURCE_DIR} Library_1)

Do the same for Library_2 and every other prerequisite project which

- has a source tree external to Application_1
- you want to be built along with the latter

and finally: TARGET_LINK_LIBRARIES(Application_1 Library_1 ...)

If the fallback value of Library_1_SOURCE_DIR once doesn't suit, you
can set it on the command line or in the GUI before (re)configuring.

Regards,

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] recognizing shell in use

[Eric Noulard]

2012/3/6 Ajay Panyala a...@csc.lsu.edu:
 Hello,

 Is there anyway that cmake could figure out the shell (bash,csh,..)
 that is being use when cmake is invoked on the command line ?

May be you can check $ENV{SHELL} ?
Why would you like to do that?

Usually when using CMake one tries to avoid shell/command interpreter
dependency??
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Functions inherit parent variables?

[Michael Hertling]

On 03/05/2012 10:43 AM, Johannes Zarl wrote:
 On Saturday 03 March 2012, 02:29:05, Robert Dailey wrote:
 Well you're really comparing apples to oranges. C++ nested scoping rules
 really have nothing to do with two separate functions sharing scoped
 variables. It doesn't even really serve as a good analogy, so I can't be
 100% certain what you were trying to tell me ;-)

 However I appreciate your response. I really just wanted to make sure this
 isn't a bug, because the way the called function inherits the calling
 function's local variables is an unusual behavior for a language, at least
 in my experience. So I had to think twice about it ;)
 
 As Michael said: This behaviour is not at all unusual for scripting 
 languages, 
 but there is not really a One True Way: In Tcl you have to import variables 
 explicitly, in bourne shell you overwrite values in the parent scope, ...
 It's just a property of the language that you have to know about.
 
 So in the CMake language you should be aware that the parent scope is visible 
 inside a function, but the function does not affect the parent scope unless 
 explicitly stated:
 
 function( test1 )
   set( var_a var_a inner1 )
   message( test1(): var_a: ${var_a} )
 endfunction()
 
 function( test2 )
   set( var_a var_a inner2 PARENT_SCOPE )
   message( test2(): var_a: ${var_a} )
 endfunction()
 
 set( var_a var_a outer )
 test1()
 message( var_a: ${var_a} )
 test2()
 message( var_a: ${var_a} )
 
 --- Output:
 test1(): var_a: var_a inner1  
   
   
  
 var_a: var_a outer
   
   
  
 test2(): var_a: var_a outer
 var_a: var_a inner2
 
 Disclaimer:  Actually, this was surprising to me. I was thinking that 
 PARENT_SCOPE sets the value in the current scope plus the parent scope, not 
 in 
 the parent scope only. I guess this could be stated in the documentation more 
 clearly...

IMO, the documentation of the PARENT_SCOPE flag is sufficiently clear:

If PARENT_SCOPE is present, the variable will be set in the scope
*above* the current scope. Each new directory or function creates
a new scope. This command will set the value of a variable into
the *parent* directory or *calling* function (whichever is
applicable to the case at hand).

Not a word about setting anything in the current scope, and as for
me, the explanation of CACHE/INTERNAL/FORCE, e.g., is rather vague.

Anyway, an additional remark on this thread's topic: CMake's functions
know neither return values nor pointers or references to variables, so
this kind of access from the callee to the caller's scope is the only
mechanism to transfer data from the the former to the latter, except
for properties and global variables which are often less convenient.

Regards,

Michael
--

Powered by www.kitware.com

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

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

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

Re: [CMake] failing target

[Michael Hertling]

On 03/05/2012 05:59 PM, Andrea Crotti wrote:
 I'm having the following behaviour, and I can't quite understand the 
 error message:
 
 ..
 Built target psi.utility_install
 ..
 make[3]: *** No rule to make target `psi.utility_install', needed by 
 `CMakeFiles/install_all_eggs'.  Stop.
 make[2]: *** [CMakeFiles/install_all_eggs.dir/all] Error 2
 make[1]: *** [CMakeFiles/unzip_all_eggs.dir/rule] Error 2
 make: *** [unzip_all_eggs] Error 2
 
 
 So first it builds successfully psi.utility_install and then it 
 complains that there are no rules to make it.
 Who is right then and what could cause such a problem?
 
 This is happening on a strange Linux machine, on Windows with MinGW it's 
 working (strangely)..

Could you boil down your project to a minimal and self-sufficient
example which exhibits this behavior for further investigations?

Regards,

Michael
--

Powered by www.kitware.com

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

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

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

[Cmake-commits] CMake branch, next, updated. v2.8.7-3053-g234216a

[Brad King]

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, next has been updated
   via  234216ad5221518f03b830d351eb6e3733964487 (commit)
   via  89403bf87f21d9bccb9c73afb5df914cb88ec9ee (commit)
  from  d8adfc2f12b866396f56b2fae89987dafe370734 (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=234216ad5221518f03b830d351eb6e3733964487
commit 234216ad5221518f03b830d351eb6e3733964487
Merge: d8adfc2 89403bf
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Mar 5 08:36:07 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Mar 5 08:36:07 2012 -0500

Merge topic 'rename-used-commands' into next

89403bf Rename UsedCommands to FinalPassCommands


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=89403bf87f21d9bccb9c73afb5df914cb88ec9ee
commit 89403bf87f21d9bccb9c73afb5df914cb88ec9ee
Author: Yury G. Kudryashov urkud.ur...@gmail.com
AuthorDate: Wed Feb 29 11:49:42 2012 +0400
Commit: Yury G. Kudryashov urkud.ur...@gmail.com
CommitDate: Wed Feb 29 11:49:42 2012 +0400

Rename UsedCommands to FinalPassCommands

When I read 'UsedCommands' I thought that it holds all commands used in the
file, not only those that have FinalPass().

diff --git a/Source/cmMakefile.cxx b/Source/cmMakefile.cxx
index fdf5b31..a715f06 100644
--- a/Source/cmMakefile.cxx
+++ b/Source/cmMakefile.cxx
@@ -210,9 +210,9 @@ cmMakefile::~cmMakefile()
 {
 delete *i;
 }
-  for(unsigned int i=0; i  this-UsedCommands.size(); i++)
+  for(unsigned int i=0; i  this-FinalPassCommands.size(); i++)
 {
-delete this-UsedCommands[i];
+delete this-FinalPassCommands[i];
 }
   std::vectorcmFunctionBlocker*::iterator pos;
   for (pos = this-FunctionBlockers.begin();
@@ -421,7 +421,7 @@ bool cmMakefile::ExecuteCommand(const cmListFileFunction 
lff,
   else if(pcmd-HasFinalPass())
 {
 // use the command
-this-UsedCommands.push_back(pcmd.release());
+this-FinalPassCommands.push_back(pcmd.release());
 }
   }
 else if ( this-GetCMakeInstance()-GetWorkingMode() == cmake::SCRIPT_MODE
@@ -813,8 +813,8 @@ void cmMakefile::FinalPass()
 
   // give all the commands a chance to do something
   // after the file has been parsed before generation
-  for(std::vectorcmCommand*::iterator i = this-UsedCommands.begin();
-  i != this-UsedCommands.end(); ++i)
+  for(std::vectorcmCommand*::iterator i = this-FinalPassCommands.begin();
+  i != this-FinalPassCommands.end(); ++i)
 {
 (*i)-FinalPass();
 }
diff --git a/Source/cmMakefile.h b/Source/cmMakefile.h
index 1c46a73..f1f318a 100644
--- a/Source/cmMakefile.h
+++ b/Source/cmMakefile.h
@@ -620,12 +620,6 @@ public:
*/
   bool CanIWriteThisFile(const char* fileName);
 
-  /**
-   * Get the vector of used command instances.
-   */
-  const std::vectorcmCommand* GetUsedCommands() const
-{return this-UsedCommands;}
-
 #if defined(CMAKE_BUILD_WITH_CMAKE)
   /**
* Get the vector source groups.
@@ -913,7 +907,7 @@ protected:
   std::vectorcmSourceGroup SourceGroups;
 #endif
 
-  std::vectorcmCommand* UsedCommands;
+  std::vectorcmCommand* FinalPassCommands;
   cmLocalGenerator* LocalGenerator;
   bool IsFunctionBlocked(const cmListFileFunction lff,
  cmExecutionStatus status);

---

Summary of changes:
 Source/cmMakefile.cxx |   10 +-
 Source/cmMakefile.h   |8 +---
 2 files changed, 6 insertions(+), 12 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v2.8.7-3056-g1ff8087

[Brad King]

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, next has been updated
   via  1ff8087e897324513bf370b3ce96d67432245dab (commit)
   via  aef248a4ff675aeb4af6aa44322bed76f4bcf990 (commit)
   via  e26657103fa95b2a898e438ec6eb982a3c0bf3cc (commit)
  from  234216ad5221518f03b830d351eb6e3733964487 (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=1ff8087e897324513bf370b3ce96d67432245dab
commit 1ff8087e897324513bf370b3ce96d67432245dab
Merge: 234216a aef248a
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Mar 5 08:37:54 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Mar 5 08:37:54 2012 -0500

Merge topic 'remove-unused-members' into next

aef248a Remove cmExprParserHelper::SetLineFile()
e266571 Remove UnionsAvailable member from 2 classes


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aef248a4ff675aeb4af6aa44322bed76f4bcf990
commit aef248a4ff675aeb4af6aa44322bed76f4bcf990
Author: Yury G. Kudryashov urkud.ur...@gmail.com
AuthorDate: Wed Feb 29 21:56:13 2012 +0400
Commit: Yury G. Kudryashov urkud.ur...@gmail.com
CommitDate: Sat Mar 3 15:11:09 2012 +0400

Remove cmExprParserHelper::SetLineFile()

diff --git a/Source/cmExprParserHelper.cxx b/Source/cmExprParserHelper.cxx
index ee37352..7728d74 100644
--- a/Source/cmExprParserHelper.cxx
+++ b/Source/cmExprParserHelper.cxx
@@ -30,12 +30,6 @@ cmExprParserHelper::~cmExprParserHelper()
   this-CleanupParser();
 }
 
-void cmExprParserHelper::SetLineFile(long line, const char* file)
-{
-  this-FileLine = line;
-  this-FileName = file;
-}
-
 int cmExprParserHelper::ParseString(const char* str, int verb)
 {
   if ( !str)
diff --git a/Source/cmExprParserHelper.h b/Source/cmExprParserHelper.h
index f3fd4f6..690426d 100644
--- a/Source/cmExprParserHelper.h
+++ b/Source/cmExprParserHelper.h
@@ -46,8 +46,6 @@ public:
 
   int GetResult() { return this-Result; }
 
-  void SetLineFile(long line, const char* file);
-
   const char* GetError() { return this-ErrorString.c_str(); }
 
 private:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e26657103fa95b2a898e438ec6eb982a3c0bf3cc
commit e26657103fa95b2a898e438ec6eb982a3c0bf3cc
Author: Yury G. Kudryashov urkud.ur...@gmail.com
AuthorDate: Wed Feb 29 17:44:02 2012 +0400
Commit: Yury G. Kudryashov urkud.ur...@gmail.com
CommitDate: Sat Mar 3 15:11:08 2012 +0400

Remove UnionsAvailable member from 2 classes

These classes were copied from cmDependsJavaParserHelper that really needs 
this
member.

diff --git a/Source/cmCommandArgumentParserHelper.h 
b/Source/cmCommandArgumentParserHelper.h
index a211e95..cdb832b 100644
--- a/Source/cmCommandArgumentParserHelper.h
+++ b/Source/cmCommandArgumentParserHelper.h
@@ -81,7 +81,6 @@ private:
   cmStdString InputBuffer;
   std::vectorchar OutputBuffer;
   int CurrentLine;
-  int UnionsAvailable;
   int Verbose;
 
   void Print(const char* place, const char* str);
diff --git a/Source/cmExprParserHelper.h b/Source/cmExprParserHelper.h
index 0c36b44..f3fd4f6 100644
--- a/Source/cmExprParserHelper.h
+++ b/Source/cmExprParserHelper.h
@@ -55,7 +55,6 @@ private:
   cmStdString InputBuffer;
   std::vectorchar OutputBuffer;
   int CurrentLine;
-  int UnionsAvailable;
   int Verbose;
 
   void Print(const char* place, const char* str);

---

Summary of changes:
 Source/cmCommandArgumentParserHelper.h |1 -
 Source/cmExprParserHelper.cxx  |6 --
 Source/cmExprParserHelper.h|3 ---
 3 files changed, 0 insertions(+), 10 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v2.8.7-3058-g027084f

[Stephen Kelly]

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, next has been updated
   via  027084f60efced153ac088acf69ab0e1ff68aba5 (commit)
   via  761c146a4c02c76adafb233606dfe50157857c87 (commit)
  from  1ff8087e897324513bf370b3ce96d67432245dab (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=027084f60efced153ac088acf69ab0e1ff68aba5
commit 027084f60efced153ac088acf69ab0e1ff68aba5
Merge: 1ff8087 761c146
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Mar 5 09:51:50 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Mar 5 09:51:50 2012 -0500

Merge topic 'win32_executable-and-macosx_bundle-initializers' into next

761c146 Add default initializers for WIN32_EXECUTABLE and MACOSX_BUNDLE


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=761c146a4c02c76adafb233606dfe50157857c87
commit 761c146a4c02c76adafb233606dfe50157857c87
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Mar 5 15:36:46 2012 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Mar 5 15:50:55 2012 +0100

Add default initializers for WIN32_EXECUTABLE and MACOSX_BUNDLE

This allows downstreams to use

set(CMAKE_WIN32_EXECUTABLE ON)
set(CMAKE_MACOSX_BUNDLE ON)

to create executables with the WIN32_EXECUTABLE and MACOSX_BUNDLE
properties set on by default.

diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index a31dd01..80f6b87 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -1278,6 +1278,22 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
  See that target property for additional information.,
  false,
  Variables that Control the Build);
+  cm-DefineProperty
+(CMAKE_WIN32_EXECUTABLE, cmProperty::VARIABLE,
+ Default value for WIN32_EXECUTABLE of targets.,
+ This variable is used to initialize the 
+ WIN32_EXECUTABLE property on all the targets. 
+ See that target property for additional information.,
+ false,
+ Variables that Control the Build);
+  cm-DefineProperty
+(CMAKE_MACOSX_BUNDLE, cmProperty::VARIABLE,
+ Default value for MACOSX_BUNDLE of targets.,
+ This variable is used to initialize the 
+ MACOSX_BUNDLE property on all the targets. 
+ See that target property for additional information.,
+ false,
+ Variables that Control the Build);
 
 //   Variables defined when the a language is enabled These variables will
 // also be defined whenever CMake has loaded its support for compiling (LANG)
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index da99eb9..817375e 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -861,7 +861,9 @@ void cmTarget::DefineProperties(cmake *cm)
  of of just main().
  This makes it a GUI executable instead of a console application.  
  See the CMAKE_MFC_FLAG variable documentation to configure use 
- of MFC for WinMain executables.);
+ of MFC for WinMain executables.  
+ This property is initialized by the value of the variable 
+ CMAKE_WIN32_EXECUTABLE if it is set when a target is created.);
 
   cm-DefineProperty
 (MACOSX_BUNDLE, cmProperty::TARGET,
@@ -871,7 +873,9 @@ void cmTarget::DefineProperties(cmake *cm)
  This makes it a GUI executable that can be launched from 
  the Finder.  
  See the MACOSX_BUNDLE_INFO_PLIST target property for information 
- about creation of the Info.plist file for the application bundle.);
+ about creation of the Info.plist file for the application bundle.  
+ This property is initialized by the value of the variable 
+ CMAKE_MACOSX_BUNDLE if it is set when a target is created.);
 
   cm-DefineProperty
 (MACOSX_BUNDLE_INFO_PLIST, cmProperty::TARGET,
@@ -1224,6 +1228,8 @@ void cmTarget::SetMakefile(cmMakefile* mf)
   this-SetPropertyDefault(AUTOMOC, 0);
   this-SetPropertyDefault(AUTOMOC_MOC_OPTIONS, 0);
   this-SetPropertyDefault(LINK_INTERFACE_LIBRARIES, 0);
+  this-SetPropertyDefault(WIN32_EXECUTABLE, 0);
+  this-SetPropertyDefault(MACOSX_BUNDLE, 0);
 
   // Collect the set of configuration types.
   std::vectorstd::string configNames;

---

Summary of changes:
 Source/cmDocumentVariables.cxx |   16 
 Source/cmTarget.cxx|   10 --
 2 files changed, 24 insertions(+), 2 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v2.8.7-3060-g7f1b86d

[Stephen Kelly]

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, next has been updated
   via  7f1b86d666b0d18dae8ea3196e821e57bffdaef7 (commit)
   via  635bf50c27aef184bfa1698953dd44361e1fb2f9 (commit)
  from  027084f60efced153ac088acf69ab0e1ff68aba5 (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=7f1b86d666b0d18dae8ea3196e821e57bffdaef7
commit 7f1b86d666b0d18dae8ea3196e821e57bffdaef7
Merge: 027084f 635bf50
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Mar 5 16:49:21 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Mar 5 16:49:21 2012 -0500

Merge topic 'skip-install-rpath' into next

635bf50 Add an option to skip RPATH during installation.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=635bf50c27aef184bfa1698953dd44361e1fb2f9
commit 635bf50c27aef184bfa1698953dd44361e1fb2f9
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Mon Feb 20 00:34:11 2012 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Mon Mar 5 22:24:57 2012 +0100

Add an option to skip RPATH during installation.

diff --git a/Modules/CMakeGenericSystem.cmake b/Modules/CMakeGenericSystem.cmake
index 6cd8fe6..ee8040e 100644
--- a/Modules/CMakeGenericSystem.cmake
+++ b/Modules/CMakeGenericSystem.cmake
@@ -39,6 +39,8 @@ SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS TRUE)
 
 SET (CMAKE_SKIP_RPATH NO CACHE BOOL
  If set, runtime paths are not added when using shared libraries.)
+SET (CMAKE_SKIP_INSTALL_RPATH NO CACHE BOOL
+ If set, runtime paths are not added when installing shared libraries, 
but are added when building.)
 
 SET(CMAKE_VERBOSE_MAKEFILE FALSE CACHE BOOL If this value is on, makefiles 
will be generated without the .SILENT directive, and all commands will be 
echoed to the console during the make.  This is useful for debugging only. With 
Visual Studio IDE projects all commands are done without /nologo.) 
 
@@ -168,5 +170,6 @@ ENDIF(CMAKE_HOST_UNIX)
 
 MARK_AS_ADVANCED(
   CMAKE_SKIP_RPATH
+  CMAKE_SKIP_INSTALL_RPATH
   CMAKE_VERBOSE_MAKEFILE
 )
diff --git a/Source/cmComputeLinkInformation.cxx 
b/Source/cmComputeLinkInformation.cxx
index edf6c35..c57b85d 100644
--- a/Source/cmComputeLinkInformation.cxx
+++ b/Source/cmComputeLinkInformation.cxx
@@ -1760,6 +1760,7 @@ void 
cmComputeLinkInformation::GetRPath(std::vectorstd::string runtimeDirs,
  !linking_for_install);
   bool use_link_rpath =
 outputRuntime  linking_for_install 
+!this-Makefile-IsOn(CMAKE_SKIP_INSTALL_RPATH) 
 this-Target-GetPropertyAsBool(INSTALL_RPATH_USE_LINK_PATH);
 
   // Construct the RPATH.
diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index 1cab2b5..fb15615 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -355,7 +355,9 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
  If this is set to TRUE, then the rpath information 
  is not added to compiled executables.  The default 
  is to add rpath information if the platform supports it.  
- This allows for easy running from the build tree.,false,
+ This allows for easy running from the build tree.  To omit RPATH
+ in the install step, but not the build step, use 
+ CMAKE_SKIP_INSTALL_RPATH instead.,false,
  Variables that Provide Information);
   cm-DefineProperty
 (CMAKE_SOURCE_DIR, cmProperty::VARIABLE,
@@ -1181,6 +1183,20 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
  Variables that Control the Build);
 
   cm-DefineProperty
+(CMAKE_SKIP_INSTALL_RPATH, cmProperty::VARIABLE,
+ Do not include RPATHs in the install tree.,
+ Normally CMake uses the build tree for the RPATH when building 
+ executables etc on systems that use RPATH. When the software 
+ is installed the executables etc are relinked by CMake to have 
+ the install RPATH. If this variable is set to true then the software 
+ is always installed without RPATH, even if RPATH is enabled when 
+ building.  This can be useful for example to allow running tests from 
+ the build directory with RPATH enabled before the installation step.  
+ To omit RPATH in both the build and install steps, use 
+ CMAKE_SKIP_RPATH instead.,false,
+ Variables that Control the Build);
+
+  cm-DefineProperty
 (CMAKE_EXE_LINKER_FLAGS, cmProperty::VARIABLE,
  Linker flags used to create executables.,
  Flags used by the linker when creating an executable.,false,
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index ae5596b..b87c086 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -3602,7 +3602,8 @@ bool 

[Cmake-commits] CMake branch, master, updated. v2.8.7-561-gec50093

[KWSys 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  ec50093be768c9fa9384cc42a4d1f331f0264b39 (commit)
  from  17a099dd1379051eaa6c0a66a5ee6df5aea49089 (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=ec50093be768c9fa9384cc42a4d1f331f0264b39
commit ec50093be768c9fa9384cc42a4d1f331f0264b39
Author: KWSys Robot kwro...@kitware.com
AuthorDate: Tue Mar 6 00:01:07 2012 -0500
Commit: KWSys Robot kwro...@kitware.com
CommitDate: Tue Mar 6 00:05:18 2012 -0500

KWSys Nightly Date Stamp

diff --git a/Source/kwsys/kwsysDateStamp.cmake 
b/Source/kwsys/kwsysDateStamp.cmake
index d4dcea9..617f126 100644
--- a/Source/kwsys/kwsysDateStamp.cmake
+++ b/Source/kwsys/kwsysDateStamp.cmake
@@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR  2012)
 SET(KWSYS_DATE_STAMP_MONTH 03)
 
 # KWSys version date day component.  Format is DD.
-SET(KWSYS_DATE_STAMP_DAY   05)
+SET(KWSYS_DATE_STAMP_DAY   06)

---

Summary of changes:
 Source/kwsys/kwsysDateStamp.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