Re: [cmake-developers] ninja spaces in the path do not work on linux

[Bill Hoffman]

If I edit the build.ninja file directly:

this:
ident21 = /media/Work/My\ Builds/cmake/Utilities/KWIML/test/test.c
to this:
ident21 = /media/Work/My$ Builds/cmake/Utilities/KWIML/test/test.c

Then it does not complain about test.c.  So it seems like the place to 
fix this would be where it rights out the path to the sources and to 
replace the "\ " stuff with "$ ".  Or the place that puts in the "\ " 
and use $ instead of \ to escape the spaces  in the first place.


As a quick hack I tried this:

std::string cmNinjaTargetGenerator::ConvertToNinjaPath(const char *path) 
const

{
  std::string p = this->LocalGenerator->Convert(path,

cmLocalGenerator::HOME_OUTPUT,

cmLocalGenerator::MAKEFILE);
  cmSystemTools::ReplaceString(p, "\\ ", "$ ");
  return p;
}

It got further but got hung up on Docs/ctest.txt.  That is from a custom 
command so it must be calling something else to convert to paths for 
those...


-Bill
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] ninja broken on windows?

[Peter Kümmel]

On 16.02.2012 22:46, Peter Kümmel wrote:

On 16.02.2012 21:38, Bill Hoffman wrote:

On 2/16/2012 2:57 PM, Peter Kümmel wrote:


They are not interested.
There is another patch in the pipeline but with
this the current generator doesn't work.

Use the official ninja and drop Win atm.


Bummer.  I am most interested in windows.  Would love to stop using


OK, I could update my branch with the official one, disable all
Windows specific patches on Linux. This way, testing on Linux is like
testing against the official ninja, and an Windows we have intermediate
version until ninja supports win32.


I've created on stage the new branch 'ninja-generator-win'.
It differs from 'ninja-generator' only by one small commit:
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=3bda549dd1dc4a739e7a7f1b23ce98b59986940f
(when someone cherry-pick this commit, please also delete this branch)

The CMake binary of this branch generates ninja files which build CMake with a 
patched
ninja version: https://github.com/syntheticpp/ninja/tree/cninja
With the official ninja it is not possible to build CMake on Windows.

At least on Windows I would use this ninja branch until ninja ships Windows 
support out-of-the-box.

The final ninja would only require to change the build rule generation for 
response file support.
Other fixes to the generator will not be lost when we switch back to the 
official ninja code.

Peter




But I don't wanna touch the generator atm because I don't like the actual
proposal for response file support.



gmake...  Seems like they are doing lots of stuff with .d files for
windows.  So, they seem interested in supporting the platform.  Is there
something we can change in the cmake generator to make it work with the
way ninja is today, and will be for the foreseeable future?


-Bill


--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://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


--

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] ninja spaces in the path do not work on linux

[Bill Hoffman]

On 2/17/2012 5:09 PM, Peter Kümmel wrote:

On 17.02.2012 21:37, Bill Hoffman wrote:

On 2/17/2012 3:16 PM, Nicolas Desprès wrote:



I think yes. It is just a matter of time. My weekend is already
overloaded. I'll try to do it. If Peter or someone else in the community
comes up with a patch before me everybody would be happy :-)

I'll try to do my best.


I could give it a try if you pointed me to the right spot in the code...


Does attached patch help?


Nope:

http://www.cdash.org/CDash/viewBuildError.php?buildid=2015922

-Bill
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Brad King wrote:
> On 2/17/2012 5:05 PM, Alexander Neundorf wrote:
> > I think the nicer MODULE_MODE and CONFIG_MODE keywords are not worth
> > breaking backward compatibility of users projects (not cmake) this way.
> 
> We can add them and document them in the new version but not mention
> them in error messages for now.

This is what I have so far:
---
policy NEW, Find-module not found:

CMake Error at CMakeLists.txt:8 (find_package):
  Could not find module Findecm.cmake.

  Adjust CMAKE_MODULE_PATH to find Findecm.cmake.

  Findecm.cmake must either be part of this project itself,
  in this case adjust CMAKE_MODULE_PATH so that it points to the correct
  location inside your source tree.

  Or it must be installed by a package which has already been found via
  find_package().  In this case make sure that this package has indeed been
  found and adjust CMAKE_MODULE_PATH to contain the location where that
  package has installed Findecm.cmake.  This must be a
  variable provided by that package or something similar, i.e.  for instance
  not your current CMAKE_INSTALL_PREFIX.  This error in general means that
  you are relying on a Find-module without ensuring that this Find-module
  exists.


---
policy not set, nothing found:

CMake Warning (dev) at CMakeLists.txt:8 (find_package):
  find_package() did not find Findecm.cmake and additionally
  searched unsuccessfully for configuration files for the package
  ecm, but it was not running in Config mode.

  If this project intentionally uses the configuration file of
  ecm and not a Find-module, add the NO_MODULE keyword to the
  find_package() call to make this explicitly visible and compatible to
  future (and past) CMake versions.

  Policy CMP0018 is not set: find_package() Run "cmake --help-policy CMP0018"
  for policy details.  Use the cmake_policy command to set the policy and
  suppress this warning.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at CMakeLists.txt:8 (find_package):
  Could not find module Findecm.cmake or a configuration file
  for package ecm (requested version 0.0.3) with one of the
  following names:

ecmConfig.cmake
ecm-config.cmake

  Adjust CMAKE_MODULE_PATH to find Findecm.cmake.  To find
  the configuration file, set CMAKE_PREFIX_PATH to the installation prefix of
  ecm, or set ecm_DIR to the directory
  containing a CMake configuration file for ecm.

---
policy OLD, nothing found:

CMake Error at CMakeLists.txt:8 (find_package):
  Could not find module Findecm.cmake or a configuration file
  for package ecm (requested version 0.0.3) with one of the
  following names:

ecmConfig.cmake
ecm-config.cmake

  Adjust CMAKE_MODULE_PATH to find Findecm.cmake.  To find
  the configuration file, set CMAKE_PREFIX_PATH to the installation prefix of
  ecm, or set ecm_DIR to the directory
  containing a CMake configuration file for ecm.

---
policy not set, no matching version found:

CMake Warning (dev) at CMakeLists.txt:8 (find_package):
  find_package() did not find Findecm.cmake, but found
  instead configuration files, which didn't match the required version, for
  the package ecm, but it was not running in Config mode.

  If this project intentionally uses the configuration file of
  ecm and not a Find-module, add the NO_MODULE keyword to the
  find_package() call to make this explicitly visible and compatible to
  future (and past) CMake versions.

  Policy CMP0018 is not set: find_package() Run "cmake --help-policy CMP0018"
  for policy details.  Use the cmake_policy command to set the policy and
  suppress this warning.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at CMakeLists.txt:8 (find_package):
  Could not find a configuration file for package "ecm" that
  is compatible with requested version "0.0.4".

  The following configuration files were considered but not accepted:

/opt/ecm/share/ecm-0.0.2/cmake/ecm-config.cmake, version: 0.0.2
/opt/ecm/share/ecm-0.0.3/cmake/ecm-config.cmake, version: 0.0.3


---
policy not set, config found:

CMake Warning (dev) at CMakeLists.txt:8 (find_package):
  find_package() found the configuration file
  /opt/ecm/share/ecm-0.0.3/cmake/ecm-config.cmake
  for the package ecm, but it was not running in Config mode.

  If this project intentionally uses the configuration file of
  ecm and not a Find-module, add the NO_MODULE keyword to the
  find_package() call to make this explicitly visible and compatible to
  future (and past) CMake versions.

  Policy CMP0018 is not set: find_package() Run "cmake --help-policy CMP0

Re: [cmake-developers] ninja spaces in the path do not work on linux

[Nicolas Desprès]

On Fri, Feb 17, 2012 at 11:09 PM, Peter Kümmel  wrote:

> On 17.02.2012 21:37, Bill Hoffman wrote:
>
>  On 2/17/2012 3:16 PM, Nicolas Desprès wrote:
>>
>>
>>> I think yes. It is just a matter of time. My weekend is already
>>> overloaded. I'll try to do it. If Peter or someone else in the community
>>> comes up with a patch before me everybody would be happy :-)
>>>
>>> I'll try to do my best.
>>>
>>>  I could give it a try if you pointed me to the right spot in the code...
>>
>
> Does attached patch help?


I don't think so because EncodeLiteral is only called in
WriteCustomCommandBuild to encode the description:

  vars["DESC"] = EncodeLiteral(description);

Plus I think we should keep the description untouched since it is printed
in the terminal. This description is the description of custom command rule
used here in rules.ninja:

rule CUSTOM_COMMAND
  command = $COMMAND
  description = $DESC
  restat = 1

Thanks for the patch anyway.

-- 
Nicolas Desprès
--

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] find_package error wording

[Brad King]

On 2/17/2012 5:05 PM, Alexander Neundorf wrote:

I think the nicer MODULE_MODE and CONFIG_MODE keywords are not worth breaking
backward compatibility of users projects (not cmake) this way.


We can add them and document them in the new version but not mention
them in error messages for now.

-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] ninja spaces in the path do not work on linux

[Peter Kümmel]

On 17.02.2012 21:37, Bill Hoffman wrote:

On 2/17/2012 3:16 PM, Nicolas Desprès wrote:



I think yes. It is just a matter of time. My weekend is already
overloaded. I'll try to do it. If Peter or someone else in the community
comes up with a patch before me everybody would be happy :-)

I'll try to do my best.


I could give it a try if you pointed me to the right spot in the code...


Does attached patch help?

Peter
diff --git a/Source/cmGlobalNinjaGenerator.cxx b/Source/cmGlobalNinjaGenerator.cxx
index 7ff33ba..190e777 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -77,6 +77,7 @@ std::string cmGlobalNinjaGenerator::EncodeLiteral(const std::string &lit)
 {
   std::string result = lit;
   cmSystemTools::ReplaceString(result, "$", "$$");
+  cmSystemTools::ReplaceString(result, " ", "$ ");
   return result;
 }
 
--

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] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Brad King wrote:
> On 2/17/2012 4:01 PM, Alexander Neundorf wrote:
> > There is now a branch FindPackage_CONFIG_MODE_MODULE_MODE which has the
> > two keywords, but doesn't change the behaviour yet.
> > So there wasn't a lot to change in the documentation or tests.
> > I'll do the modified behaviour together with the policy.
> 
> Looks good.

I'm just implementing the warnings
There is a problem with the new keywords.

If I make the warning "... use the CONFIG_MODE keyword ..." and the developer 
does this then, then his project will not work anymore with older cmake 
versions, because they don't know CONFIG_MODE.

If the warning says instead "... use the NO_MODULE keyword ..." then the 
project will still work with old and new cmake versions correctly.

I think the nicer MODULE_MODE and CONFIG_MODE keywords are not worth breaking 
backward compatibility of users projects (not cmake) this way.

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] ninja spaces in the path do not work on linux

[Nicolas Desprès]

2012/2/17 Nicolas Desprès 

>
>
> 2012/2/17 Bill Hoffman 
>
>> On 2/17/2012 3:16 PM, Nicolas Desprčs wrote:
>>
>>
>>> I think yes. It is just a matter of time. My weekend is already
>>> overloaded. I'll try to do it. If Peter or someone else in the community
>>> comes up with a patch before me everybody would be happy :-)
>>>
>>> I'll try to do my best.
>>>
>>>  I could give it a try if you pointed me to the right spot in the code...
>
>
> I think the first place to look at is cmGlobalNinjaGenerator.cxx. There
> are a bunch of class methods there that are used to write the statements in
> the .ninja files.
>
> Look at WriteBuild() in particular. Many others are convenient methods
> based on this one. So the escaping logic should happen there. "build"
> statements in ninja are where most of the path are written.
> Some problem may arise from WriteRule() since the path to the command is
> written by it.
>
> Also there are:
>   static std::string EncodeIdent(const std::string &ident, std::ostream
> &vars);
>   static std::string EncodeLiteral(const std::string &lit);
>
> which I don't really know since I haven't written them and they are not
> documented. Peter did. But their name are pretty explicit and their code
> trivial.
>
> I think we should add an EncodePath() method to follow the same logic and
> use it in WriteBuild() and WriteRule().
>
> In WriteBuild(), arguments like ouputs, explictDeps, implicitDeps,
> orderOnlyDeps must be encoded. The tricky part would be that some part of
> the value of the "variables" arguments (which is a hash_map) must be
> encoded because they may be a white space sparated list of word which may
> contains some paths...
>

Just to be clearer, "outputs", "explicitDeps", "implicitDeps" and
"orderOnlyDeps" are all a list of paths (types are declared in
cmNinjaTypes.h) so each item of the list must be encoded.

A "build" statements look like this (using the argument name of WriteBuild):

comment
build outputs: rule explicitDeps | implicitDeps || orderOnlyDeps
  variables


>
> For exemple look at this part of the build.ninja file generated for cmake:
>
> build Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLParser.cxx.o:
> CXX_COMPILER ../Tests/CMakeLib/testXMLParser.cxx || Source/libCMakeLib.a
>   DEFINES = -DLIBARCHIVE_STATIC
>   FLAGS = -Wall  -g -IUtilities -I../Utilities -ITests/CMakeLib -ISource
> -I../Source
>
> or this one:
>
> # Link the executable Tests/CMakeLib/CMakeLibTests
> build Tests/CMakeLib/CMakeLibTests: CXX_EXECUTABLE_LINKER
> Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/CMakeLibTests.cxx.o
> Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testGeneratedFileStream.cxx.o
> Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testSystemTools.cxx.o
> Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testUTF8.cxx.o
> Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLParser.cxx.o
> Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLSafe.cxx.o |
> Source/libCMakeLib.a Source/kwsys/libcmsys.a /usr/lib/libexpat.so
> Utilities/cmlibarchive/libarchive/libcmlibarchive.a /usr/lib/libz.so
> Utilities/cmbzip2/libcmbzip2.a Utilities/cmcompress/libcmcompress.a
> /usr/lib/libcurl.so
>   FLAGS = -Wall  -fPIC
>   LINK_LIBRARIES = -rdynamic Source/libCMakeLib.a Source/kwsys/libcmsys.a
> -ldl -lexpat Utilities/cmlibarchive/libarchive/libcmlibarchive.a -lz
> Utilities/cmbzip2/libcmbzip2.a Utilities/cmcompress/libcmcompress.a -lcurl
>   POST_BUILD = :
>   PRE_LINK = :
>
> In this case I think the encoding should happen before the call to
> WriteBuild when the "variables" argument is built because WriteBuild would
> not have enough information to figure out which part of the variable value
> is a path or not, specially for things like: "-I../Utilities"
>
> Hope this helps,
> Cheers,
> -Nico
>
>


-- 
Nicolas Desprès
--

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] ninja spaces in the path do not work on linux

[Nicolas Desprès]

2012/2/17 Bill Hoffman 

> On 2/17/2012 3:16 PM, Nicolas Desprčs wrote:
>
>
>> I think yes. It is just a matter of time. My weekend is already
>> overloaded. I'll try to do it. If Peter or someone else in the community
>> comes up with a patch before me everybody would be happy :-)
>>
>> I'll try to do my best.
>>
>>  I could give it a try if you pointed me to the right spot in the code...


I think the first place to look at is cmGlobalNinjaGenerator.cxx. There are
a bunch of class methods there that are used to write the statements in the
.ninja files.

Look at WriteBuild() in particular. Many others are convenient methods
based on this one. So the escaping logic should happen there. "build"
statements in ninja are where most of the path are written.
Some problem may arise from WriteRule() since the path to the command is
written by it.

Also there are:
  static std::string EncodeIdent(const std::string &ident, std::ostream
&vars);
  static std::string EncodeLiteral(const std::string &lit);

which I don't really know since I haven't written them and they are not
documented. Peter did. But their name are pretty explicit and their code
trivial.

I think we should add an EncodePath() method to follow the same logic and
use it in WriteBuild() and WriteRule().

In WriteBuild(), arguments like ouputs, explictDeps, implicitDeps,
orderOnlyDeps must be encoded. The tricky part would be that some part of
the value of the "variables" arguments (which is a hash_map) must be
encoded because they may be a white space sparated list of word which may
contains some paths...

For exemple look at this part of the build.ninja file generated for cmake:

build Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLParser.cxx.o:
CXX_COMPILER ../Tests/CMakeLib/testXMLParser.cxx || Source/libCMakeLib.a
  DEFINES = -DLIBARCHIVE_STATIC
  FLAGS = -Wall  -g -IUtilities -I../Utilities -ITests/CMakeLib -ISource
-I../Source

or this one:

# Link the executable Tests/CMakeLib/CMakeLibTests
build Tests/CMakeLib/CMakeLibTests: CXX_EXECUTABLE_LINKER
Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/CMakeLibTests.cxx.o
Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testGeneratedFileStream.cxx.o
Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testSystemTools.cxx.o
Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testUTF8.cxx.o
Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLParser.cxx.o
Tests/CMakeLib/CMakeFiles/CMakeLibTests.dir/testXMLSafe.cxx.o |
Source/libCMakeLib.a Source/kwsys/libcmsys.a /usr/lib/libexpat.so
Utilities/cmlibarchive/libarchive/libcmlibarchive.a /usr/lib/libz.so
Utilities/cmbzip2/libcmbzip2.a Utilities/cmcompress/libcmcompress.a
/usr/lib/libcurl.so
  FLAGS = -Wall  -fPIC
  LINK_LIBRARIES = -rdynamic Source/libCMakeLib.a Source/kwsys/libcmsys.a
-ldl -lexpat Utilities/cmlibarchive/libarchive/libcmlibarchive.a -lz
Utilities/cmbzip2/libcmbzip2.a Utilities/cmcompress/libcmcompress.a -lcurl
  POST_BUILD = :
  PRE_LINK = :

In this case I think the encoding should happen before the call to
WriteBuild when the "variables" argument is built because WriteBuild would
not have enough information to figure out which part of the variable value
is a path or not, specially for things like: "-I../Utilities"

Hope this helps,
Cheers,
-Nico
--

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] Tests directory layout

[Brad King]

On 2/17/2012 3:03 PM, Rolf Eike Beer wrote:

In a README please, for locality of reference.


Pushed as commit 378f2291593c5b1d7d9fcd03029b931ce674a3d2 to next.


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] find_package error wording

[Brad King]

On 2/17/2012 4:01 PM, Alexander Neundorf wrote:

There is now a branch FindPackage_CONFIG_MODE_MODULE_MODE which has the two
keywords, but doesn't change the behaviour yet.
So there wasn't a lot to change in the documentation or tests.
I'll do the modified behaviour together with the policy.


Looks good.

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] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Brad King wrote:
> On 2/17/2012 2:16 PM, Alexander Neundorf wrote:
> > On Friday 17 February 2012, Brad King wrote:
> >> On 2/17/2012 2:01 PM, Alexander Neundorf wrote:
> >>> Do you want me to add the new keywords ?
> >>> NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE
> >> 
> >> Yes, but I don't think NO_CONFIG_MODE is necessary.  NO_MODULE
> >> will become historical.  Let's make the new ones consistent with
> >> 
> >> each other:
> >> CONFIG_MODE
> >> MODULE_MODE
> >> 
> >> The names have clear mapping to the documented modes.
> >> 
> >> This change can be made first with documentation and tests.
> >> I'd like to review and accept that change first.
> > 
> > I'd like to do this on top of the FindPackage_ImprovedErrorMessages
> > branch, which has IMO only uncontroversial fixes to the error messages
> > and a small bugfix.
> > Ok ?
> > (since I merged this already into next, and I have never undone such a
> > merge yet)
> 
> Okay.  The messages will be tweaked again by the new modes though.

There is now a branch FindPackage_CONFIG_MODE_MODULE_MODE which has the two 
keywords, but doesn't change the behaviour yet.
So there wasn't a lot to change in the documentation or tests.
I'll do the modified behaviour together with the policy.

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] ninja broken on windows?

[Peter Kümmel]

On 17.02.2012 21:27, Peter Kümmel wrote:


I did find out that the ninja generator is not part of the cmake
bootstrap.


Where is the actual cmake repository and branch which contains the ninja 
generator
on which we should work?


stage/ninja-generator?



Peter
--

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] ninja spaces in the path do not work on linux

[Bill Hoffman]

On 2/17/2012 3:16 PM, Nicolas Desprès wrote:



I think yes. It is just a matter of time. My weekend is already
overloaded. I'll try to do it. If Peter or someone else in the community
comes up with a patch before me everybody would be happy :-)

I'll try to do my best.


I could give it a try if you pointed me to the right spot in the code...

-Bill

--

Powered by www.kitware.com

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

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

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

[cmake-developers] Additional software on a Windows build machine

[Rolf Eike Beer]

Hi,

the CMakeOnly.AllFindModules collects the output of all the Find*.cmake 
modules for some weeks now. However it of course can only find what is 
installed. There are some modules that find their stuff by querying an 
executable for things, like perl and ruby for example. I suspect that these 
programs will output a native path, i.e. can screw up things severely on 
Windows. Therefore I would like to see if one of the Kitware build machines 
could get a bunch of additional stuff installed to give the findmodules 
something to work on. Currently my main interest would be perl (see e.g. 
http://www.activestate.com/activeperl/) and ruby 
(http://rubyforge.org/projects/rubyinstaller/). The reason is simply that I 
have touched those modules recently and would like to see if they are properly 
working. Any other stuff you may find suitable (python, lua, whatever 
libraries) will certainly not hurt either.

Thanks,

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] ninja broken on windows?

[Peter Kümmel]

I did find out that the ninja generator is not part of the cmake
bootstrap.


Where is the actual cmake repository and branch which contains the ninja 
generator
on which we should work?

Peter
--

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] ninja spaces in the path do not work on linux

[Nicolas Desprès]

2012/2/17 Bill Hoffman 

> On 2/17/2012 12:26 PM, Nicolas Desprès wrote:
>
>>
>> I think it is a bug in the generator which do not escape the space
>> properly using the $ character as supported by Ninja.
>>
>> --
>> Nicolas Desprès
>>
>>  Will you be able to fix that?
>

I think yes. It is just a matter of time. My weekend is already overloaded.
I'll try to do it. If Peter or someone else in the community comes up with
a patch before me everybody would be happy :-)

I'll try to do my best.

Cheers,
-Nico
--

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] Tests directory layout

[Rolf Eike Beer]

Brad King wrote:
> On 1/20/2012 1:16 PM, Rolf Eike Beer wrote:
> > What I currently know is:
> > 
> > -if tests run in CMake script mode, they should go in CMakeTests
> > -if they need to run CMake in configure mode, but don't build anything,
> > they should go in CMakeOnly
> > -if they test something from the Modules directory, but do not belong to
> > one of the previous 2 cases, they should go in Modules
> > 
> > Correct? Anything else?
> 
> That covers what little organization we have now ;)
> 
> > Where should such a list go? Tests/README? Wiki?
> 
> In a README please, for locality of reference.

Pushed as commit 378f2291593c5b1d7d9fcd03029b931ce674a3d2 to next.

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] find_package error wording

[Brad King]

On 2/17/2012 2:16 PM, Alexander Neundorf wrote:

On Friday 17 February 2012, Brad King wrote:

On 2/17/2012 2:01 PM, Alexander Neundorf wrote:

Do you want me to add the new keywords ?
NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE


Yes, but I don't think NO_CONFIG_MODE is necessary.  NO_MODULE
will become historical.  Let's make the new ones consistent with
each other:

CONFIG_MODE
MODULE_MODE

The names have clear mapping to the documented modes.

This change can be made first with documentation and tests.
I'd like to review and accept that change first.


I'd like to do this on top of the FindPackage_ImprovedErrorMessages branch,
which has IMO only uncontroversial fixes to the error messages and a small
bugfix.
Ok ?
(since I merged this already into next, and I have never undone such a merge
yet)


Okay.  The messages will be tweaked again by the new modes though.

-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] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Brad King wrote:
> On 2/17/2012 2:01 PM, Alexander Neundorf wrote:
> > Do you want me to add the new keywords ?
> > NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE
> 
> Yes, but I don't think NO_CONFIG_MODE is necessary.  NO_MODULE
> will become historical.  Let's make the new ones consistent with
> each other:
> 
>CONFIG_MODE
>MODULE_MODE
> 
> The names have clear mapping to the documented modes.
> 
> This change can be made first with documentation and tests.
> I'd like to review and accept that change first.

I'd like to do this on top of the FindPackage_ImprovedErrorMessages branch, 
which has IMO only uncontroversial fixes to the error messages and a small 
bugfix.
Ok ?
(since I merged this already into next, and I have never undone such a merge 
yet)

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] CMake improve-findruby topic

[Rolf Eike Beer]

Brad King wrote:
> On 2/17/2012 1:31 PM, Rolf Eike Beer wrote:
> >> Does this address
> >> 
> >> http://www.cmake.org/Bug/view.php?id=12965
> > 
> > Nope, sadly not. But it should make that easier to solve.
> 
> Currently we have no official maintainer for the module.
> 
> Alex, Eike, do either of you care to take assignment of this issue?
> Otherwise I'll update the issue with a link to the module maintainer
> page asking for help.

I have no idea of Ruby. I just saw the warnings and fixed them.

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] find_package error wording

[Brad King]

On 2/17/2012 2:01 PM, Alexander Neundorf wrote:

Do you want me to add the new keywords ?
NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE


Yes, but I don't think NO_CONFIG_MODE is necessary.  NO_MODULE
will become historical.  Let's make the new ones consistent with
each other:

  CONFIG_MODE
  MODULE_MODE

The names have clear mapping to the documented modes.

This change can be made first with documentation and tests.
I'd like to review and accept that change first.

Then the policy can be added on top of it as a new topic.

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] find_package module-only policy (was: find_package error wording)

[Brad King]

On 2/17/2012 1:54 PM, Alexander Neundorf wrote:

Should I do this by continuing in the FindPackage_ImprovedErrorMessages
branch or create a new branch, branched away from
FindPackage_ImprovedErrorMessages ?


The messages will probably be all different with the policy.
Let's start a new one for this change and revert the current
branch to avoid conflicts.

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] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Alexander Neundorf wrote:
...
> Ok :-)
> 
> Should I do this by continuing in the FindPackage_ImprovedErrorMessages
> branch or create a new branch, branched away from
> FindPackage_ImprovedErrorMessages ?

I create a new branch.

Do you want me to add the new keywords ?
NO_MODULE == CONFIG_MODE == !MODULE == !NO_CONFIG_MODE


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] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Brad King wrote:
> On 2/17/2012 1:28 PM, Alexander Neundorf wrote:
> >> We can adjust it slightly to avoid the policy warning when FooConfig
> >> 
> >> is found and Foo_DIR is set:
> >>- search for FindFoo.cmake, use if found
> >>- if not found, check new policy setting
> >>- if not set, enter config mode and emit both the policy warning
> >>
> >>  and the current error if not found
> >>
> >>- if set to OLD, enter config mode and use current error if not found
> >>- if set to NEW, present error about no FindFoo in module path
> > 
> > Just to make sure I understand:
> > behave as described intially, but don't warn if the config file has been
> > found via Foo_DIR.
> > Right ?
> > Ok with me.
> 
> Yes.  That will avoid unnecessary policy warnings when things work.
> 
> Please push a proposed implementation to the stage for review.
> The documentation of the policy will have a lot of history to
> explain this.

Ok :-)

Should I do this by continuing in the FindPackage_ImprovedErrorMessages
branch or create a new branch, branched away from 
FindPackage_ImprovedErrorMessages ?

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 exports first-class (was: Making Config.cmake files easier to write)

[Brad King]

On 2/17/2012 1:33 PM, Yury G. Kudryashov wrote:

Eric Noulard wrote:


2012/2/17 Alexander Neundorf:

We discussed that too already.


Sorry, I surely missed this part if the discussion,
next time don't bother re-explaining me I'll go and dig the ML.

A digest of the old discussion.

The only non-bloated version of "do all the cmake-config magic" command I
see is write_basic_config_file_for_export(MyExport). This would require some
changes on C++ side (i.e., make it possible to query MyExport DESTINTATION,
NAMESPACE, list of targets etc.). And this will work only for simple cases
(e.g., a few libraries/executables with simple version logic).


If anyone is interested in working on something like this the C++ changes
you mention would need to make exports recorded by either export() or
install(EXPORT) into first-class objects.  A major missing feature from
them right now is having multiple logical exports with dependencies.
Currently an export must include the transitive closure of its own
dependencies.  If instead they were first class objects in CMake then
then the dependencies of one export could be satisfied by an export-level
dependency on another export.

Note that this is not directly tied to package configuration file generation.
Exports correspond to *target* files that can be loaded by package config
files to import the targets provided by an export into another project.
I suppose extra properties could be configured on the exports to generate
simple package configuration files but as you say it would only work for
simple cases.

-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] CMake improve-findruby topic

[Alexander Neundorf]

On Friday 17 February 2012, you wrote:
> On 2/17/2012 1:31 PM, Rolf Eike Beer wrote:
> >> Does this address
> >> 
> >> http://www.cmake.org/Bug/view.php?id=12965
> > 
> > Nope, sadly not. But it should make that easier to solve.
> 
> Currently we have no official maintainer for the module.
> 
> Alex, Eike, do either of you care to take assignment of this issue?
> Otherwise I'll update the issue with a link to the module maintainer
> page asking for help.

In general yes, but it's not on my priority list for 2.8.8.
So, it would be nice if somebody else could take care of it.

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] CMake improve-findruby topic

[Brad King]

On 2/17/2012 1:31 PM, Rolf Eike Beer wrote:

Does this address
http://www.cmake.org/Bug/view.php?id=12965

Nope, sadly not. But it should make that easier to solve.


Currently we have no official maintainer for the module.

Alex, Eike, do either of you care to take assignment of this issue?
Otherwise I'll update the issue with a link to the module maintainer
page asking for help.

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] find_package error wording

[Brad King]

On 2/17/2012 1:28 PM, Alexander Neundorf wrote:

We can adjust it slightly to avoid the policy warning when FooConfig
is found and Foo_DIR is set:

   - search for FindFoo.cmake, use if found
   - if not found, check new policy setting
   - if not set, enter config mode and emit both the policy warning
 and the current error if not found
   - if set to OLD, enter config mode and use current error if not found
   - if set to NEW, present error about no FindFoo in module path


Just to make sure I understand:
behave as described intially, but don't warn if the config file has been found
via Foo_DIR.
Right ?
Ok with me.


Yes.  That will avoid unnecessary policy warnings when things work.

Please push a proposed implementation to the stage for review.
The documentation of the policy will have a lot of history to
explain this.

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

[Yury G. Kudryashov]

Eric Noulard wrote:

> 2012/2/17 Alexander Neundorf :
>> We discussed that too already.
> 
> Sorry, I surely missed this part if the discussion,
> next time don't bother re-explaining me I'll go and dig the ML.
A digest of the old discussion.

The only non-bloated version of "do all the cmake-config magic" command I 
see is write_basic_config_file_for_export(MyExport). This would require some 
changes on C++ side (i.e., make it possible to query MyExport DESTINTATION, 
NAMESPACE, list of targets etc.). And this will work only for simple cases 
(e.g., a few libraries/executables with simple version logic).
-- 
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] CMake improve-findruby topic

[Rolf Eike Beer]

Brad King wrote:
> On 2/17/2012 12:09 PM, Rolf Eike Beer wrote:
> > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=854e76237ce3e8f03d9cabc
> > ad1f8f37e04992ad3 commit 854e76237ce3e8f03d9cabcad1f8f37e04992ad3
> > Author: Rolf Eike Beer
> > AuthorDate: Fri Feb 17 18:06:07 2012 +0100
> > Commit: Rolf Eike Beer
> > CommitDate: Fri Feb 17 18:06:07 2012 +0100
> > 
> >  FindRuby: clean up querying variables from Ruby
> >  
> >  Newer Ruby versions (from 1.9 onward) seem to warn if you query
> >  Config::CONFIG and print a warning to use RbConfig instead. RbConfig
> >  seems to also work in older versions, at least in 1.8. Use a macro
> >  to query RbConfig first and only if that doesn't give anything fall
> >  back to Config.
> 
> Does this address
> 
>http://www.cmake.org/Bug/view.php?id=12965
> 
> ?

Nope, sadly not. But it should make that easier to solve.

I wonder what does ruby output on Windows? Likely backslash separated paths, 
in which case most of those things would also need an additional 
file(TO_CMAKE_PATH).

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] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Brad King wrote:
> On 2/17/2012 12:09 PM, Alexander Neundorf wrote:
> > But another significant part of the reason is probably that beside
> > upstreaming a module to cmake, there is no other "official" way to
> > distribute Find- modules. So if somebody wrote a libblub, it is a
> > relatively obvious choice to install FindBlub.cmake as part of the
> > library, so that whoever uses Blub, also has FindBlub.cmake available.
> 
> If the Blub project is built with CMake then there should be no FindBlub
> for it at all.  It should just install BlubConfig.cmake and be done.
> Perhaps your work to make the files easier to write will help with that.

Yes, but people do that all the time.
I think I saw this for more or less every library which was written in KDE, 
and whenever I saw it I explained that distributing the Find-module together 
with the library doesn't make sense. I'm sure I didn't get all cases.

> The only reason to distribute FindBlub for a CMake-aware project is
> to wrap up find_package NO_MODULE to produce a nicer message, but that
> is totally optional.  If a project does want to distribute one for
> reference it should go in the -doc package, not in -dev, and should be
> put in share/doc/blub or the distro's equivalent.
> 
> > Additionally, the Config.cmake file feature of cmake is still relatively
> > unknown. It could use some more PR ;-)
> 
> I'll have to think about how to deal with that.
> 
> > By having to use NO_MODULE, or the other way round, if by not using
> > NO_MODULE it is clear to cmake that a Find-module is needed, it could
> > then print
> 
> > something like:
> Adding the explicit "MODULE" mode keyword could help with that.
> 
> >>   >  - search for FindFoo.cmake, use if found
> >>   >  - if not found, check new policy setting
> >>   >  - if not set, warn and follow OLD behavior
> >>   >  - if set to OLD, enter config mode and use current error if not
> >>   >  found - if set to NEW, present error about no FindFoo in module
> >>   >  path
> > 
> > Yes, exactly.
> 
> We can adjust it slightly to avoid the policy warning when FooConfig
> is found and Foo_DIR is set:
> 
>   - search for FindFoo.cmake, use if found
>   - if not found, check new policy setting
>   - if not set, enter config mode and emit both the policy warning
> and the current error if not found
>   - if set to OLD, enter config mode and use current error if not found
>   - if set to NEW, present error about no FindFoo in module path

Just to make sure I understand:
behave as described intially, but don't warn if the config file has been found 
via Foo_DIR.
Right ?
Ok with me.

> One problem with the policy is that it favors module mode as the "normal"
> case and makes "config" mode look like something special.  That will
> not help with the perception that the latter is preferred.

I actually prefer to have a simple 3 line wrapper Find-module within the 
project:
FindFoo.cmake:

find_package(Foo NO_MODULE)
fphsa(Foo CONFIG_MODE)
set_package_feature(Foo PROPERTIES PURPOSE "Enables something in this app"
   TYPE RECOMMENDED
   URL http://www.foo.org )

so people get a nice short result line during the cmake run and an informative 
summary at the end of the cmake run via FeatureSummary.cmake

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] CMake improve-findruby topic

[Brad King]

On 2/17/2012 12:09 PM, Rolf Eike Beer wrote:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=854e76237ce3e8f03d9cabcad1f8f37e04992ad3
commit 854e76237ce3e8f03d9cabcad1f8f37e04992ad3
Author: Rolf Eike Beer
AuthorDate: Fri Feb 17 18:06:07 2012 +0100
Commit: Rolf Eike Beer
CommitDate: Fri Feb 17 18:06:07 2012 +0100

 FindRuby: clean up querying variables from Ruby

 Newer Ruby versions (from 1.9 onward) seem to warn if you query 
Config::CONFIG
 and print a warning to use RbConfig instead. RbConfig seems to also work in
 older versions, at least in 1.8. Use a macro to query RbConfig first and 
only
 if that doesn't give anything fall back to Config.


Does this address

  http://www.cmake.org/Bug/view.php?id=12965

?

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] find_package error wording

[Brad King]

On 2/17/2012 12:09 PM, Alexander Neundorf wrote:

But another significant part of the reason is probably that beside upstreaming
a module to cmake, there is no other "official" way to distribute Find-
modules. So if somebody wrote a libblub, it is a relatively obvious choice to
install FindBlub.cmake as part of the library, so that whoever uses Blub, also
has FindBlub.cmake available.


If the Blub project is built with CMake then there should be no FindBlub
for it at all.  It should just install BlubConfig.cmake and be done.
Perhaps your work to make the files easier to write will help with that.

The only reason to distribute FindBlub for a CMake-aware project is
to wrap up find_package NO_MODULE to produce a nicer message, but that
is totally optional.  If a project does want to distribute one for
reference it should go in the -doc package, not in -dev, and should be
put in share/doc/blub or the distro's equivalent.


Additionally, the Config.cmake file feature of cmake is still relatively
unknown. It could use some more PR ;-)


I'll have to think about how to deal with that.


By having to use NO_MODULE, or the other way round, if by not using NO_MODULE
it is clear to cmake that a Find-module is needed, it could then print
something like:


Adding the explicit "MODULE" mode keyword could help with that.


  >  - search for FindFoo.cmake, use if found
  >  - if not found, check new policy setting
  >  - if not set, warn and follow OLD behavior
  >  - if set to OLD, enter config mode and use current error if not found
  >  - if set to NEW, present error about no FindFoo in module path


Yes, exactly.


We can adjust it slightly to avoid the policy warning when FooConfig
is found and Foo_DIR is set:

 - search for FindFoo.cmake, use if found
 - if not found, check new policy setting
 - if not set, enter config mode and emit both the policy warning
   and the current error if not found
 - if set to OLD, enter config mode and use current error if not found
 - if set to NEW, present error about no FindFoo in module path

One problem with the policy is that it favors module mode as the "normal"
case and makes "config" mode look like something special.  That will
not help with the perception that the latter is preferred.

-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] ninja spaces in the path do not work on linux

[Bill Hoffman]

On 2/17/2012 12:26 PM, Nicolas Desprès wrote:


I think it is a bug in the generator which do not escape the space
properly using the $ character as supported by Ninja.

--
Nicolas Desprès


Will you be able to fix that?


Thanks.

-Bill
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] ninja spaces in the path do not work on linux

[Nicolas Desprès]

On Wed, Feb 15, 2012 at 9:16 PM, Bill Hoffman wrote:

>
> -  On linux spaces in the path do not work, I get this error:
>
> http://www.cdash.org/CDash/**viewBuildError.php?buildid=**2009436
>
>
I think it is a bug in the generator which do not escape the space properly
using the $ character as supported by Ninja.

-- 
Nicolas Desprès
--

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] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Alexander Neundorf wrote:
...
> But another significant part of the reason is probably that beside
> upstreaming a module to cmake, there is no other "official" way to
> distribute Find- modules. So if somebody wrote a libblub, it is a
> relatively obvious choice to install FindBlub.cmake as part of the
> library, so that whoever uses Blub, also has FindBlub.cmake available.

I did not make that up, this email from Pau on the buildsystem list just 
arrived after I sent this email here:
http://lists.kde.org/?l=kde-buildsystem&m=132949736429566&w=2

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] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Brad King wrote:
> On 2/17/2012 11:37 AM, Alexander Neundorf wrote:
> >>> developers use Find modules.  Consider:
> >>>CMake Error at CMakeLists.txt:7 (find_package):
> >>>  No package configuration file for "ecm" found by names:
> >>>ecmConfig.cmake
> >>>ecm-config.cmake
> >>>  
> >>>  Add the installation prefix of "ecm" to CMAKE_PREFIX_PATH or
> >>>  set "ecm_DIR" to a directory containing one of the above files.
> >>>  
> >>>  (If you are a developer expecting this find_package to load a
> >>>  
> >>>   Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.)
> >> 
> >> I'm still not convinced.
> 
> Convinced of what?  I'm suggesting alternative wording for a change
> you just committed yourself.

Not convinced that splitting the error message this way is appropriate, and 
also not convinced that it is good that config-files are searched also without 
NO_MODULE.

> Whether to introduce the policy is another decision which should be
> resolved before any changes for this end up in master.
>
> > IOW: it's a quite common error to install a FindFoo.cmake as part of the
> > package Foo into the prefix where foo is installed.
> 
> Any suggestion how to correct this misconception?  There is no place
> in any of our documentation or tutorials on the wiki that suggests it.

I may be part of the problem.
We install a lot of Find-modules with kdelibs, so developers got the 
impression that this is a good thing to do, so they do this now too for their 
libraries.
But another significant part of the reason is probably that beside upstreaming 
a module to cmake, there is no other "official" way to distribute Find-
modules. So if somebody wrote a libblub, it is a relatively obvious choice to 
install FindBlub.cmake as part of the library, so that whoever uses Blub, also 
has FindBlub.cmake available.
Additionally, the Config.cmake file feature of cmake is still relatively 
unknown. It could use some more PR ;-)

(But what I did never do is to install FindKDE4.cmake as part of kdelibs, 
FindKDE4.cmake comes with cmake, so that is fine. And once you found kdelibs, 
it is ok to use the modules installed by kdelibs.)

By having to use NO_MODULE, or the other way round, if by not using NO_MODULE 
it is clear to cmake that a Find-module is needed, it could then print 
something like:

"Did not find FindFoo.cmake.
FindFoo.cmake must either be part of the project itself, in this case adjust 
CMAKE_MODULE_PATH so that it points to the correct location inside your source 
tree.
Or it must be installed by a package which has already been found via 
find_package(). In this case make sure that this package has indeed been found 
and adjust CMAKE_MODULE_PATH to contain the location where that package has 
installed FindFoo.cmake. This must be a variable provided by that package.
If you are developer of the current project, go fix your buildsystem !
If you are only building this project, tell the developers to fix their 
buildsystem !"

Well, something like this. ;-)

> > So if cmake knows that really the Find-module should have been found, it
> > can produce a very clear error message that the missing Find-module must
> > be part of the project itself or provided by another previously found
> > package, and that the buildsystem is broken.
> 
> This discussion relates to the introduction of the policy you proposed.
> Please comment on my question from yesterday:
>
> On 2/16/2012 11:57 AM, Brad King wrote:
>  > So your proposal when no extra find_package mode arg is given is:
>  > 
>  > - search for FindFoo.cmake, use if found
>  > - if not found, check new policy setting
>  > - if not set, warn and follow OLD behavior
>  > - if set to OLD, enter config mode and use current error if not found
>  > - if set to NEW, present error about no FindFoo in module path
>  > 
>  > ?
>  > 
>  > Separately the CONFIG and MODULE explicit mode args can be given
>  > to be alternative to NO_MODULE.

Yes, exactly.
I think I didn't answer explicitely because it seemed clear to me that this is 
exactly what I meant :-)

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] find_package error wording

[Brad King]

On 2/17/2012 11:37 AM, Alexander Neundorf wrote:

developers use Find modules.  Consider:
   CMake Error at CMakeLists.txt:7 (find_package):
 No package configuration file for "ecm" found by names:
   ecmConfig.cmake
   ecm-config.cmake

 Add the installation prefix of "ecm" to CMAKE_PREFIX_PATH or
 set "ecm_DIR" to a directory containing one of the above files.

 (If you are a developer expecting this find_package to load a

  Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.)


I'm still not convinced.


Convinced of what?  I'm suggesting alternative wording for a change
you just committed yourself.

Whether to introduce the policy is another decision which should be
resolved before any changes for this end up in master.


IOW: it's a quite common error to install a FindFoo.cmake as part of the
package Foo into the prefix where foo is installed.


Any suggestion how to correct this misconception?  There is no place
in any of our documentation or tutorials on the wiki that suggests it.


So if cmake knows that really the Find-module should have been found, it can
produce a very clear error message that the missing Find-module must be part
of the project itself or provided by another previously found package, and
that the buildsystem is broken.


This discussion relates to the introduction of the policy you proposed.
Please comment on my question from yesterday:

On 2/16/2012 11:57 AM, Brad King wrote:
> So your proposal when no extra find_package mode arg is given is:
>
> - search for FindFoo.cmake, use if found
> - if not found, check new policy setting
> - if not set, warn and follow OLD behavior
> - if set to OLD, enter config mode and use current error if not found
> - if set to NEW, present error about no FindFoo in module path
>
> ?
>
> Separately the CONFIG and MODULE explicit mode args can be given
> to be alternative to NO_MODULE.

-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] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Alexander Neundorf wrote:
> On Friday 17 February 2012, Brad King wrote:
...
> > Perhaps we can make the distinction between user and developer right
> > in the message.  When there is no Find module the proper message that
> > a user sees should talk about ecm_DIR and CMAKE_PREFIX_PATH only.
> > This should be the focus.  We can then add an extra note to help
> > 
> > developers use Find modules.  Consider:
> >   CMake Error at CMakeLists.txt:7 (find_package):
> > No package configuration file for "ecm" found by names:
> >   ecmConfig.cmake
> >   ecm-config.cmake
> > 
> > Add the installation prefix of "ecm" to CMAKE_PREFIX_PATH or
> > set "ecm_DIR" to a directory containing one of the above files.
> > 
> > (If you are a developer expecting this find_package to load a
> > 
> >  Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.)
> 
> I'm still not convinced.
> Just today I found this commit from last October in kdelibs:
> http://quickgit.kde.org/index.php?p=kdelibs.git&a=commitdiff&h=ca501aa9f4c1
> e7adcd42accbd53538502ba50ce3&hp=3186e7a5f3acfaa5b5ac1b5cce9315eb53f54655
> 
> Commit message: on win32 we need access to the installed cmake modules dir
> 
> --- a/cmake/modules/FindKDE4Internal.cmake
> +++ b/cmake/modules/FindKDE4Internal.cmake
> @@ -736,6 +736,7 @@ endif(${CMAKE_MAJOR_VERSION}.${CMAKE_MIN
>  option(KDE4_ENABLE_FPIE  "Enable platform supports PIE linking")
> 
>   if (WIN32)
> +   list(APPEND CMAKE_MODULE_PATH
>"${CMAKE_INSTALL_PREFIX}/share/apps/cmake/modules")
> find_package(KDEWin REQUIRED)
> option(KDE4_ENABLE_UAC_MANIFEST "add manifest to make..." OFF)
> if (KDE4_ENABLE_UAC_MANIFEST)
> 
> 
> This looks really wrong (I mean this directory is not guaranteed to exist
> at all at cmake time, so it can't help finding a module file), and it was
> committed by a developer who is using cmake now already since 2006 at
> least.
> 
> If I would build this, I would get exactly to case 1) - neither Find-module
> nor config-file found.
> As user I should assume that there should be a config file, and I should
> install the package or set CMAKE_PREFIX_PATH. But this wouldn't help,
> because actually the Find-module is missing, because in some way the
> buildsystem expects something wrong.
> So when I (as user) would assume the package is not installed because the
> config has not been found, I would be wrong, but I couldn't see this from
> the code.
> If config-file searching would have to be enabled, I would know from the
> error message (which would then say "Find-module not found") that the
> buildsystem is broken, and not some package is missing or
> CMAKE_PREFIX_PATH is not set.

IOW: it's a quite common error to install a FindFoo.cmake as part of the 
package Foo into the prefix where foo is installed.

So if cmake knows that really the Find-module should have been found, it can 
produce a very clear error message that the missing Find-module must be part 
of the project itself or provided by another previously found package, and 
that the buildsystem is broken.

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 0012965]: FindRuby.cmake uses an incorrect method to detect if vendor directory is available.

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=12965 
== 
Reported By:Thomas Dziedzic
Assigned To:
== 
Project:CMake
Issue ID:   12965
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-02-17 11:18 EST
Last Modified:  2012-02-17 11:18 EST
== 
Summary:FindRuby.cmake uses an incorrect method to detect if
vendor directory is available.
Description: 
I'm specifically talking about the following line:
http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindRuby.cmake;h=c4adfd1ee985a4f147796da654fa0b97fe61ee2f;hb=HEAD#l98

It seems that opensuse is the only distro shipping a vendor-specific.rb file
which is not a standard ruby convention. Archlinux, Debian, probably no other
distro uses this except Opensuse.

I emailed the opensuse ruby maintainer and he indeed said vendor-specific.rb was
only introduced from macports. You should be checking if the following variables
exist in ruby:

RbConfig::CONFIG['vendordir']
RbConfig::CONFIG['vendorlibdir']
RbConfig::CONFIG['vendorarchdir']
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-02-17 11:18 Thomas DziedzicNew 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] Modifying RPATH feature to run tests uninstalled

[Brad King]

On 2/17/2012 9:31 AM, Alexander Neundorf wrote:

Yes, but this could be done already right now.
We (KDE) could add an option(), which when enabled sets CMAKE_INSTALL_RPATH
empty, and CMAKE_INSTALL_RPATH_USE_LINK_PATH to FALSE. This would be the same
effect.

CMAKE_SKIP_RPATH is intentionally for people who just want to disable RPATH no
matter what the project does.

...maybe we (KDE) could do:

if(CMAKE_SKIP_RPATH)
   set(CMAKE_SKIP_RPATH FALSE)
   set(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE)
   set(CMAKE_INSTALL_RPATH "")
endif()


As I said in parallel to your response I'd prefer that distros
use a hammer like CMAKE_SKIP_INSTALL_RPATH so they do not have
to depend on the project supporting it with code like the above.
I'd like to discourage them from using CMAKE_SKIP_RPATH because
it is a pain for testing.

Of course your approach doesn't depend on any new CMake changes
so you can use it right now to get started.

-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

[Brad King]

On 2/17/2012 9:27 AM, Stephen Kelly wrote:

Then add SetPropertyDefault in the initialization of EXECUTABLE targets
so that

set(CMAKE_GUI_EXECUTABLE 1)

will change the default for new executable targets in scope of the
variable.


Yes, I had the same idea last night after emailing.

I can implement that.


Great.  On second thought I wonder if a better name for the property
is "EXECUTABLE_GUI" since that uses the prefix "EXECUTABLE_" which
can be re-used later for other properties that are specific to
executable targets.  Then one could write

  set(CMAKE_EXECUTABLE_GUI 1)

for the variable version and "CMAKE_EXECUTABLE_" is the prefix for
settings related to executables.

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

[Alexander Neundorf]

On Friday 17 February 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Friday 17 February 2012, Stephen Kelly wrote:
> > ...
> > 
> >> The other issue is regarding setting RPATH for the build step and not
> >> the install step, and what syntax should be used for that.
> >> 
> >> The options are:
> >> 
> >> a) Change the behaviour of CMAKE_SKIP_RPATH to set the RPATH in the
> >> build
> >> 
> >>dir (does this need a policy)
> >> 
> >> b) Add the new variable CMAKE_SKIP_INSTALL_RPATH to skip only the
> >> 
> >>installation RPATH, but do use it for the build step. (Fits with
> >> 
> >> existing CMAKE_SKIP_BUILD_RPATH)
> >> 
> >> c) Make the existing CMAKE_SKIP_BUILD_RPATH override CMAKE_SKIP_RPATH if
> >> set to false. (This probably would need a policy)
> >> 
> >> My choice is b), but I don't know if there are good reasons for the
> >> others.
> > 
> > I'm not sure this would help a lot.
> > Some people (distro packagers) disable RPATH by setting CMAKE_SKIP_RPATH
> > to TRUE.
> > CMAKE_SKIP_RPATH is the big switch which overrides all others. So if this
> > is used, we would still have no RPATH in the build tree.
> 
> Are you saying this is a chicken-egg problem?
> 
> If CMAKE_SKIP_INSTALL_RPATH is used by our buildsystems and
> CMAKE_SKIP_RPATH is not, distros will learn that they can run unit tests
> if they build their packages with the former instead of the latter.
> 
> From my point of view though, the ENVIRONMENT property manipulation solves
> enough of the problem already. It makes 'make test' work.
> 
> What it doesn't fix is running a unit test executable directly without
> setting the environment manually or running make install. I don't see why
> that should be expected to work though if the developer disables the RPATH
> stuff. It also doesn't work currently (without wrapper scripts), so nothing
> is really lost.
> 
> However, adding CMAKE_SKIP_INSTALL_RPATH would make that work even if a
> developer wanted to disable RPATH, so maybe it's a nice thing to do.

Yes, but this could be done already right now.
We (KDE) could add an option(), which when enabled sets CMAKE_INSTALL_RPATH 
empty, and CMAKE_INSTALL_RPATH_USE_LINK_PATH to FALSE. This would be the same 
effect.

CMAKE_SKIP_RPATH is intentionally for people who just want to disable RPATH no 
matter what the project does.

...maybe we (KDE) could do:

if(CMAKE_SKIP_RPATH)
  set(CMAKE_SKIP_RPATH FALSE)
  set(CMAKE_INSTALL_RPATH_USE_LINK_PATH FALSE)
  set(CMAKE_INSTALL_RPATH "")
endif()

... I didn't say that loud, did I ? ;-)

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

[Brad King]

On 2/17/2012 9:13 AM, Stephen Kelly wrote:

If CMAKE_SKIP_INSTALL_RPATH is used by our buildsystems and CMAKE_SKIP_RPATH
is not, distros will learn that they can run unit tests if they build their
packages with the former instead of the latter.

 From my point of view though, the ENVIRONMENT property manipulation solves
enough of the problem already. It makes 'make test' work.

What it doesn't fix is running a unit test executable directly without
setting the environment manually or running make install. I don't see why
that should be expected to work though if the developer disables the RPATH
stuff. It also doesn't work currently (without wrapper scripts), so nothing
is really lost.

However, adding CMAKE_SKIP_INSTALL_RPATH would make that work even if a
developer wanted to disable RPATH, so maybe it's a nice thing to do.


This is achievable by project code if it never sets INSTALL_RPATH.
However it can be convenient for distros to have a "hammer" like
CMAKE_SKIP_INSTALL_RPATH to avoid patching uncooperative projects.

Distros are using CMAKE_SKIP_RPATH as that hammer now, and it's a
pain for tests.  I think CMAKE_SKIP_INSTALL_RPATH is the right
balance.  It allows tests to run and distros to avoid RPATH in
their packages.

-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] find_package error wording

[Alexander Neundorf]

On Friday 17 February 2012, Brad King wrote:
> On 2/17/2012 4:29 AM, Alexander Neundorf wrote:
>  > I collected the various error messages which can be produced in the
>  > different cases:
>  > * package not found
>  > * package found, but version doesn't match
>  > 
>  > * REQUIRED
>  > * without REQUIRED
>  > 
>  > * find_package() with no Find-module present
>  > * find_package(NO_MODULE)
>  > 
>  > * find_package() with a wrapper Find-module which does:
>  >   find_package(ecm QUIET NO_MODULE)
>  >   fphsa(ecm CONFIG_MODE)
> 
> Nice.  Can you code this into a test in the Tests/CMakeOnly directory?
> That way we will have a single place to reference to see all the current
> error messages and we will know if things change accidentally.

I'll try to.
 
> On 2/17/2012 5:48 AM, Alexander Neundorf wrote:
> > These three points and a small bug fix (error message was not printed at
> > all for an invalid CONFIGS name) are now in the
> > FindPackage_ImprovedErrorMessages branch and merged into next.
> 
>  From your commit message:
>  > CMake Error at CMakeLists.txt:7 (find_package):
>  >   Could not find module Findecm.cmake or a configuration file
>  >   
>  >   for package ecm with one of the following names:
>  > ecmConfig.cmake
>  > ecm-config.cmake
>  >   
>  >   Adjust CMAKE_MODULE_PATH to find Findecm.cmake.  To find
>  >   the configuration file, set CMAKE_PREFIX_PATH to the installation
>  >   prefix of ecm, or set ecm_DIR to the directory
>  >   containing a CMake configuration file for ecm.
> 
> Perhaps we can make the distinction between user and developer right
> in the message.  When there is no Find module the proper message that
> a user sees should talk about ecm_DIR and CMAKE_PREFIX_PATH only.
> This should be the focus.  We can then add an extra note to help
> developers use Find modules.  Consider:
> 
>   CMake Error at CMakeLists.txt:7 (find_package):
> No package configuration file for "ecm" found by names:
> 
>   ecmConfig.cmake
>   ecm-config.cmake
> 
> Add the installation prefix of "ecm" to CMAKE_PREFIX_PATH or
> set "ecm_DIR" to a directory containing one of the above files.
> 
> (If you are a developer expecting this find_package to load a
>  Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.)


I'm still not convinced.
Just today I found this commit from last October in kdelibs:
http://quickgit.kde.org/index.php?p=kdelibs.git&a=commitdiff&h=ca501aa9f4c1e7adcd42accbd53538502ba50ce3&hp=3186e7a5f3acfaa5b5ac1b5cce9315eb53f54655

Commit message: on win32 we need access to the installed cmake modules dir 
 
--- a/cmake/modules/FindKDE4Internal.cmake
+++ b/cmake/modules/FindKDE4Internal.cmake
@@ -736,6 +736,7 @@ endif(${CMAKE_MAJOR_VERSION}.${CMAKE_MIN
 option(KDE4_ENABLE_FPIE  "Enable platform supports PIE linking")
 
  if (WIN32)
+   list(APPEND CMAKE_MODULE_PATH
   "${CMAKE_INSTALL_PREFIX}/share/apps/cmake/modules")
find_package(KDEWin REQUIRED)
option(KDE4_ENABLE_UAC_MANIFEST "add manifest to make..." OFF)
if (KDE4_ENABLE_UAC_MANIFEST)


This looks really wrong (I mean this directory is not guaranteed to exist at 
all at cmake time, so it can't help finding a module file), and it was 
committed by a developer who is using cmake now already since 2006 at least.

If I would build this, I would get exactly to case 1) - neither Find-module 
nor config-file found.
As user I should assume that there should be a config file, and I should 
install the package or set CMAKE_PREFIX_PATH. But this wouldn't help, because 
actually the Find-module is missing, because in some way the buildsystem 
expects something wrong.
So when I (as user) would assume the package is not installed because the 
config has not been found, I would be wrong, but I couldn't see this from the 
code.
If config-file searching would have to be enabled, I would know from the error 
message (which would then say "Find-module not found") that the buildsystem is 
broken, and not some package is missing or CMAKE_PREFIX_PATH is not set.

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

[Stephen Kelly]

Brad King wrote:

> On 2/17/2012 5:44 AM, Stephen Kelly wrote:
>> I meant 'default' in the sense of
>> cmTarget::SetPropertyDefault, in the same way that set(CMAKE_AUTOMOC ON)
>> sets the AUTOMOC property to true by default for all targets that follow.
> [snip]
>> default value of the property *if* set(CMAKE_CREATE_GUI_EXECUTABLES) is
>> ON.
> 
> Instead of a special behavior for WIN32_EXECUTABLE and MACOSX_BUNDLE
> property defaults, consider creating a new property that generalizes
> the concept, such as "GUI_EXECUTABLE".  Teach the code and update the
> documentation to specify that the property implies WIN32_EXECUTABLE
> and MACOSX_BUNDLE on the respective platforms.
> 
> Then add SetPropertyDefault in the initialization of EXECUTABLE targets
> so that
> 
>set(CMAKE_GUI_EXECUTABLE 1)
> 
> will change the default for new executable targets in scope of the
> variable.

Yes, I had the same idea last night after emailing.

I can implement that.

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 2/17/2012 5:44 AM, Stephen Kelly wrote:

I meant 'default' in the sense of
cmTarget::SetPropertyDefault, in the same way that set(CMAKE_AUTOMOC ON)
sets the AUTOMOC property to true by default for all targets that follow.

[snip]

default value of the property *if* set(CMAKE_CREATE_GUI_EXECUTABLES) is ON.


Instead of a special behavior for WIN32_EXECUTABLE and MACOSX_BUNDLE
property defaults, consider creating a new property that generalizes
the concept, such as "GUI_EXECUTABLE".  Teach the code and update the
documentation to specify that the property implies WIN32_EXECUTABLE
and MACOSX_BUNDLE on the respective platforms.

Then add SetPropertyDefault in the initialization of EXECUTABLE targets
so that

  set(CMAKE_GUI_EXECUTABLE 1)

will change the default for new executable targets in scope of the
variable.

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

Alexander Neundorf wrote:

> On Friday 17 February 2012, Stephen Kelly wrote:
> ...
>> The other issue is regarding setting RPATH for the build step and not the
>> install step, and what syntax should be used for that.
>> 
>> The options are:
>> 
>> a) Change the behaviour of CMAKE_SKIP_RPATH to set the RPATH in the build
>>dir (does this need a policy)
>> 
>> b) Add the new variable CMAKE_SKIP_INSTALL_RPATH to skip only the
>>installation RPATH, but do use it for the build step. (Fits with
>> existing CMAKE_SKIP_BUILD_RPATH)
>> 
>> c) Make the existing CMAKE_SKIP_BUILD_RPATH override CMAKE_SKIP_RPATH if
>> set to false. (This probably would need a policy)
>> 
>> My choice is b), but I don't know if there are good reasons for the
>> others.
> 
> I'm not sure this would help a lot.
> Some people (distro packagers) disable RPATH by setting CMAKE_SKIP_RPATH
> to TRUE.
> CMAKE_SKIP_RPATH is the big switch which overrides all others. So if this
> is used, we would still have no RPATH in the build tree.
> 

Are you saying this is a chicken-egg problem?

If CMAKE_SKIP_INSTALL_RPATH is used by our buildsystems and CMAKE_SKIP_RPATH 
is not, distros will learn that they can run unit tests if they build their 
packages with the former instead of the latter.

>From my point of view though, the ENVIRONMENT property manipulation solves 
enough of the problem already. It makes 'make test' work. 

What it doesn't fix is running a unit test executable directly without 
setting the environment manually or running make install. I don't see why 
that should be expected to work though if the developer disables the RPATH 
stuff. It also doesn't work currently (without wrapper scripts), so nothing 
is really lost.

However, adding CMAKE_SKIP_INSTALL_RPATH would make that work even if a 
developer wanted to disable RPATH, so maybe it's a nice thing to do.

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] find_package error wording

[Brad King]

On 2/17/2012 4:29 AM, Alexander Neundorf wrote:
> I collected the various error messages which can be produced in the different
> cases:
> * package not found
> * package found, but version doesn't match
>
> * REQUIRED
> * without REQUIRED
>
> * find_package() with no Find-module present
> * find_package(NO_MODULE)
> * find_package() with a wrapper Find-module which does:
>   find_package(ecm QUIET NO_MODULE)
>   fphsa(ecm CONFIG_MODE)

Nice.  Can you code this into a test in the Tests/CMakeOnly directory?
That way we will have a single place to reference to see all the current
error messages and we will know if things change accidentally.

On 2/17/2012 5:48 AM, Alexander Neundorf wrote:

These three points and a small bug fix (error message was not printed at all
for an invalid CONFIGS name) are now in the FindPackage_ImprovedErrorMessages
branch and merged into next.


From your commit message:

> CMake Error at CMakeLists.txt:7 (find_package):
>   Could not find module Findecm.cmake or a configuration file
>   for package ecm with one of the following names:
>
> ecmConfig.cmake
> ecm-config.cmake
>
>   Adjust CMAKE_MODULE_PATH to find Findecm.cmake.  To find
>   the configuration file, set CMAKE_PREFIX_PATH to the installation prefix of
>   ecm, or set ecm_DIR to the directory
>   containing a CMake configuration file for ecm.

Perhaps we can make the distinction between user and developer right
in the message.  When there is no Find module the proper message that
a user sees should talk about ecm_DIR and CMAKE_PREFIX_PATH only.
This should be the focus.  We can then add an extra note to help
developers use Find modules.  Consider:

 CMake Error at CMakeLists.txt:7 (find_package):
   No package configuration file for "ecm" found by names:

 ecmConfig.cmake
 ecm-config.cmake

   Add the installation prefix of "ecm" to CMAKE_PREFIX_PATH or
   set "ecm_DIR" to a directory containing one of the above files.

   (If you are a developer expecting this find_package to load a
Findecm.cmake module then ensure it lies in CMAKE_MODULE_PATH.)

-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] Bad error message when a package could not be found - make find_package() not search config files by default

[Brad King]

On 2/17/2012 5:07 AM, Alexander Neundorf wrote:

The documentation page says: "The REQUIRED option stops processing with an
error message if the package cannot be found."

I interpret this as "stops processing immediately".


This has always been the intended meaning.  The idea is that code following
the line can be written without checking whether the package was FOUND
and assume certain variables are set.  If you want other behavior then
do not pass REQUIRED and check if(...FOUND) manually.

-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

[Alexander Neundorf]

On Friday 17 February 2012, Stephen Kelly wrote:
...
> The other issue is regarding setting RPATH for the build step and not the
> install step, and what syntax should be used for that.
> 
> The options are:
> 
> a) Change the behaviour of CMAKE_SKIP_RPATH to set the RPATH in the build
>dir (does this need a policy)
> 
> b) Add the new variable CMAKE_SKIP_INSTALL_RPATH to skip only the
>installation RPATH, but do use it for the build step. (Fits with
> existing CMAKE_SKIP_BUILD_RPATH)
> 
> c) Make the existing CMAKE_SKIP_BUILD_RPATH override CMAKE_SKIP_RPATH if
> set to false. (This probably would need a policy)
> 
> My choice is b), but I don't know if there are good reasons for the others.

I'm not sure this would help a lot.
Some people (distro packagers) disable RPATH by setting CMAKE_SKIP_RPATH to 
TRUE.
CMAKE_SKIP_RPATH is the big switch which overrides all others. So if this is 
used, we would still have no RPATH in the build tree.

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]

Eric Noulard wrote:

> 2012/2/17 Stephen Kelly
> :
>> Marcel Loose wrote:
>>
>>> Hi Stephen,
>>>
>>> On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
>>>
>>> -- 8<  8<  8<  8<  8<  8<  8<  8<  8< --
>>>
 diff --git a/templates/tests/CMakeLists.txt
>>> b/templates/tests/CMakeLists.txt
 index d2e37d2..ad471c7 100644
 --- a/templates/tests/CMakeLists.txt
 +++ b/templates/tests/CMakeLists.txt
 @@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
 ${_testresource_rcc_src}
 )
 add_test(${_testname} ${_testname}_exec )
 +set_property(TEST ${testname} PROPERTY ENVIRONMENT
 "LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib")


 Do you see anything wrong there?
>>>
>>> You should use ${_testname} in the set_property() command. Don't you get
>>> an error message from CMake? Or do you happen to have a variable
>>> "testname" as well.
>>>
>>
>> D'Oh! You're right. I typo'd there. It works with my system Qt if I fix
>> the typo.
>>
>> However, it doesn't solve the whole problem for me. Mostly I use a Qt in
>> a non-standard prefix and I set LD_LIBRARY_PATH to find it (I have many
>> Qts and a script to change my environment)
>>
>> I tried changing it to
>> set_property(TEST ${_testname} PROPERTY ENVIRONMENT
>> "LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${CMAKE_BINARY_DIR}/templates/lib")
>>
>> ie appending to the LD_LIBRARY_PATH, and it didn't find the correct Qt.
> 
> I'm not sure it'll append using this shell-like syntax, which suppose
> shell-like evaluation for "$LD_LIBRARY_PATH".
> 
> Could you try
> LD_LIBRARY_PATH=$ENV{LD_LIBRARY_PATH}:${CMAKE_BINARY_DIR}/templates/lib"
> instead, which uses the CMake variable syntax to access environment.

Yes, that works fine as expected, thanks!

> 
>> Is that something relevant for others that we should care about? Or is my
>> setup unusual and irrelevant? Is it a bug that the LD_LIBRARY_PATH from
>> my environment is not carried over?
> 
> Does you initial environment export LD_LIBRARY_PATH or not (simple set) ?
> 

It is exported.

So that resolves one of the two issues I posted about. 

The other issue is regarding setting RPATH for the build step and not the 
install step, and what syntax should be used for that. 

The options are:

a) Change the behaviour of CMAKE_SKIP_RPATH to set the RPATH in the build
   dir (does this need a policy)

b) Add the new variable CMAKE_SKIP_INSTALL_RPATH to skip only the 
   installation RPATH, but do use it for the build step. (Fits with existing 
CMAKE_SKIP_BUILD_RPATH)

c) Make the existing CMAKE_SKIP_BUILD_RPATH override CMAKE_SKIP_RPATH if set 
   to false. (This probably would need a policy)

My choice is b), but I don't know if there are good reasons for the others.


--

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

[Eric Noulard]

2012/2/17 Stephen Kelly :
> Marcel Loose wrote:
>
>> Hi Stephen,
>>
>> On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
>>
>> -- 8<  8<  8<  8<  8<  8<  8<  8<  8< --
>>
>>> diff --git a/templates/tests/CMakeLists.txt
>> b/templates/tests/CMakeLists.txt
>>> index d2e37d2..ad471c7 100644
>>> --- a/templates/tests/CMakeLists.txt
>>> +++ b/templates/tests/CMakeLists.txt
>>> @@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
>>>                    ${_testresource_rcc_src}
>>>      )
>>>      add_test(${_testname} ${_testname}_exec )
>>> +    set_property(TEST ${testname} PROPERTY ENVIRONMENT
>>> "LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib")
>>>
>>>
>>> Do you see anything wrong there?
>>
>> You should use ${_testname} in the set_property() command. Don't you get
>> an error message from CMake? Or do you happen to have a variable
>> "testname" as well.
>>
>
> D'Oh! You're right. I typo'd there. It works with my system Qt if I fix the
> typo.
>
> However, it doesn't solve the whole problem for me. Mostly I use a Qt in a
> non-standard prefix and I set LD_LIBRARY_PATH to find it (I have many Qts
> and a script to change my environment)
>
> I tried changing it to
>    set_property(TEST ${_testname} PROPERTY ENVIRONMENT
> "LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${CMAKE_BINARY_DIR}/templates/lib")
>
> ie appending to the LD_LIBRARY_PATH, and it didn't find the correct Qt.

I'm not sure it'll append using this shell-like syntax, which suppose
shell-like evaluation for "$LD_LIBRARY_PATH".

Could you try
LD_LIBRARY_PATH=$ENV{LD_LIBRARY_PATH}:${CMAKE_BINARY_DIR}/templates/lib"
instead, which uses the CMake variable syntax to access environment.

> Is that something relevant for others that we should care about? Or is my
> setup unusual and irrelevant? Is it a bug that the LD_LIBRARY_PATH from my
> environment is not carried over?

Does you initial environment export LD_LIBRARY_PATH or not (simple set) ?

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

Powered by www.kitware.com

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

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

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

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

[Stephen Kelly]

Marcel Loose wrote:

> Hi Stephen,
> 
> On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
> 
> -- 8<  8<  8<  8<  8<  8<  8<  8<  8< --
> 
>> diff --git a/templates/tests/CMakeLists.txt
> b/templates/tests/CMakeLists.txt
>> index d2e37d2..ad471c7 100644
>> --- a/templates/tests/CMakeLists.txt
>> +++ b/templates/tests/CMakeLists.txt
>> @@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
>>${_testresource_rcc_src}
>>  )
>>  add_test(${_testname} ${_testname}_exec )
>> +set_property(TEST ${testname} PROPERTY ENVIRONMENT
>> "LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib")
>> 
>> 
>> Do you see anything wrong there?
> 
> You should use ${_testname} in the set_property() command. Don't you get
> an error message from CMake? Or do you happen to have a variable
> "testname" as well.
> 

D'Oh! You're right. I typo'd there. It works with my system Qt if I fix the 
typo.

However, it doesn't solve the whole problem for me. Mostly I use a Qt in a 
non-standard prefix and I set LD_LIBRARY_PATH to find it (I have many Qts 
and a script to change my environment)

I tried changing it to 
set_property(TEST ${_testname} PROPERTY ENVIRONMENT 
"LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${CMAKE_BINARY_DIR}/templates/lib")

ie appending to the LD_LIBRARY_PATH, and it didn't find the correct Qt. It 
found my system Qt (4.7) instead of my environment Qt (4.8) which has new 
methods and so I get symbol lookup errors.

Is that something relevant for others that we should care about? Or is my 
setup unusual and irrelevant? Is it a bug that the LD_LIBRARY_PATH from my 
environment is not carried over?

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

[Marcel Loose]

Hi Stephen,

On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:

-- 8<  8<  8<  8<  8<  8<  8<  8<  8< --

> diff --git a/templates/tests/CMakeLists.txt
b/templates/tests/CMakeLists.txt
> index d2e37d2..ad471c7 100644
> --- a/templates/tests/CMakeLists.txt
> +++ b/templates/tests/CMakeLists.txt
> @@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
>${_testresource_rcc_src}
>  )
>  add_test(${_testname} ${_testname}_exec )
> +set_property(TEST ${testname} PROPERTY ENVIRONMENT 
> "LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib")
> 
> 
> Do you see anything wrong there?

You should use ${_testname} in the set_property() command. Don't you get
an error message from CMake? Or do you happen to have a variable
"testname" as well.

> 
> Thanks,
> 
> Steve.

Cheers,
Marcel.


--

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]

Marcel Loose wrote:

> Hi,
> 
> On Fri, 2012-02-17 at 08:51 +0100, Alexander Neundorf wrote:
> 
> -- 8<  8<  8<  8<  8<  8<  8<  8<  8< --
> 
>> > So the suggestion is
>> > 
>> > a) Change CMAKE_SKIP_RPATH to only skip RPATH when installing, but
> not when
>> > building (I don't know if that's easy in CMake), or alternatively
> provide
>> > another CMAKE_ variable to do that.
>> > 
>> > b) Implement something like:
>> > set_property(TARGET foo APPEND PROPERTY TEST_ENVIRONMENT "foo=bar")
>> > 
>> > 
>> > Possibly both a) and b).
>> > 
>> > Thoughts/comments?
>> 
>> b) is IMO definitely a missing feature.
>> (but even with that, we (KDE) would have to keep a macro, because we
> can't
>> expect that all developers know how to set this properly for all
> platforms.
>> ...or, since it is a target property, this could be also intialized
> from a
>> CMAKE_TEST_ENVIRONMENT cmake variable).
> 
> Maybe I'm missing the point but there is a property ENVIRONMENT for
> tests:
> http://cmake.org/cmake/help/cmake-2-8-docs.html#prop_test:ENVIRONMENT

That indeed looks like what was discussed in one of the links I posted.

However I tried it out and it didn't work for me (with CMAKE_SKIP_RPATH):
 
stephen@hal:~/dev/build/qt/grantlee$ LD_LIBRARY_PATH=$PWD/templates/lib 
./templates/tests/testsafestring_exec 
* Start testing of TestSafeString *
Config: Using QTest library 4.7.4, Qt 4.7.4
PASS   : TestSafeString::initTestCase()
PASS   : TestSafeString::testCombining()
PASS   : TestSafeString::testAppending()
PASS   : TestSafeString::testChopping()
PASS   : TestSafeString::testReplacing()
PASS   : TestSafeString::cleanupTestCase()
Totals: 6 passed, 0 failed, 0 skipped
* Finished testing of TestSafeString *
Qt( ) KDE ( ) 
stephen@hal:~/dev/build/qt/grantlee$ ctest -V .
UpdateCTestConfiguration  from 
:/home/stephen/dev/build/qt/grantlee/DartConfiguration.tcl
Parse Config file:/home/stephen/dev/build/qt/grantlee/DartConfiguration.tcl
UpdateCTestConfiguration  from 
:/home/stephen/dev/build/qt/grantlee/DartConfiguration.tcl
Parse Config file:/home/stephen/dev/build/qt/grantlee/DartConfiguration.tcl
Test project /home/stephen/dev/build/qt/grantlee
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 1
  Start  1: testsafestring

1: Test command: 
/home/stephen/dev/build/qt/grantlee/templates/tests/testsafestring_exec
1: Test timeout computed to be: 1500
1: /home/stephen/dev/build/qt/grantlee/templates/tests/testsafestring_exec: 
error while loading shared libraries: libgrantlee_core.so.0: cannot open 
shared object file: No such file or directory
 1/11 Test  #1: testsafestring ...***Failed0.00 sec
Qt( ) KDE ( ) 
stephen@hal:~/dev/src/grantlee{master}$ git diff 
diff --git a/templates/tests/CMakeLists.txt b/templates/tests/CMakeLists.txt
index d2e37d2..ad471c7 100644
--- a/templates/tests/CMakeLists.txt
+++ b/templates/tests/CMakeLists.txt
@@ -83,6 +83,7 @@ macro(GRANTLEE_TEMPLATES_UNIT_TESTS)
   ${_testresource_rcc_src}
 )
 add_test(${_testname} ${_testname}_exec )
+set_property(TEST ${testname} PROPERTY ENVIRONMENT 
"LD_LIBRARY_PATH=${CMAKE_BINARY_DIR}/templates/lib")


Do you see anything wrong there?

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

[Alexander Neundorf]

On Thursday 16 February 2012, Brad King wrote:
> On 2/16/2012 1:24 PM, Alexander Neundorf wrote:
> > Actually I expected I would prefer this over the fixed names, but now
> > that I've done it and look at what Config.cmake.in file I have to write,
> > I think I liked the previous version with the fixed names
> > (CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
> 
> I think the fixed names are better/simpler too.  I'm not fond of
> "CONFIG_HELPER" specifically.  The information stored in them is
> about the *package* that the file is configuring, which is why
> I originally proposed the prefix "PACKAGE_".  The INCLUDE_INSTALL_DIR
> is where the *package* goes, not where the config helper is/goes.
> 
> It's also the same as the package version file input/output
> variable names.

I looked a bit around cmFindPackage.
It has a parameter "CONFIGS", it has a "Config mode" and the documentation and 
error messages use "configuration file".
So, I'm not that sure that using "PACKAGE" instead of "CONFIG" is really 
better (the branch I pushed uses "PACKAGE", but I could change this again).

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] Bad error message when a package could not be found - make find_package() not search config files by default

[Alexander Neundorf]

On Friday 17 February 2012, Alexander Neundorf wrote:
...
> What should be improved:
...
> 2.) CMAKE_PREFIX_PATH should be mentioned
> 
> 1.), 2.) if a version number was used, this should be printed in the error
> message
> 
> 1.) CMAKE_PREFIX_PATH should be mentioned at least.

These three points and a small bug fix (error message was not printed at all 
for an invalid CONFIGS name) are now in the FindPackage_ImprovedErrorMessages 
branch and merged into next.

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

[Stephen Kelly]

Eric Noulard wrote:

> 2012/2/17 Stephen Kelly
> :
>>
>> Hi there,
>>
>> Also in this thread one of the discussion topics was making CMake default
>> to creating Gui-ready executables. That is, setting the WIN32_EXECUTABLE
>> or MACOSX_BUNDLE property on the executable target.
>>
>> http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6961/focus=7005
>>
>> By default CMake does not set those properties, which is actually
>> uncommon. Generally in KDE at least, only unit tests and some small
>> utilities are non- gui executables.
>>
>> We'd like to be able to specify with a defaultProperty something like
>>
>> set(CMAKE_CREATE_GUI_EXECUTABLES ON)
> 
> You probably mean:
> 
> set_property(GLOBAL PROPERTY CMAKE_CREATE_GUI_EXECUTABLES ON)

Nope, I meant the one I wrote. It'a similar to, eg, set(CMAKE_AUTOMOC ON) 
and many others.

> 
>> which would set those target properties to True on the Windows and Mac
>> platforms by default. For unit tests, we could then disable it again.
>>
>> Thoughts/comments?
> 
> I have [at least] one project which build on Windows where some
> applications (not test)
> are not GUI apps. In fact those applications are seldom launched by
> the user because
> they are "forked" by some GUI apps.
> 
> If this was set by default would my apps still be working as expected?

If you change nothing they will continue to work as expected.

If you add set(CMAKE_CREATE_GUI_EXECUTABLES ON) then you would have to use 
set_target_property(foo WIN32_EXECUTABLE 0) on the non-gui executable in the 
project.

Note that I think I caused confusion for you when I wrote 'by default'. I 
didn't actually mean that CMake should change its default behaviour in a 
source incompatible way. I meant 'default' in the sense of 
cmTarget::SetPropertyDefault, in the same way that set(CMAKE_AUTOMOC ON) 
sets the AUTOMOC property to true by default for all targets that follow.

> or shall I
> put "NON-GUI" properties on them?
> 
> If this was to be introduced I bet the default value of the property
> should be OFF (or not SET)
> for backward compatibility reason.

Of course. I don't intend to change the default behaviour of CMake, just the 
default value of the property *if* set(CMAKE_CREATE_GUI_EXECUTABLES) is ON.

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] Bad error message when a package could not be found - make find_package() not search config files by default

[Alexander Neundorf]

On Friday 17 February 2012, Rolf Eike Beer wrote:
> > On Thursday 16 February 2012, Alexander Neundorf wrote:
...
> > What should be improved:
> > 1.), 2.), 4.)  processing should stop if REQUIRED was used
> 
> I disagree. Say I want to build $random package. Throw the source
> somewhere, run cmake. Now I see the errors and install the packages that
> are missing. If processing immediately stops on an unmet dependency I
> would have to repeat that as long as there are unmet dependencies. If
> processing continues but gives and error I can install all things at once.

Well, at least it is inconsistent with the behaviour of all Find-modules.
They all stop with FATAL_ERROR if a REQUIRED package was not found.

The documentation page says: "The REQUIRED option stops processing with an 
error message if the package cannot be found."

I interpret this as "stops processing immediately".
This is what find_package_handle_standard_args() does.

If this is not the intended meaning, then all the Find-modules (mostly 
FindPackageHandleStandardArgs) should be changed to use SEND_ERROR instead of 
FATAL_ERROR.

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] Bad error message when a package could not be found - make find_package() not search config files by default

[Rolf Eike Beer]

> On Thursday 16 February 2012, Alexander Neundorf wrote:
>> Hi,
>>
>> when I use a Find-module to search for a package, I get a nice error
>> message if the package could not be found.
>
> I collected the various error messages which can be produced in the
> different
> cases:
> * package not found
> * package found, but version doesn't match
>
> * REQUIRED
> * without REQUIRED
>
> * find_package() with no Find-module present
> * find_package(NO_MODULE)
> * find_package() with a wrapper Find-module which does:
>  find_package(ecm QUIET NO_MODULE)
>  fphsa(ecm CONFIG_MODE)
>
>
> Here we go:
>
> package not found, REQUIRED:
>
> 
> 1.) find_package() with no Find-module present:
>
> CMake Error at CMakeLists.txt:4 (find_package):
>   Could not find module Findecm.cmake or a configuration file
>   for package ecm.
>
>   Adjust CMAKE_MODULE_PATH to find Findecm.cmake or set
>   ecm_DIR to the directory containing a CMake configuration
>   file for ecm.  The file will have one of the following
>   names:
>
> ecmConfig.cmake
> ecm-config.cmake
> * processing continues, but with error
>
>
> 
> 2.) find_package(NO_MODULE):
>
> CMake Error at CMakeLists.txt:4 (find_package):
>   Could not find a configuration file for package ecm.
>
>   Set ecm_DIR to the directory containing a CMake
>   configuration file for ecm.  The file will have one of the
>   following names:
>
> ecmConfig.cmake
> ecm-config.cmake
> * processing continues, but with error

> 
> 4.) find_package() with no Find-module present, same with NO_MODULE:
>
> CMake Error at CMakeLists.txt:4 (find_package):
>   Could not find a configuration file for package "ecm" that
>   is compatible with requested version "0.0.4".
>
>   The following configuration files were considered but not accepted:
>
> /opt/ecm/share/ecm-0.0.2/cmake/ecm-config.cmake, version: 0.0.2
> /opt/ecm/share/ecm-0.0.3/cmake/ecm-config.cmake, version: 0.0.3
> * processing continues, but with error

> What should be improved:
> 1.), 2.), 4.)  processing should stop if REQUIRED was used

I disagree. Say I want to build $random package. Throw the source
somewhere, run cmake. Now I see the errors and install the packages that
are missing. If processing immediately stops on an unmet dependency I
would have to repeat that as long as there are unmet dependencies. If
processing continues but gives and error I can install all things at once.

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

[Alexander Neundorf]

On Friday 17 February 2012, Eric Noulard wrote:
...
> >> PS: I start to think in most simple cases "CONFIG_TEMPLATE" could be
> >> made optional as well if we add another TARGET_EXPORT_FILE option which
> >> indicates the name of export(TARGETS ... FILE ...), using this a proper
> >> config template could be created as well.
> > 
> > We discussed that too already.
> 
> Sorry, I surely missed this part if the discussion,
> next time don't bother re-explaining me I'll go and dig the ML.

Not sure whether it was here or on kde-buildsystem.


...agree to everything else.

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

[Eric Noulard]

2012/2/17 Alexander Neundorf :
> On Friday 17 February 2012, Eric Noulard wrote:
>> 2012/2/17 Alexander Neundorf :
>> > On Thursday 16 February 2012, Brad King wrote:
>> >> On 2/16/2012 1:24 PM, Alexander Neundorf wrote:
>> >> > Actually I expected I would prefer this over the fixed names, but now
>> >> > that I've done it and look at what Config.cmake.in file I have to
>> >> > write, I think I liked the previous version with the fixed names
>> >> > (CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
>> >>
>> >> I think the fixed names are better/simpler too.  I'm not fond of
>> >> "CONFIG_HELPER" specifically.  The information stored in them is
>> >> about the *package* that the file is configuring, which is why
>> >> I originally proposed the prefix "PACKAGE_".  The INCLUDE_INSTALL_DIR
>> >> is where the *package* goes, not where the config helper is/goes.
>> >
>> > I pushed a branch MakingConfigFilesEasier_ConfigureMacro to stage.
>> > It has documentation and a test.
>> > An example Config.cmake.in file is attached.
>> > I can still change names etc. tomorrow.
>> > The macro is in CMakePackageHelpers.cmake.
>>
>> Nice piece of work. Should be helpful to many of us.
>> Some more "tuning remarks".
>>
>> Why not offering more "bundled interface" to this feature ?
>>
>> currently you have to:
>>
>> 1) include(CMakePackageConfigHelpers)
>> 2) configure_package_config_file(FooConfig.cmake.in
>>                       ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
>>                       INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
>>                       PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
>> 3) write_basic_package_version_file(
>>                     ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
>>                     VERSION 1.2.3 COMPATIBILITY
>>                     SameMajorVersion)
>>
>> 4) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
>>              ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
>>              DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )
>
> Yes, these are all simple orthogonal functions, which can be described with
> one sentence without using "and".
>
>> 1) is mandatory of course
>> 3) is optional
>> 2) and 4) should be using the same "INSTALL_DESTINATION"  and
>> "DESTINATION" in order to be consistent.
>>
>> I cannot imagine doing 2) or 3) without 4).
>
> You are right.
> It is a somewhat problematic point that the destinations must match.
>
>> So in the end, wouldn't it be simpler (for the user/developer) to have
>> something like:
>>
>> include(CMakePackageConfigHelpers)
>> create_and_install_package_config_files(NAME Foo
>>                    CONFIG_TEMPLATE FooConfig.cmake.in
>>                    DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
>>                    PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR
>>                    VERSION 1.2.3
>>                    VERSION_COMPATIBILITY SameMajorVersion)
>>
>> This would do the same as 1) + 2) + 3) +4) but...
>>
>>  a) enforces that 2) "INSTALL_DESTINATION" and 4) "DESTINATION" are the
>> same and produce appropriate install rule.
>
> This is good on one side, but on the other side I always try not to "hide"
> simple cmake commands.
> I mean, every cmake-using developer should know configure_file() and
> install(FILES). IMO it is ok if they have to use those functions.
> Now for the Config file the issue is that it is somewhat complicated to get
> them relocatable, so we need a helper here.
> Combining the install() command into this macro hides the install(), i.e. if I
> would search the CMakeLists.txt for "install" command, to find out what is
> installed, I might not notice that this
> create_and_install_package_config_files() wraps an install() command.
>
> That's why I kept the install() out of the macro, so that for installing
> anything there is always an install() command visible.
>
> (this is a "not sure we should do this", not a "I seriously object to this
> idea")

I agree with all this, and like I said my proposal was not about replacing
your set macros but more like offering an extra high-level one.

>>  b) enforces that whatever the name of the "CONFIG_TEMPLATE" you end up
>> with Config.cmake
>>        and
>>        ConfigVersion.cmake
>>
>>      I think this is a good point because you don't have the choice of
>> the name do you?
>
> ...and the macro should FATAL_ERROR if CONFIG_TEMPLATE doesn't match
> *Config.cmake.in or *-config.cmake.in ?
>
> Sounds ok.
>
>>  c) VERSION and VERSION_COMPATIBILITY should be optional parameters
>> that would trigger the creation (and install rule) of
>> ConfigVersion.cmake
>
> Maybe. OTOH, is there any reason to install a package without version numbers
> ?

None I think but we could offer a way to the developer to craft his
own Version file
so if those are not specified this means that the developer is
handling this by himself.

>> PS: I start to think in most simple cases "CONFIG_TEMPLATE" could be
>> made optional a

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

[Eric Noulard]

2012/2/17 Alexander Neundorf :
>
> a) To change CMAKE_SKIP_RPATH so that it leaves the RPATH on in the build
> tree, but not in the install tree, IMO makes sense.

We already have
CMAKE_SKIP_RPATH
CMAKE_SKIP_BUILD_RPATH

may be we are missing
CMAKE_SKIP_INSTALL_RPATH

or that
CMAKE_SKIP_RPATH set to true may be overriden
for the build tree with CMAKE_SKIP_BUILD_RPATH to OFF

which is not the case currently (I did just checked).

more detail:
http://www.cmake.org/Wiki/CMake_RPATH_handling
cmake --help-variable-list | grep RPATH

> It's also a good sign that
> Sune, a Debian packager, says it doesn't matter for Debian what happens in the
> build tree, but I don't know whether it would be ok for everybody.


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

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] Bad error message when a package could not be found - make find_package() not search config files by default

[Alexander Neundorf]

On Thursday 16 February 2012, Alexander Neundorf wrote:
> Hi,
> 
> when I use a Find-module to search for a package, I get a nice error
> message if the package could not be found.

I collected the various error messages which can be produced in the different 
cases:
* package not found
* package found, but version doesn't match

* REQUIRED
* without REQUIRED

* find_package() with no Find-module present
* find_package(NO_MODULE)
* find_package() with a wrapper Find-module which does:
 find_package(ecm QUIET NO_MODULE)
 fphsa(ecm CONFIG_MODE)


Here we go:

package not found, REQUIRED:


1.) find_package() with no Find-module present:

CMake Error at CMakeLists.txt:4 (find_package):
  Could not find module Findecm.cmake or a configuration file
  for package ecm.

  Adjust CMAKE_MODULE_PATH to find Findecm.cmake or set
  ecm_DIR to the directory containing a CMake configuration
  file for ecm.  The file will have one of the following
  names:

ecmConfig.cmake
ecm-config.cmake
* processing continues, but with error



2.) find_package(NO_MODULE):

CMake Error at CMakeLists.txt:4 (find_package):
  Could not find a configuration file for package ecm.

  Set ecm_DIR to the directory containing a CMake
  configuration file for ecm.  The file will have one of the
  following names:

ecmConfig.cmake
ecm-config.cmake
* processing continues, but with error



3.) find_package() with a wrapper Find-module:

CMake Error at /opt/cmakeHEAD/share/cmake-2.8/Modules/
FindPackageHandleStandardArgs.cmake:91 (MESSAGE):
  Could NOT find ecm: found neither ecmConfig.cmake nor ecm-config.cmake
  (Required is at least version "0.0.4")

Call Stack (most recent call first):
  /opt/cmakeHEAD/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:121
  /opt/cmakeHEAD/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:247
  Findecm.cmake:4 (find_package_handle_standard_args)
  CMakeLists.txt:7 (find_package)
* processing stops




Without REQUIRED the messages are the same (with the wrapper Find-module the 
callstack is not printed), but processing continues without error. 

Now the cases where the Config file was found, but the version didn't match:



4.) find_package() with no Find-module present, same with NO_MODULE:

CMake Error at CMakeLists.txt:4 (find_package):
  Could not find a configuration file for package "ecm" that
  is compatible with requested version "0.0.4".

  The following configuration files were considered but not accepted:

/opt/ecm/share/ecm-0.0.2/cmake/ecm-config.cmake, version: 0.0.2
/opt/ecm/share/ecm-0.0.3/cmake/ecm-config.cmake, version: 0.0.3
* processing continues, but with error



5.) find_package() with a wrapper Find-module:

CMake Error at /opt/cmakeHEAD/share/cmake-2.8/Modules/
FindPackageHandleStandardArgs.cmake:91 (MESSAGE):
  Could NOT find ecm (Required is at least version "0.0.4"),
  checked the following files:

  /opt/ecm/share/ecm-0.0.2/cmake/ecm-config.cmake (version 0.0.2)
  /opt/ecm/share/ecm-0.0.3/cmake/ecm-config.cmake (version 0.0.3)

Call Stack (most recent call first):
  
/opt/cmakeHEAD/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:117 
  
/opt/cmakeHEAD/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:247 
  Findecm.cmake:4 (find_package_handle_standard_args)
  CMakeLists.txt:7 (find_package)
* processing stops




What should be improved:
1.), 2.), 4.)  processing should stop if REQUIRED was used


2.) CMAKE_PREFIX_PATH should be mentioned

1.), 2.) if a version number was used, this should be printed in the error 
message

1.) CMAKE_PREFIX_PATH should be mentioned at least.
This is the one error message which is IMO problematic. It basically only says 
"it did not work", and I don't know whether the package is missing or whether 
the buildsystem of the project is broken, which are two significantly 
different problems - one requires installing a package, the other requires 
hacking the buildsystem of an unknown project.
This could be avoided by making NO_MODULE required when the intention is to 
search for a Config file (I would have preferred from the beginning if 
find_package() would use only Find-modules, and for searching Config-files 
there would have been a separate command like find_config()).


In general, I would still recommend everybody to use the small wrapper Find-
modules also for packages which install a Config.file, if only for the purpose 
to contain some documentation or to set up information for 
FeatureSummary.cmake.

Alex
--

Powered by www.kitware.com

Visit other Kitware ope

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

[Alexander Neundorf]

On Friday 17 February 2012, Eric Noulard wrote:
> 2012/2/17 Alexander Neundorf :
> > On Thursday 16 February 2012, Brad King wrote:
> >> On 2/16/2012 1:24 PM, Alexander Neundorf wrote:
> >> > Actually I expected I would prefer this over the fixed names, but now
> >> > that I've done it and look at what Config.cmake.in file I have to
> >> > write, I think I liked the previous version with the fixed names
> >> > (CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
> >> 
> >> I think the fixed names are better/simpler too.  I'm not fond of
> >> "CONFIG_HELPER" specifically.  The information stored in them is
> >> about the *package* that the file is configuring, which is why
> >> I originally proposed the prefix "PACKAGE_".  The INCLUDE_INSTALL_DIR
> >> is where the *package* goes, not where the config helper is/goes.
> > 
> > I pushed a branch MakingConfigFilesEasier_ConfigureMacro to stage.
> > It has documentation and a test.
> > An example Config.cmake.in file is attached.
> > I can still change names etc. tomorrow.
> > The macro is in CMakePackageHelpers.cmake.
> 
> Nice piece of work. Should be helpful to many of us.
> Some more "tuning remarks".
> 
> Why not offering more "bundled interface" to this feature ?
> 
> currently you have to:
> 
> 1) include(CMakePackageConfigHelpers)
> 2) configure_package_config_file(FooConfig.cmake.in
>   ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
>   INSTALL_DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
>   PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
> 3) write_basic_package_version_file(
> ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
> VERSION 1.2.3 COMPATIBILITY
> SameMajorVersion)
> 
> 4) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
>  ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
>  DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )

Yes, these are all simple orthogonal functions, which can be described with 
one sentence without using "and".

> 1) is mandatory of course
> 3) is optional
> 2) and 4) should be using the same "INSTALL_DESTINATION"  and
> "DESTINATION" in order to be consistent.
> 
> I cannot imagine doing 2) or 3) without 4).

You are right.
It is a somewhat problematic point that the destinations must match.
 
> So in the end, wouldn't it be simpler (for the user/developer) to have
> something like:
> 
> include(CMakePackageConfigHelpers)
> create_and_install_package_config_files(NAME Foo
>CONFIG_TEMPLATE FooConfig.cmake.in
>DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
>PATH_VARS INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR
>VERSION 1.2.3
>VERSION_COMPATIBILITY SameMajorVersion)
> 
> This would do the same as 1) + 2) + 3) +4) but...
> 
>  a) enforces that 2) "INSTALL_DESTINATION" and 4) "DESTINATION" are the
> same and produce appropriate install rule.

This is good on one side, but on the other side I always try not to "hide" 
simple cmake commands.
I mean, every cmake-using developer should know configure_file() and 
install(FILES). IMO it is ok if they have to use those functions.
Now for the Config file the issue is that it is somewhat complicated to get 
them relocatable, so we need a helper here.
Combining the install() command into this macro hides the install(), i.e. if I 
would search the CMakeLists.txt for "install" command, to find out what is 
installed, I might not notice that this 
create_and_install_package_config_files() wraps an install() command.

That's why I kept the install() out of the macro, so that for installing 
anything there is always an install() command visible.

(this is a "not sure we should do this", not a "I seriously object to this 
idea")

>  b) enforces that whatever the name of the "CONFIG_TEMPLATE" you end up
> with Config.cmake
>and
>ConfigVersion.cmake
> 
>  I think this is a good point because you don't have the choice of
> the name do you?

...and the macro should FATAL_ERROR if CONFIG_TEMPLATE doesn't match 
*Config.cmake.in or *-config.cmake.in ?

Sounds ok.
 
>  c) VERSION and VERSION_COMPATIBILITY should be optional parameters
> that would trigger the creation (and install rule) of 
> ConfigVersion.cmake

Maybe. OTOH, is there any reason to install a package without version numbers 
?

> I can try to write (probably tomorrow) the proposed macro using those
> provided by Alex
> if you find the idea useful. The proposed macro is not meant replace
> the Alex's one but
> to offer higher-level [possibly] simpler API.
> 
> PS: I start to think in most simple cases "CONFIG_TEMPLATE" could be
> made optional as well if we add another TARGET_EXPORT_FILE option which
> indicates the name of export(TARGETS ... FILE ...), using this a proper
> config template could be created as well.

We discussed that too already.
The generat

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

[Eric Noulard]

2012/2/17 Stephen Kelly :
>
> Hi there,
>
> Also in this thread one of the discussion topics was making CMake default to
> creating Gui-ready executables. That is, setting the WIN32_EXECUTABLE or
> MACOSX_BUNDLE property on the executable target.
>
> http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6961/focus=7005
>
> By default CMake does not set those properties, which is actually uncommon.
> Generally in KDE at least, only unit tests and some small utilities are non-
> gui executables.
>
> We'd like to be able to specify with a defaultProperty something like
>
> set(CMAKE_CREATE_GUI_EXECUTABLES ON)

You probably mean:

set_property(GLOBAL PROPERTY CMAKE_CREATE_GUI_EXECUTABLES ON)

> which would set those target properties to True on the Windows and Mac
> platforms by default. For unit tests, we could then disable it again.
>
> Thoughts/comments?

I have [at least] one project which build on Windows where some
applications (not test)
are not GUI apps. In fact those applications are seldom launched by
the user because
they are "forked" by some GUI apps.

If this was set by default would my apps still be working as expected?
or shall I
put "NON-GUI" properties on them?

If this was to be introduced I bet the default value of the property
should be OFF (or not SET)
for backward compatibility reason.


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

Powered by www.kitware.com

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

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

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

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

[Marcel Loose]

Hi,

On Fri, 2012-02-17 at 08:51 +0100, Alexander Neundorf wrote:

-- 8<  8<  8<  8<  8<  8<  8<  8<  8< --

> > So the suggestion is
> > 
> > a) Change CMAKE_SKIP_RPATH to only skip RPATH when installing, but
not when
> > building (I don't know if that's easy in CMake), or alternatively
provide
> > another CMAKE_ variable to do that.
> > 
> > b) Implement something like:
> > set_property(TARGET foo APPEND PROPERTY TEST_ENVIRONMENT "foo=bar")
> > 
> > 
> > Possibly both a) and b).
> > 
> > Thoughts/comments?
> 
> b) is IMO definitely a missing feature.
> (but even with that, we (KDE) would have to keep a macro, because we
can't 
> expect that all developers know how to set this properly for all
platforms. 
> ...or, since it is a target property, this could be also intialized
from a 
> CMAKE_TEST_ENVIRONMENT cmake variable).

Maybe I'm missing the point but there is a property ENVIRONMENT for
tests:
http://cmake.org/cmake/help/cmake-2-8-docs.html#prop_test:ENVIRONMENT


> a) To change CMAKE_SKIP_RPATH so that it leaves the RPATH on in the
build 
> tree, but not in the install tree, IMO makes sense. It's also a good
sign that 
> Sune, a Debian packager, says it doesn't matter for Debian what
happens in the 
> build tree, but I don't know whether it would be ok for everybody.
> 
> 
> Alex

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

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

[Eric Noulard]

2012/2/17 Alexander Neundorf :
> On Thursday 16 February 2012, Brad King wrote:
>> On 2/16/2012 1:24 PM, Alexander Neundorf wrote:
>> > Actually I expected I would prefer this over the fixed names, but now
>> > that I've done it and look at what Config.cmake.in file I have to write,
>> > I think I liked the previous version with the fixed names
>> > (CONFIG_HELPER) better. I think it was easier to do, a simple scheme.
>>
>> I think the fixed names are better/simpler too.  I'm not fond of
>> "CONFIG_HELPER" specifically.  The information stored in them is
>> about the *package* that the file is configuring, which is why
>> I originally proposed the prefix "PACKAGE_".  The INCLUDE_INSTALL_DIR
>> is where the *package* goes, not where the config helper is/goes.
>
> I pushed a branch MakingConfigFilesEasier_ConfigureMacro to stage.
> It has documentation and a test.
> An example Config.cmake.in file is attached.
> I can still change names etc. tomorrow.
> The macro is in CMakePackageHelpers.cmake.

Nice piece of work. Should be helpful to many of us.
Some more "tuning remarks".

Why not offering more "bundled interface" to this feature ?

currently you have to:

1) include(CMakePackageConfigHelpers)
2) configure_package_config_file(FooConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
INSTALL_DESTINATION
${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS
INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR)
3) 
write_basic_package_version_file(${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
 VERSION 1.2.3
COMPATIBILITY
SameMajorVersion)

4) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
 ${CMAKE_CURRENT_BINARY_DIR}/FooConfigVersion.cmake
   DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake )

1) is mandatory of course
3) is optional
2) and 4) should be using the same "INSTALL_DESTINATION"  and
"DESTINATION" in order to be consistent.

I cannot imagine doing 2) or 3) without 4).

So in the end, wouldn't it be simpler (for the user/developer) to have
something like:

include(CMakePackageConfigHelpers)
create_and_install_package_config_files(NAME Foo

CONFIG_TEMPLATE FooConfig.cmake.in

DESTINATION ${LIB_INSTALL_DIR}/Foo/cmake
PATH_VARS
INCLUDE_INSTALL_DIR SYSCONFIG_INSTALL_DIR
VERSION 1.2.3

VERSION_COMPATIBILITY SameMajorVersion)

This would do the same as 1) + 2) + 3) +4) but...

 a) enforces that 2) "INSTALL_DESTINATION" and 4) "DESTINATION" are the same
 and produce appropriate install rule.

 b) enforces that whatever the name of the "CONFIG_TEMPLATE" you end up with
   Config.cmake
   and
   ConfigVersion.cmake

 I think this is a good point because you don't have the choice of
the name do you?

 c) VERSION and VERSION_COMPATIBILITY should be optional parameters
that would trigger
 the creation (and install rule) of  ConfigVersion.cmake

I can try to write (probably tomorrow) the proposed macro using those
provided by Alex
if you find the idea useful. The proposed macro is not meant replace
the Alex's one but
to offer higher-level [possibly] simpler API.

PS: I start to think in most simple cases "CONFIG_TEMPLATE" could be
made optional as well
  if we add another TARGET_EXPORT_FILE option which indicates the name of
  export(TARGETS ... FILE ...), using this a proper config
template could be created as well.

PS2: we may need to add an optional COMPONENT option as well if the
generated install rule should
be put in some install component.

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

Powered by www.kitware.com

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

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

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

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

[Alexander Neundorf]

On Friday 17 February 2012, Eric Noulard wrote:
> 2012/2/16 Brad King :
...
> > the real install location, DESTDIR, or a tarball that was extracted
> > at an arbitrary location on another machine.  The load-time prefix
> > is computed relative to the file's location.  Under that prefix the
> > file refers to all the other pieces (include, etc.) which exist at
> > a fixed location relative to BarConfig.cmake.
> 
> Right I did not realize that relative position should still be valid.
> In fact I'm pretty sure you can break this if you mess-up with
> absolute install destination, but if ones to that there is no point in
> using this so...

It works with absolute install destinations as long as they point to 
subdirectories of CMAKE_INSTALL_PREFIX.
If they point somewhere else, they are really fixed.

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