Re: [CMake] Documentation for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT missing?

[Johannes Zarl]

On 03/07/2011 at 23:47, Gabriel Petrovay gabipetro...@gmail.com wrote: 
 On Mon, Mar 7, 2011 at 7:03 PM, Alexander Neundorf
 a.neundorf-w...@gmx.net wrote:

 It's an internal variable.
 
 May we use it? Or is it not intended for users to use it?

Just bumping this thread up, but I think this is a valid question.
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT is not only widely
used in projects, but also used in the semi(?)-officially solution 
to setting an install prefix without overwriting user-choices.

If it's internal and we should not use it, quite a number of 
projects will have to be changed...

Cheers,
  Johannes


-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










___
Powered by www.kitware.com

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

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

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

Re: [CMake] CMake and include only libraries

[Johannes Zarl]

 Honestly, headers seem sometimes a second class citizen in cmake: there
 are some properties related to headers but few header knowledgeable
 commands...
 I really don't see how CMake could automate this any more, or what
 additional information it could generate for you. 

Well, since you asked: it *would* be nice if cmake would know about the 
headers needed by a target, or even support header-only targets. Currently 
it feels like an artificial divide between shared object files and header 
files:

# find required dependency which correctly sets up import targets:
find_package(BAR)
# additional step for headers (with side-effects for other targets)...
include_directories(${BAR_INCLUDE_DIRS})
# ... that is not needed (and in fact discouraged) for libs:
#NO: link_directories(${BAR_LIBRARY_DIRS})
target_link_libraries(foo bar)

To be fair though, most other build-systems are not any better at 
handling header files. And since this feature request has already been
discussed in http://public.kitware.com/Bug/view.php?id=115, I'm content 
with it only being deferred, not dismissed...




-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










___
Powered by www.kitware.com

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

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

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

Re: [CMake] Wiki: version compatibility matrix

[Johannes Zarl]

Apparently I forgot to add the list in my reply to Alexander, so
here for all to read:

Now that I'm back from my vacation, I'll get to it soonish (during 
August).

Cheers,
  Johannes

On 07/14/2011 at 14:03, Clifford Yapp cliffy...@gmail.com wrote: 
 On Tue, Jul 12, 2011 at 4:58 PM, Alexander Neundorf
 a.neundorf-w...@gmx.net wrote:
 
 now cmake 2.8.5 has been released, could you please if you find the time
 update that page ?
 It's really useful :-)
 
 Second that motion - it just helped me figure out another issue! :-)
 
 Cheers,
 CY


___
Powered by www.kitware.com

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

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

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

Re: [CMake] Wiki: version compatibility matrix - please add feedback

[Johannes Zarl]

Hi,

So I've started bringing the matrix up to date. Just to make sure I'm not 
reporting documentation-changes as real changes, please take a look at the 
following items and correct me where I'm wrong:

Changes from 2.8.3 to 2.8.4:


* get_cmake_property:
previously reported an error when property was not found, now only the result 
variable is set to NOTFOUND.

* get_test_property:
Parameters VAR and property swapped in docu - I guess this was a doc-bug 
in earlier versions.
Additionally, the same behaviour change as in get_cmake_property (didn't this 
change in all get_*_property commands?).

* try_compile, try_run:
Mention of CMAKE_TRY_COMPILE_CONFIGURATION is added to the doc for 
completeness? Or was it not available before?


Changes from 2.8.4 to 2.8.5:


* add_custom_command, add_custom_target:
Option WORKING_DIRECTORY did not alter behaviour w.r.t relative paths, just 
the doc was improved?

* find_package:
Is the support for setting a package-directory in 
HKEY_CURRENT_USER\Software\Kitware\CMake\Packages\lt;packagegt; (windows) or 
~/.cmake/packages/lt;packagegt; (unix) new, or just not that well documented 
before?

* list:
I guess the scoping of the variables by list command is new?


Well, that's all for now. I'll keep asking here as new questions arise...

Cheers,
  Johannes
___
Powered by www.kitware.com

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

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

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

[CMake] Wiki: enabling Cite extension?

[Johannes Zarl]

Hi,

Working on the version compatibility matrix (which is now up-to-date once 
again), I came to think that the Cite extension for MediaWiki 
(http://www.mediawiki.org/wiki/Extension:Cite) would allow the compatibility 
matrix to be much more compact (by moving additional notes from the matrix 
into footnotes). 

Would it be possible to install this extension inside the cmake wiki?

Cheers,
  Johannes
___
Powered by www.kitware.com

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

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

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

[CMake] Wiki spam

[Johannes Zarl]

Hi,

I just noticed that some spam pages seem to have been inserted 
into the wiki using these user accounts:

http://www.cmake.org/Wiki/Special:Contributions/Carinsurancecarinsurancequotes
http://www.cmake.org/Wiki/Special:Contributions/Sarawilliam30
http://www.cmake.org/Wiki/Special:Contributions/WalterMosley
http://www.cmake.org/Wiki/Special:Contributions/Janyrobert23
http://www.cmake.org/Wiki/Special:Contributions/Rozer456
http://www.cmake.org/Wiki/Special:Contributions/Jason85clark

Also, one can find lots of spam pages via the orphaned pages...

Is there a preferred way how to deal with wiki-spam one encounters?

Kind regards,
  Johannes

___
Powered by www.kitware.com

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

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

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

Re: [CMake] Wiki: version compatibility matrix

[Johannes Zarl]

Hi,

I'll probably get to it in the next 1-3 weeks...

Cheers,
  Johannes

 On 10/05/2011 at 16:51, David Cole david.c...@kitware.com wrote: 
 On Tue, Jul 12, 2011 at 4:58 PM, Alexander Neundorf
 a.neundorf-w...@gmx.net wrote:
 Hi,

 On Saturday 04 December 2010, Johannes Zarl wrote:
 Hello,

 The compatibility matrix for different versions of cmake is now complete
 and awaits review:
 http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix

 Apart from factual errors and things I might have missed, I am also
 interested if someone has a better idea for embedding the comments: they
 make the tables broader than they need to be. Also, the wiki warns that
 the page might be to big for some browsers. Should the page be divided
 into subpages?

 If no one objects, I will add a link to the main-page under Development
 Topics by Wednesday next week (2010-12-08).

 now cmake 2.8.5 has been released, could you please if you find the time
 update that page ?
 It's really useful :-)

 Alex
 ___
 Powered by www.kitware.com

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

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

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

 
 Same request over again, but now for the hot-off-the-presses CMake
 2.8.6 official release.
 
 Can you / do you have the time to update the wiki for 2.8.6?
 
 
 Thanks!
 David


--
Powered by www.kitware.com

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

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

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

Re: [CMake] Wiki: version compatibility matrix

[Johannes Zarl]

Hello David,

I just finished the updated version for 2.8.6. Can you maybe check again with 
the wiki admins if the Cite extension can be added to the CMake wiki?

Cheers,
  Johannes


Ceterum censeo emendationem Cite esse immuniendam.


On Wednesday 05 October 2011 16:51:43 David Cole wrote:
 Same request over again, but now for the hot-off-the-presses CMake
 2.8.6 official release.
 
 Can you / do you have the time to update the wiki for 2.8.6?
 
 
 Thanks!
 David
--

Powered by www.kitware.com

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

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

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

Re: [CMake] hear hear

[Johannes Zarl]

On Tuesday, 6. December 2011, 17:27:47, Daniel Dekkers wrote:
 On Dec 4, 2011, at 11:59 AM, Michael Jackson wrote:
  I think if the CMake community took a vote we could probably come up with
  an Exemplar Find*.cmake file that is good for someone trying to
  develop a new one.
 
 Yes please.
 And I think in general that is true. Of course it is more interesting and
 often more urgent to spend time on exotic problems. But there are these
 basics that are missing in the documentation. Like,.. this works in 99% of
 the cases, we, CMake, advise you to do this. If you don't, you are making
 life hard on yourself and you are more or less on your own. Something
 like:
 1) a single executable
 2) a single executable linked to a lib built from source
 3) different executables using the same lib built from source
 4) a single executable linked to a binary lib (with the aid of a find
 module) ...
 n) multiple executables linked to multiple libraries (linked to third-party
 libraries), some static, some dynamic, some with their own CMake builds,
 some without, on different platforms. Auch. n+1) making anything work with
 Xcode

I would like that, too.

Also, it would be nice if the example would include a *Config.cmake (and 
*Version.cmake) file. What I notice with several projects is that the 
*config.cmake mechanism for finding out about a package is still largely 
ignored 
and each projects rolls out its own Find*.cmake file instead, which dependent 
projects than copy into their source tree.

Raising the awareness for the *Config.cmake style of making your package easy 
to find would certainly be a good thing. 

Cheers,
  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] shell level access to values of cmake variables

[Johannes Zarl]

Am Thursday, 10. November 2011, 18:48:06 schrieb vagn scott:
 is there something like
  cmake --dump-var PROJECT_NAME
 that would output the string
  hello_foo_baz

As far as I know CMake doesn't do this out of the box. As long as you have a 
configured build tree and only want to access cache variables, you could use 
the script mode.

Create a script named printvar.cmake with the following command:

message(${${VAR}})

Then you can do this in the build directory:

cmake . -DVAR=CMAKE_PROJECT_NAME -P ../printvar.cmake

Be aware, though, that the message is printed to stderr, not stdout. Other 
than that (and the issue that it is a dirty hack), this should do what you 
need...

Cheers,
  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Wiki: version compatibility matrix

[Johannes Zarl]

Hi David,

I guess I'll have time this week to update the matrix. 

In case the admin team would like to have a rationale for installing the Cite 
extension: Having the Cite extension would allow me to write the matrix in a 
more compact/less cluttered style.

Thanks for lobbying for this issue!
  Johannes

On Monday, 2. January 2012, 16:33:04, David Cole wrote:
 Hi Johannes,
 
 Time to update again, this time for CMake 2.8.7.
 
 This page tells me what the Cite extension is:
 http://www.mediawiki.org/wiki/Extension:Cite
 
 This page tells me it's not installed yet on the CMake wiki server:
 http://www.cmake.org/Wiki/Special:Version
 
 I'll ask the admin team to install it. I'll let you know if they say
 we can't for some reason...

--

Powered by www.kitware.com

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

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

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

Re: [CMake] Wiki: version compatibility matrix

[Johannes Zarl]

Hi David,

This is great news! I have updated the matrix to use footnotes, and also added 
the 2.8.7 changes to it. The whole matrix now looks much more clearly:

http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix

Cheers,
  Johannes

On Tuesday 03 January 2012 17:25:31 David Cole wrote:
 The Cite extension is now installed on the CMake wiki. See this page
 to see what mediawiki extensions are available:
 
 http://www.cmake.org/Wiki/Special:Version
 
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Revision header

[Johannes Zarl]

On Saturday, 21. January 2012, 22:51:01, Oliver Smith wrote:
 I have a script that generates a revision.h file, I've spent the morning
 trying to figure out how to make it so that ... any time CMake rebuilds
 any of the other targets, it starts by running the make-new-revision
 script.
 
 The idea is, I use the script manually to upversion, but anytime I type
 make and /anything/ has to be done (even just a relink), it will do
 the upversion first.
 
 I've only managed to make it either source dependent or always build,
 which forces the versionNo file to recompile and forces all executables
 to relink, so if you type:
 
 make ; make ... it will have to relink the executables the second time
 because of an pointless upversion :)

I guess the most efficient way is to fix your upversion script so that it only 
overwrites revision.h if it actually changed. This way you can execute it 
every time without having it mess up the dependency tracking...


  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Compile CMakeCache.txt into shared library

[Johannes Zarl]

Hi,

I'm not sure if I understand you correctly, but I would guess that in most 
cases you don't need to know _all_ cmake cache variables at runtime.

If you really just need to know some specific variables, you would be much 
better off using a generated header file. See the documentation for 
configure_file 
for details on this.

In short, you'd make a headerfile config.h.in with lines like this:
#cmakedefine @my_magic_variable@

And in cmakeLists:
configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/config.h.in
   ${CMAKE_CURRENT_BINARY_DIR}/config.h )

Afterwards, you can include config.h in your shared library and you can use the 
value there...

HTH,
  Johannes


On Wednesday 08 February 2012, 14:34:00, Hänel Nikolaus Valentin wrote:
 Dear Cmake List,
 
 we would like to include a CmakeCache.txt file into our shared
 library. The reason is, that we would like to know what CMake options
 were used when compiling the library in case we have only the binary.
 
 Has anyone done something like this before and can give me some
 pointers?
 
 Thanks for any advice
 
 Valentin
 
--

Powered by www.kitware.com

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

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

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

Re: [CMake] providing library information, what's the cmake way

[Johannes Zarl]

Sorry for hijacking this thread, but I'm wondering about this for some 
time, too. (And the information in the doc/wiki is somewhat dated and/or 
ambiguous [1,2,3,4]). I will just go on and write my thoughts and what I 
(think I) know, in the hope that somebody corrects those things I got 
wrong.

So summarizing the previous mesage in the thread, one can say:
 + cmake aware packages should provide LibraryConfig.cmake scripts
   (and optionally LibraryVersion.cmake scrips), just like they would
   provide pkg-config files.
 + developers should create FindLibrary.cmake scripts for packages
   they are using that are not cmake aware.

I think that information should be transported more clearly, because
in practice most cmake based software provides a FindLibrary.cmake
file for itself.

Also, I could not find a definitive answer on where these packages 
should put the LibraryConfig.cmake script. If I read the search paths in
[1] correctly, the preferred paths are:
 + prefix/ on windows
 + prefix/(share|lib)/cmake/name*/ on linux, and
 + prefix/name.framework/Resources/ on Apple

We have have every library and library-version in its own prefix and use 
shell modules[5] to provide the correct environment that a user wants.
Is there any way to let cmake know about specific prefix directories it 
should be aware of? Unfortunately, the CMAKE_MODULE_PATH variable has
to be manually set, and not influenced by the environment.

Something like the PKG_CONFIG_PATH environment variable for pkg-config
would be really nice to have in cmake.

Another somehow related topic seems to be import/export of targets. Should
a LibraryConfig.cmake or FindLibrary.cmake file create imported targets
for the library?

And is there any documentation on how to create a LibraryConfig.cmake file
with support for components?

Cheers,
  Johannes

[1] http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:find_package
[2] http://www.cmake.org/Wiki/CMake_HowToFindInstalledSoftware
[3] http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries
[4] http://www.cmake.org/Wiki/CMake:Improving_Find*_Modules
[5] http://modules.sourceforge.net/




-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










___
Powered by www.kitware.com

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

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

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

Re: [CMake] providing library information, what's the cmake way

[Johannes Zarl]

On Wednesday 24 November 2010 19:03:21 David Cole wrote:
 On Wed, Nov 24, 2010 at 12:58 PM, Tyler Roscoe ty...@cryptio.net wrote:
  On Wed, Nov 24, 2010 at 11:41:46AM -0500, David Cole wrote:
  On Wed, Nov 24, 2010 at 11:34 AM, Rolf Eike Beer e...@sf-mail.de wrote:
   So I think it is _really_ necessary to go through all the CMake
   documentation items and add a line about when which feature was added.
  
  Adding that information in the documentation would be good, I agree.
  (Although quite time consuming and costly for somebody...)
  
  Perhaps a good compromise is simply to add version information to all
  new CMake commands/variables/properties that are added henceforth?
  
  Thanks,
  tyler
 
 That does sound like a good idea.

From the information in http://www.cmake.org/Wiki/CMake_Released_Versions and 
using some shell-scripts to create the diffs between all neighbor-versions, 
it's not too much work to create a compatibility matrix for the documented 
features.

I took the liberty and compiled such a compatibility matrix here:
http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix

It's a draft and does not (yet) contain information about properties and 
variables, but if this idea receives general consent I could complete the 
information.

What do you think? Is this worth the effort, or would no one ever bother to 
update the information?

cheers,
  Johannes
___
Powered by www.kitware.com

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

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

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

Re: [CMake] providing library information, what's the cmake way

[Johannes Zarl]

On Friday 26 November 2010 10:49:01 Eric Noulard wrote:
  From the information in http://www.cmake.org/Wiki/CMake_Released_Versions
  and using some shell-scripts to create the diffs between all
  neighbor-versions, it's not too much work to create a compatibility
  matrix for the documented features.
 
 May be it can be fully  automated suche that adding a column for each new
 CMake release would take minimum time?

Unfortunately, I don't think that's possible. After all, the information has 
to be gathered comparing the textual output of cmake --help-full. While most 
differences are pretty straightforward to interpret (at least for a human 
reader), sometimes the documentation changes and you really have to read the 
different versions and decide if there really was a change in behaviour, or if 
it's just a documentation change.

  I took the liberty and compiled such a compatibility matrix here:
  http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix
  
  It's a draft and does not (yet) contain information about properties and
  variables, but if this idea receives general consent I could complete the
  information.
  
  What do you think? Is this worth the effort, or would no one ever bother
  to update the information?
 
 I like it too, I think it's very handy.
 Concerning the update I think I will be done (and I may help)
 if some scripts pre-digest the informations to be laid out.

I don't have any time for this matter before next Thursday, but regarding the 
positive reactions on this list I will certainly complete the matrix.

Eric: I can send you the shell-scripts if you want to have a look...

Have a nice weekend,
  Johannes
___
Powered by www.kitware.com

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

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

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

Re: [CMake] providing library information, what's the cmake way

[Johannes Zarl]

Sorry for the late response, but your mail was simply to long for a
swift response...

On 11/26/2010 at 05:47, Michael Hertling mhertl...@online.de wrote: 
 On 11/24/2010 04:51 PM, Johannes Zarl wrote:
 About the components question again: I played around a bit, and I think I 
 now more or less have comprehended this. I guess for a package XXX with 
 components YYY and ZZZ, one could set variables XXX_HAS_YYY and XXX_HAS_ZZZ
 and then use a loop like this one in the XXXConfig.cmake file:
 
 foreach( component ${XXX_FIND_COMPONENTS} )
 if ( XXX_HAS_${component})
 set ( XXX_${component}_FOUND TRUE )
 else( XXX_HAS_${component})
 if ( ${XXX_FIND_REQUIRED})
 message(FATAL_ERROR Required component ${component} not 
 found!)
 elseif ( NOT XXX_FIND_QUIETLY)
 message(STATUS Component ${component} not found!)
 endif ( ${XXX_FIND_REQUIRED})
 endif ( XXX_HAS_${component})
 endforeach( component )
 
 Correct?
 
 While that's a possible approach it lacks the invocation-specific
 variables, i.e. XXX_{INCLUDE_DIRS,LIBRARIES,DEFINITIONS}, and in
 some cases, these can't be assembled in a simple component-wise
 manner, see below. Moreover, there are further questions w.r.t.
 multi-component packages and their config files:

Does this mean that XXX_LIBRARIES etc. should normally incorporate the
settings for the components as well? IMO this can't work if you call
find_package several times with different components. Also, this would 
make it impossible to link to the base library alone, i.e. without
the components...

 - Does the config file provide the component-specific variables like
 XXX_YYY_FOUND for each available component or for the requested ones
 only, i.e. can you rely on XXX_ZZZ_FOUND to have a definite value if
 you just said FIND_PACKAGE(XXX COMPONENTS YYY)? With your foregoing
 approach, you can't. That's alright, but should be mentioned in the
 package's documentation. Imagine the following scenario: There's one
 installation of XXX for the native system and another one for cross
 compiling purposes. The latter has YYY and ZZZ while the former has
 YYY only. Due to FIND_PACKAGE()'s ability to search for config files
 in various locations, such a coexistence is easily possible. Now, a
 FIND_PACKAGE(XXX COMPONENTS YYY ZZZ) for the cross compilation XXX
 returns with XXX_ZZZ_FOUND=TRUE, but does a subsequent invocation of
 FIND_PACKAGE(XXX COMPONENTS YYY) within the same scope for the native
 XXX return with XXX_ZZZ_FOUND=FALSE, or does XXX_ZZZ_FOUND=TRUE still
 hold from the previous invocation? Both alternatives are fine, but the
 user should know the score. 

Thanks, I hadn't thought of this. So the code-snippet above should 
contain a set ( XXX_${component}_FOUND ${component}-NOTFOUND ).

 Besides, it's a good style to refer to any
 component-related variables only if the particular component has been
 requested explicitly.

Ok, so a better style would be to only set the XXX_HAS_* variables at 
first (maybe unsetting them at the end of the config file?), and then
to conditionally set the XXX_YYY_INCLUDE_DIRS etc. if XXX_YYY_FOUND
is true.

 - Handling of inter-component dependencies: Imagine the user just says
 FIND_PACKAGE(XXX COMPONENTS ZZZ), but ZZZ needs YYY. If YYY is to be
 enabled automatically the config file must know about the dependency
 and cannot simply add the ZZZ-specific variables to the invocation-
 specific ones; the YYY-specific variables must be mentioned, too.

I don't really see this as a problem. Although the code at hand lacks 
support for this kind of dependencies, in most cases you won't need it.
And if you as the config file writer need it, you obviously know you
have dependencies and that you have to write code supporting those
dependencies.

Update/FYI: I just tried tried to write generic code to deal with 
dependencies, and its not as straightforward as I thought it is. Assuming
that there are no circular dependencies, you could recursively add the 
dependencies to the XXX_FIND_COMPONENTS variable and remove the duplicates
afterwards. Then you can use the above code to set XXX_*_FOUND, and
afterwards, you have to recursively add the libraries/defines/include_dirs
of the depended upon components to each component's includes (this
is the tricky part IMO). I guess it is far easier to write this in a
non-generic way...

 - Do multiple consecutive FIND_PACKAGE(XXX ...) invocations act in an
 accumulative manner on the invocation-specific variables? 

Generally speaking, I would say: yes. At least this is the way of the
least surprise for the user, as in sufficiently complex projects a
package may be included at different places with different arguments.

 FIND_PACKAGE(XXX REQUIRED YYY)
 FIND_PACKAGE(XXX COMPONENTS ZZZ)

Ah, this is how it's done. I was wondering why a call like

find_package(XXX COMPONENTS ZZZ REQUIRED YYY)

sets both XXX_YYY_REQUIRED and XXX_ZZZ_REQUIRED.

 When turning towards find modules

Re: [CMake] providing library information, what's the cmake way

[Johannes Zarl]

On 11/29/2010 at 14:28, Johannes Zarl johannes.z...@jku.at wrote:
 On 11/26/2010 at 05:47, Michael Hertling mhertl...@online.de wrote:
 See [1] for a former discussion of
 several aspects regarding multi-component packages.
 [...]
 [1] http://www.mail-archive.com/cmake@cmake.org/msg28431.html
 
 Looks interesting. I will have to read that discussion...

Ok. Now I that I have read that whole thread, I think I more or less 
agree with you, Michael. Also, I've found this mail from Brad King
quite informative:
http://www.mail-archive.com/cmake@cmake.org/msg28666.html

Have a nice evening,
  Johannes


-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










___
Powered by www.kitware.com

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

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

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

Re: [CMake] providing library information, what's the cmake way

[Johannes Zarl]

On 11/30/2010 at 11:39, Michael Hertling mhertl...@online.de wrote: 
 Does this mean that XXX_LIBRARIES etc. should normally incorporate the
 settings for the components as well? [...]
 
 Yes, of course, if FIND_PACKAGE(XXX ...) returns successfully one would
 expect XXX_LIBRARIES to hold all libraries necessary to link against in
 order to use all components enabled by the FIND_PACKAGE() invocation,
 i.e. the libraries provided by the components themselves as well as
 their prerequisites.

About that one would expect: I would be rather stumped and scratching 
my head if I saw this behaviour. But I'll get to that below...

 [...] IMO this can't work if you call
 find_package several times with different components. [...]
 
 This is one of those questions to deal with when it comes to multi-
 component packages: Does FIND_PACKAGE(XXX ...) act accumulatively?

Yes. Again, for a detailed explanation see below...

 [...] Also, this would 
 make it impossible to link to the base library alone, i.e. without
 the components...
 
 One might consider the base library as a component by itself, perhaps
 enabled automatically by resolving inter-component dependencies. As an
 alternative, one could a priori populate XXX_LIBRARIES et al. with the
 base library stuff and add the components' contributions as required.
 Furthermore, a package doesn't need to have a dedicated base library,
 e.g. Boost hasn't, and if you don't specify any components the
 Boost_LIBRARIES variable remains empty.

Which is to be expected, given that Boost is mostly a headers-only 
library. Still, after your find_package call for Boost alone, you can
use all Boost core libraries.


-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










 - Handling of inter-component dependencies: Imagine the user just says
 FIND_PACKAGE(XXX COMPONENTS ZZZ), but ZZZ needs YYY. If YYY is to be
 enabled automatically the config file must know about the dependency
 and cannot simply add the ZZZ-specific variables to the invocation-
 specific ones; the YYY-specific variables must be mentioned, too.
 
 I don't really see this as a problem. Although the code at hand lacks 
 support for this kind of dependencies, in most cases you won't need it.
 And if you as the config file writer need it, you obviously know you
 have dependencies and that you have to write code supporting those
 dependencies.
 
 Usually, handling of such dependencies means enabling some components
 the user hasn't requested explicitly, so it's quite straight forward,
 in fact. However, I've mentioned these dependencies to point out that
 the invocation-specific variables like XXX_LIBRARIES sometimes can't
 be assembled by a simple iteration over XXX_FIND_COMPONENTS; instead,
 the dependencies must be resolved first. BTW, do you know an example
 with a component A depending on B only if C is enabled? ;)

No, but you are posing questions that make my head hurt (in a good-ish
way ;-)

 - Do multiple consecutive FIND_PACKAGE(XXX ...) invocations act in an
 accumulative manner on the invocation-specific variables? 
 
 Generally speaking, I would say: yes. At least this is the way of the
 least surprise for the user, as in sufficiently complex projects a
 package may be included at different places with different arguments.
 
 For the same reason, I'd tend to the opposite; look at the following:
 
 FIND_PACKAGE(XXX COMPONENTS YYY)
 ...
 ADD_SUBDIRECTORY(subdir)
 
 In subdir/CMakeLists.txt:
 
 FIND_PACKAGE(XXX COMPONENTS ZZZ)
 ...
 TARGET_LINK_LIBRARIES(... ${XXX_LIBRARIES})
 
 Here, the target is also linked against XXX_YYY_LIBRARY as the latter is
 inherited via XXX_LIBRARIES from the parent directory, but if the target
 only needs XXX_ZZZ_LIBRARY it will possibly be overlinked. Although this
 can be avoided by resetting XXX_LIBRARIES before each FIND_PACKAGE()
 invocation, I don't think that's the way one would like to go.
 
 IMO, the invocation-specific results of any FIND_PACKAGE() call should
 depend solely on the parameters passed in and the well-known variables
 like CMAKE_PREFIX_PATH. The downside is that one must possibly process
 or save the results before they could be overwritten, e.g.:
 
 FIND_PACKAGE(XXX REQUIRED YYY)
 SET(LIBRARIES ${XXX_LIBRARIES})
 FIND_PACKAGE(XXX COMPONENTS ZZZ)
 LIST(APPEND LIBRARIES ${XXX_LIBRARIES})
 ...
 TARGET_LINK_LIBRARIES(... ${LIBRARIES})
 
 Since such related calls to FIND_PACKAGE(XXX ...) usually occur nearby
 each other within the same CMakeLists.txt, this little penalty should
 be acceptable whereas accumulated XXX_LIBRARIES and the like may have
 far reaching and surprising effects, especially in complex projects.

Funny enough, my example is almost the same:

FIND_PACKAGE(XXX COMPONENTS YYY)
...
ADD_SUBDIRECTORY(subdir)
...
TARGET_LINK_LIBRARIES(AAA ${XXX_LIBRARIES})
TARGET_LINK_LIBRARIES(BBB

Re: [CMake] providing library information, what's the cmake way

[Johannes Zarl]

 writing and housekeeping 
of find modules (you don't have to copy essentially the same code to n 
files and keep those in sync, you don't clutter your modules directory
with countless files).

BTW you can have exactly the same behaviour with multiple find modules:
when you call the base package, it resets the XXX_INCLUDE_DIRS, 
XXX_LIBRARIES and XXX_DEFINITIONS. The component files just add their 
own stuff to these libraries. So this really isn't a fundamental
difference between multi-component packages and multi single-component 
packages.


-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










 IF YYY hasn't been requested explicitly, but the find module despite
 looks for it, XXX_YYY_FIND_{REQUIRED,QUIETLY} should be set to FALSE
 and TRUE, resp., so FPHSA handles the REQUIRED/QUIET flags for each
 component as the user probably expects, and XXX_YYY_FOUND is set up
 properly at the same time.

 I'm not completely sure if I understood that all correctly. As far as
 I can see, the REQUIRED/QUIET flags are set for all components or
 nothing. The interface of find_package simply doesn't allow a more fine
 grained setting of those flags.
 
 That's right, but the REQUIRED/QUIET flags cannot be applied to every
 component in the same manner in all situations. Suppose FindXXX.cmake
 looks for each of XXX's known components, say YYY and ZZZ, regardless
 if it is explicitly requested in the FIND_PACKAGE() call or not; e.g.
 FindQt4.cmake behaves this way. Now, with
 
 FIND_PACKAGE(XXX REQUIRED YYY)
 
 the user would not expect the find module to bail out if ZZZ is not
 found, but the absence of YYY should terminate the configuration, so
 the REQUIRED flag applies to YYY only. A similar point may be adopted
 for the QUIET flag: If it is not specified the user probably wouldn't
 want to see any messages related to components that are not requested
 explicitly, i.e. with the FIND_PACKAGE() above, one usually does not
 want to spot -- Found XXX_ZZZ: /usr/local/lib/libXXX_ZZZ.so 

Ok. So QUIET gets applied for any component which has not been 
explicitly requested, and REQUIRED is only applied to those which have 
been explicitly requested. 

 Regarding FIND_PACKAGE_HANDLE_STANDARD_ARGS: why not simply adding
 another command? In fact, let's discuss its interface right now, and
 then implement it:

 set(XXX_COMPONENTS YYY;ZZZ)
 FIND_PACKAGE_COMPONENTS_HANDLE_STANDARD_ARGS(
XXX
XXX_COMPONENTS
DEFAULT_MSG
DEFAULT_SUFFIXES
 )

 Assuming DEFAULT_SUFFIXES to be LIBRARIES;INCLUDE_DIRS;DEFINITIONS,
 this would check the following variables:
 XXX_LIBRARIES
 XXX_INCLUDE_DIRS
 XXX_DEFINITIONS
 XXX_YYY_LIBRARIES
 XXX_YYY_INCLUDE_DIRS
 XXX_YYY_DEFINITIONS
 XXX_ZZZ_LIBRARIES
 XXX_ZZZ_INCLUDE_DIRS
 XXX_ZZZ_DEFINITIONS

 Let's say that component YYY has been found, but ZZZ is not, so the
 XXX_YYY_* variables are set, as well as the XXX_{LIBRARIES,INCLUDE_DIRS,
 DEFINITIONS} variables.

 So regardless of the REQUIRED flag you end up with these variable-values:
 XXX_FOUND = TRUE
 XXX_YYY_FOUND = TRUE
 XXX_ZZZ_FOUND = FALSE (or XXX_ZZZ-NOTFOUND, whatever you like most)

 A fatal error is raised, if REQUIRED is true and XXX_FIND_REQUIRED_ZZZ
 is true:

 find_package(XXX REQUIRED YYY)
  - OK, user can trust that XXX_FOUND and XXX_YYY_FOUND are true.

 find_package(XXX COMPONENTS ZZZ)
  - OK, user has to check XXX_FOUND and XXX_ZZZ_FOUND
 find_package(XXX REQUIRED ZZZ)
  - FATAL_ERROR, cmake will abort, so XXX_FOUND=true doesn't matter.

 Is this an interface that you could use? Any criticism?
 
 What do you do if an unusually named variable is involved to indicate a
 component's presence/absence? 

Can you give an example for this?

 While FPHSA accepts arbitrary variables,
 your FIND_PACKAGE_COMPONENTS_HANDLE_STANDARD_ARGS() is restricted to
 XXX_COMPONENTS times DEFAULT_SUFFIXES.

Actually, my FPCHSA is just as mighty as the standard FPHSA. Leave the 
XXX_COMPONENTS empty and it behaves the same way as FPHSA does (at least
if you use the same prefix for all variables, which is IMO the recommended
practice. After all, polluting the namespace is bad(tm)).

 IMO, instead of developing a completely new function, one should re-use
 established code as far as possible, and the measure necessary to apply
 FPHSA to components is just to promote the standard args while taking
 account of the above-mentioned point:
 
 # Handle explicitly requested component YYY:
 # Set up (or not) XXX_YYY_LIBRARY, XXX_YYY_INCLUDE_DIR, ...
 SET(XXX_YYY_FIND_REQUIRED ${XXX_FIND_REQUIRED})
 SET(XXX_YYY_FIND_QUIETLY ${XXX_FIND_QUIETLY})
 FPHSA(XXX_YYY DEFAULT_MSG XXX_YYY_LIBRARY XXX_YYY_INCLUDE_DIR ...)
 
 # Handle non-requested component ZZZ:
 # Set up (or not) XXX_ZZZ_LIBRARY, XXX_ZZZ_INCLUDE_DIR, ...
 SET(XXX_ZZZ_FIND_REQUIRED FALSE)
 SET(XXX_ZZZ_FIND_QUIETLY TRUE)
 FPHSA(XXX_ZZZ

Re: [CMake] providing library information, what's the cmake way

[Johannes Zarl]

On Wednesday 01 December 2010 17:57:45 Johannes Zarl wrote:
 Back to my proposed FPCHSA: My initial goal was to provide an interface
 which does as much work as possible for you, maybe at the price of
 restricted variable naming. So let's come up with a better interface:
 
 I do want to restrict the possible prefix for modules, because I really
 do think it is a good practice (and a practice worth enforcing) to
 require a common package prefix and one prefix for each component):
 
 FPCHSA( XXX DEFAULT_MSG LIBRARY INCLUDE_DIR DEFINITIONS
   COMPONENT YYY DEFAULT_MSG LIBRARY INCLUDE_DIR DEFINITIONS
   COMPONENT ZZZ DEFAULT_MSG INCLUDE_DIR OTHER_VAR )
 
 This is far noisier than the initial approach, but still much easier to
 read and more compact to write that the FPHSA approach outlined above
 (3 lines vs. 7 lines). Even without the namespace-enforcement it would
 be readable:
 
 FPCHSA( XXX DEFAULT_MSG XXX_LIBRARY XXX_INCLUDE_DIR XXX_DEFINITIONS
   COMPONENT YYY DEFAULT_MSG XXX_YYY_LIBRARY XXX_YYY_INCLUDE_DIR
 XXX_YYY_DEFINITIONS COMPONENT ZZZ DEFAULT_MSG XXX_YYY_INCLUDE_DIR
 XXX_YYY_OTHER_VAR )
 
 This signature should even be downwards-compatible with FPHSA.

Btw. I just read the documentation for the new FPHSA: I do think that the 
COMPONENT keyword would actually fit in quite well into the new interface.

I guess the FindPackageHandleStandardArgs-maintainer is reading this list:
What do you think about adding component support?

Cheers,
  Johannes
___
Powered by www.kitware.com

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

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

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

[CMake] Wiki: version compatibility matrix

[Johannes Zarl]

Hello,

The compatibility matrix for different versions of cmake is now complete and 
awaits review: http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix

Apart from factual errors and things I might have missed, I am also interested 
if someone has a better idea for embedding the comments: they make the tables 
broader than they need to be. Also, the wiki warns that the page might be to 
big for some browsers. Should the page be divided into subpages?

If no one objects, I will add a link to the main-page under Development 
Topics by Wednesday next week (2010-12-08).

Cheers,
  Johannes
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Wiki: version compatibility matrix

[Johannes Zarl]

On 12/06/2010 at 12:33, David Cole david.c...@kitware.com wrote: 
 Wow!
 
 I wondered why all the responses here started with wow and then I
 clicked through to see for myself this morning.

Thank you all for your positive feedback, it is appreciated.

 This is a *great* page. Phenomenally complete summary. Is it going to
 be easy to add a column for CMake 2.8.4 after its release? Or is it
 going to be painful?

Wiki-wise it's easy to add another column, although time-consuming.
The best way to do this is to copy the wiki-code into a text-file
and then add a new column using a sensible text-editor.
You can use a regex to do this:
sed 's/^\(| [^|]*$\)/\1\n| style=background:green; | X/'

Afterwards, you would add new rows (this is less hassle, just copy an 
existing block) and adjust the values in each row.

 Can you describe how much effort this took on your part? (Number of
 hours estimate?)

I did it in my free time (obviously), so I didn't do any accounting.
I would estimate that it took about 8-12 hours (including breaks).

The time should scale pretty much linearly, so adding a new version
should take about an hour or so (depending on the number of changes).

 Can you contribute your helper scripts to the CMake code base itself?
 (Somewhere under CMake/Utilities perhaps...)

Sure, no problem. I don't have write-access to the code base, though.
I'll just send it to you, if that's ok...

  Johannes


-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










___
Powered by www.kitware.com

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

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

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

Re: [CMake] providing library information, what's the cmake way

[Johannes Zarl]

At this point of the discussion, I think that we need someone else to 
join. We both have made strong points for our viewpoints, and neither of 
us has a perfect solution. 

On Sunday 05 December 2010 12:48:49 Michael Hertling wrote:
 On 12/01/2010 05:57 PM, Johannes Zarl wrote:
  On 12/01/2010 at 16:06, Michael Hertling mhertling at online.de 
wrote:
  These variables are well-known and officially recommended for
  component- less packages only. Nobody bothered to write
  recommendations for component-packages yet.
 
 ${CMAKE_ROOT}/Modules/readme.txt mentions the XXX_YYY_EXECUTABLE and
 XXX_YY_{LIBRARY,INCLUDE_DIR} variables explicitly, and IMO, wordings
 as YYY tool that comes with XXX or YY library that is part of the
 XXX system allow the general terms tool and part to be applied
 smoothly to the components of a package. Furthermore, the component-
 specific variables like XXX_FIND_COMPONENTS are handled also, so I
 do believe that this file is relevant for multi-component packages,
 too, including the XXX_{LIBRARIES,INCLUDE_DIRS} variables. However,
 variables like XXX_YYY_{LIBRARIES,INCLUDE_DIRS} are not mentioned
 at all, i.e. there're completely new and should be well founded.

IMO the wording is ambiguous. When I read it, it was obvious to me that 
the XXX_YYY_LIBRARIES etc. are to be defined. To quote readme.txt:

 XXX_EXECUTABLE Where to find the XXX tool.
 XXX_YYY_EXECUTABLE Where to find the YYY tool that comes with XXX.

I assumed XXX_YYY_EXECUTABLE as an example, so that not every variable 
has to be mentioned a second time in its component-specific form.
Now that I heard your interpretation and reread readme.txt, it fits the 
description just as well.

 Anyway, the ${CMAKE_ROOT}/Modules/readme.txt doesn't handle multi-
 component packages thouroughly, so I would greatly appreciate any
 improvements to decrease ambiguities/uncertainties and to reach a
 consensus. For this reason, I regret that we haven't seen further
 opinions on this topic, in particular because pretty much every
 non-trivial package could make good use of a components-aware
 find module or config file.

As I have written above, I totally agree.

  The problem is that FPHSA simply wasn't created with components in
  mind. As worthwhile as code-reuse is, it's not a goal in itself.
  Rather than jump through hoops in order to reuse the existing
  interface, IMO one should create a good interface for the more
  complex use-case at hand.
 
 To apply FPHSA to a component and, thus, re-use existing code, I just
 need to define two variables; this is not jumping through hoops.

Setting a specific variable for its side-effects before calling a 
function makes a truly bad interface-style for me. Regardless of the 
outcome of this discussion, I'll create a patch for the FPHSA module 
introducing the component-keyword (once, I have time, whenever that is; 
a totally different topic is whether the patch will be included to 
cmake).

 
 Suppose you have components YYY and ZZZ with ZZZ depending on YYY.
 When handling ZZZ in the find module, there's a certain probability
 that you must access the YYY stuff, so one would like to have the
 XXX_YYY_FOUND variable already defined at this time. 

This is a sensible assumption, and should be supported by a component-
aware FPHSA...

 With the
 FPCHSA, the components' FOUND variables are defined in one go at the
 module's end; hence, one has to check YYY's availability by oneself
 when it's needed for ZZZ, and FPCHSA will do the same work once more
 later. 

Well, there currently does not exist a single line of code for a 
component-aware FPHSA. If it were to be implemented like this, There 
wouldn't be much incentive to use it.

 Instead, IMO, it's convenient to check a component's presence
 right after the relevant variables have received their values, and
 for this purpose, FPHSA is entirely sufficient.

Apart from the whole defining-variables-for-side-effect thing, yes. 
Still this would benefit from component-awareness:

...
FPHSA(XXX XXX_LIBRARIES XXX_INCLUDE_DIRS)
#detect component YYY
FPHSA(XXX COMPONENT YYY XXX_YYY_FOO XXX_YYY_BAR)
...

  find_package( XXX COMPONENTS YYY)
  target_link_libraries(foo ${YYY_LIBRARIES})
  find_package( XXX COMPONENTS ZZZ)
  target_link_libraries(bar ${ZZZ_LIBRARIES})
  
  At this point, I just realised that I was being inconsistent. After
  all, the components do depend on the whole package. So
  YYY_LIBRARIES should also contain XXX_LIBRARIES.
 
 If I understand correctly, you intend to populate XXX_YYY_LIBRARIES,
 e.g., with its own value XXX_YYY_LIBRARY *and all* its prerequisite
 components' values, too? If so, you will end up with many repeatedly
 mentioned libraries on the link command line unless there're hardly
 any inter-component dependencies. Suppose ZZZ depends on YYY, so
 


I have to admit that I didn't encounter a use-case with inter-component 
dependencies before this discussion, so my thoughts on this might be 
called developing

[CMake] Weird behaviour of functions with list arguments

[Johannes Zarl]

Hello,

I noticed that when defining a function, one can access lists as 
arguments using named arguments or ARGV0..ARGVn, but not using ARGV and 
ARGN.

To elaborate, assuming the function list_as_args defined as follows:
function(list_as_arg)
  message(STATUS ${ARGC} arguments, ARGV: ${ARGV})
  message(STATUS First argument: ${ARGV0})
  foreach(_arg ${ARGN})
message(STATUS Parsing argument ${_arg})
  endforeach(_arg)
endfunction(list_as_arg)

... and called with 2 arguments:
list_as_arg(list1a;list1b list2a;list2b)

...prints the following:
-- 2 arguments, ARGV: list1a;list1b;list2a;list2b
-- First argument: list1a;list1b
-- Parsing argument list1a
-- Parsing argument list1b
-- Parsing argument list2a
-- Parsing argument list2b

So ARGV0 is not the same as the first argument of ARGV. Why? Is it that 
the ARGV and ARGN lists get flattened, but the ARGVx are assigned before 
that?

How can I safely access the values of ARGN, if they might contain lists?

Thanks,
  Johannes
___
Powered by www.kitware.com

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

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

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

[CMake] Component support in FindPackageHandleStandardArgs

[Johannes Zarl]

Hello list,

During a recent discussion about find_package modules and components,
the question came up how to best use FindPackageHandleStandardArgs
(FPHSA) with components.

One solution that currently works is to call FPHSA several times with
the qualified component name as package name:

# Handle core package:
FPHSA(XXX DEFAULT_MSG XXX_LIBRARY XXX_INCLUDE_DIR)

# Handle explicitly requested component YYY:
# Set up (or not) XXX_YYY_LIBRARY, XXX_YYY_INCLUDE_DIR
SET(XXX_YYY_FIND_REQUIRED ${XXX_FIND_REQUIRED})
SET(XXX_YYY_FIND_QUIETLY ${XXX_FIND_QUIETLY})
FPHSA(XXX_YYY DEFAULT_MSG XXX_YYY_LIBRARY XXX_YYY_INCLUDE_DIR )

# Handle non-requested component ZZZ:
# Set up (or not) XXX_ZZZ_LIBRARY, XXX_ZZZ_INCLUDE_DIR
SET(XXX_ZZZ_FIND_REQUIRED FALSE)
SET(XXX_ZZZ_FIND_QUIETLY TRUE)
FPHSA(XXX_ZZZ DEFAULT_MSG XXX_ZZZ_LIBRARY XXX_ZZZ_INCLUDE_DIR )

IMO, the new syntax of FPHSA could easily extended to handle components
as well:

FPHSA(NAME [REQUIRED_VARS var1...varN]
 [COMPONENTS 
[COMPONENT cname cvar1..cvarN [COMPONENT cname 
cvar1..cvarN[..]]]
[[NO_]CHECK_REQUESTED_COMPONENTS]
 ]
 [VERSION_VAR   versionvar
 [CONFIG_MODE]
 [FAIL_MESSAGE Custom failure message] )

The component description begins with the keyword COMPONENTS, and has an
entry for each component (which starts with COMPONENT, followed by the 
component name (without the package-name prefix), and then lists all variables
required by the component. Components are checked after REQUIRED_VARS, in order
of their occurrence.

If CHECK_REQUESTED_COMPONENTS is set (=default), FPHSA also checks if any
other components have been requested by the user in the find_package command.

The three FPHSA calls from above could be written using this syntax as:
FPHSA(XXX REQUIRED_VARS XXX_LIBRARY XXX_INCLUDE_DIR
  COMPONENTS
COMPONENT YYY XXX_YYY_LIBRARY XXX_YYY_INCLUDE_DIR
COMPONENT ZZZ XXX_ZZZ_LIBRARY XXX_ZZZ_INCLUDE_DIR )

The attached patch implements this syntax for FPHSA.

Is this a desirable extension to FPHSA?

Cheers,
  Johannes



-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at












FindPackageHandleStandardArgs.cmake.diff
Description: Binary data
___
Powered by www.kitware.com

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

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

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

Re: [CMake] Weird behaviour of functions with list arguments

[Johannes Zarl]

On 01/18/2011 at 20:51, Alexander Neundorf a.neundorf-w...@gmx.net wrote: 
 On Saturday 11 December 2010, Johannes Zarl wrote:
 So ARGV0 is not the same as the first argument of ARGV. Why? Is it that
 the ARGV and ARGN lists get flattened, but the ARGVx are assigned before
 that?

 How can I safely access the values of ARGN, if they might contain lists?
 
 Do I understand correctly that you want to pass two lists of things to a 
 macro/function ?
 To do this, you have to separate them with keywords.
 
 Since version 2.8.3 (or was it 2.8.2 ?) CMake comes with the module 
 CMakeParseArguments.cmake which helps with evaluating such lists of 
 arguments. There you can find also documentation.

It turned out that the thing I wanted to do is not quite possible. 
AFAIK CMakeParseArguments can't handle keywords that appear more than once.
My basic idea for a workaround was to use one keyword with several 
list-arguments and have CMakeParseArguments return a list of lists for that
keyword. 

In the end, I did find another solution, though...

Cheers,
  Johannes


-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










___
Powered by www.kitware.com

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

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

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

Re: [CMake] Component support in FindPackageHandleStandardArgs

[Johannes Zarl]

On 01/18/2011 at 20:54, Alexander Neundorf a.neundorf-w...@gmx.net wrote: 
 On Monday 13 December 2010, Johannes Zarl wrote:
 The three FPHSA calls from above could be written using this syntax as:
 FPHSA(XXX REQUIRED_VARS XXX_LIBRARY XXX_INCLUDE_DIR
   COMPONENTS
 COMPONENT YYY XXX_YYY_LIBRARY XXX_YYY_INCLUDE_DIR
 COMPONENT ZZZ XXX_ZZZ_LIBRARY XXX_ZZZ_INCLUDE_DIR )

 The attached patch implements this syntax for FPHSA.

 Is this a desirable extension to FPHSA?
 
 Can you please add that to http://public.kitware.com/Bug/view.php?id=5920

Done.

 
 I'm not sure the current version of CMakeParseArguments.cmake supports 
 listing the same keyword multiple times.

That's true. In fact, the signature uses a single multiVAlueArg COMPONENTS
and then evaluates the COMPONENT ... entries using a loop.

Cheers,
  Johannes


-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










___
Powered by www.kitware.com

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

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

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

[CMake] Documentation for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT missing?

[Johannes Zarl]

Hi,

I just wanted to read the documentation on 
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, but discovered
that the variable is not listed in the cmake docs.

Is there a reason for this? Should I open a bugreport on it?

Cheers,
  Johannes


-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










___
Powered by www.kitware.com

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

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

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

Re: [CMake] newbie q - where do I put what in which CMakeLists file? out of source build

[Johannes Zarl]

 configure_file(src/config.h.in config.h)

In CMake, use of relative filenames is (mostly) discouraged. A robust
way to do this would be to write:

configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/src/config.h.in 
${CMAKE_CURRENT_BINARY_DIRECTORY}/include/config.h )

include_directories( ${CMAKE_CURRENT_BINARY_DIRECTORY}/include )

The include_directories tells cmake to add a 
-I/path/to/tone12/build/include directive,
so config.h can be found.

 
 ~/tone12/src/CMakeLists.txt:
 add_executable(tone12 tone12.cpp midi.cpp midi.h riffwave.cpp riffwave.cpp 
 tonegen.cpp tonegen.h)
 configure_file(config.h.in config.h)

It's normally not a good idea to call configure_file twice. You have to decide
which of the two configure_file statements you really want (which fits your 
project style,
is more robust when changing directory names,...).

You have the same issue with relative paths here, as above. If you want to 
configure
your header here, you could write:

configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/config.h.in 
${CMAKE_CURRENT_BINARY_DIRECTORY}/config.h )

include_directories( ${CMAKE_CURRENT_BINARY_DIRECTORY} )

(Current binary directory in this case evaluates to /path/to/tone12/build/src.)


HTH,
  Johannes


-- 
Johannes Zarl
Virtual Reality Services

Johannes Kepler University
Informationsmanagement

Altenbergerstrasze 69
4040 Linz, Austria
Phone: +43 732 2468-8321
johannes.z...@jku.at
http://vrc.zid.jku.at










___
Powered by www.kitware.com

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

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

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

Re: [CMake] Functions inherit parent variables?

[Johannes Zarl]

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

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

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

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

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

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

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


   
var_a: var_a outer  


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

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

Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Functions inherit parent variables?

[Johannes Zarl]

Drifting away from the original thread topic...

On Tuesday 06 March 2012, 08:09:27, Michael Hertling wrote:
 IMO, the documentation of the PARENT_SCOPE flag is sufficiently clear:
 
 If PARENT_SCOPE is present, the variable will be set in the scope
 *above* the current scope. Each new directory or function creates
 a new scope. This command will set the value of a variable into
 the *parent* directory or *calling* function (whichever is
 applicable to the case at hand).
 
 Not a word about setting anything in the current scope, 

Well, one could argue that not saying anything about the current scope means 
that it works in the current scope just as expected. 

I would have expected that when nothing is said about the current scope, the 
functionality in the current scope is unaffected by PARENT_SCOPE. Others might 
expect (correctly) that if nothing is said about the current scope, it doesn't 
apply to the current scope.

So: nothing _wrong_ with the documentation. It's just that people like me who 
have the wrong notion to begin with can read the documentation without 
realising that they are wrong.

 and as for me, the explanation of CACHE/INTERNAL/FORCE, e.g., is rather
 vague.

You're right. This assumes some knowledge about the cmake cache that is not 
really described anywhere in the docs.

Cheers,
  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Wiki: version compatibility matrix

[Johannes Zarl]

Hi David,

Yes, I should have time somewhere this week...

  Johannes

On Thursday, April 19, 2012 11:20:48 PM David Cole wrote:
 Hi Johannes,
 
 Time to update again, this time for CMake 2.8.8.
 
 Do you have time to do the update again in the next week or two?
 
 Thanks,
 David
 
 On Thu, Jan 5, 2012 at 4:47 PM, Johannes Zarl johannes.z...@jku.at wrote:
  Hi David,
  
  This is great news! I have updated the matrix to use footnotes, and also
  added the 2.8.7 changes to it. The whole matrix now looks much more
  clearly:
  
  http://www.cmake.org/Wiki/CMake_Version_Compatibility_Matrix
  
  Cheers,
   Johannes
  
  On Tuesday 03 January 2012 17:25:31 David Cole wrote:
  The Cite extension is now installed on the CMake wiki. See this page
  to see what mediawiki extensions are available:
  
  http://www.cmake.org/Wiki/Special:Version
  
  --
  
  Powered by www.kitware.com
  
  Visit other Kitware open-source projects at
  http://www.kitware.com/opensource/opensource.html
  
  Please keep messages on-topic and check the CMake FAQ at:
  http://www.cmake.org/Wiki/CMake_FAQ
  
  Follow this link to subscribe/unsubscribe:
  http://www.cmake.org/mailman/listinfo/cmake
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Wiki: version compatibility matrix

[Johannes Zarl]

Hi David,

I tried to upload the new matrix today, but the page on standard modules is 
too big (112kb): On my current internet connection I get a timeout before the 
upload finishes.

Maybe you can do the upload? The text is available from 
https://github.com/jzarl/cmake-
vcm/blob/master/split_page/StandardCMakeModules.txt

Otherwise, I'll do it some time next week.

  Johannes


On Thursday, April 19, 2012 11:20:48 PM David Cole wrote:
 Hi Johannes,
 
 Time to update again, this time for CMake 2.8.8.
 
 Do you have time to do the update again in the next week or two?
 
 Thanks,
 David
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Fwd: module and cmake

[Johannes Zarl]

Hello Paul,

I don't know about your specific find_package file for FFTW, but we do use 
modules together with CMake, so I'll add my thoughts:

As Eric already said, the modules command alters your environment. CMake 
doesn't know about shell modules, but most find_package commands provide some 
way to tell them about the location of a package by specifying an environment 
variable (normally something like PACKAGE_ROOT or PACKAGE_DIR). You'll 
have to look in the find-package script if this is the case with your 
FindFFTW.cmake script. If it's not written in the documentation on top of that 
file, search for $ENV.

If your FindFFTW3.cmake does not examine any environment variable, you should 
fix it in your project (and file a bug with the original project, if it's not 
your project). If that's not an option, it's probably best if you just set 
whatever variable your findFFTW3.cmake script expects as a clue as parameter 
to cmake (e.g. cmake .. -DFFTW3_INCLUDE_DIR=$FFTW3_ROOT/include).

So in summary, you should fix your module file to provide a suitable variable 
pointing to your installation root, and you should also fix poorly written 
FindXXX.cmake scripts circulating in the wild.

Somewhat off-topic, because it's got nothing to do with cmake and your 
specific problem: it's probably a good idea to prepend PKG_CONFIG_PATH with 
the pkgconfig directory of fftw. That way, autotool-based projects will be 
able to find it as well.

Cheers,
  Johannes



On Saturday 19 May 2012 14:42:49 Paul Anton Letnes wrote:
 Hi all.
 
 I am currently trying to create a more tidy CMakeLists.txt script for
 a simulation code I'm working on. The target platforms are mac and
 linux desktops (for development) and HPC [0] servers (all linux or, in
 some hypothetical future, unix systems). For the desktop/laptop case,
 it's mostly easy enough, as one installs libraries in a standard
 location - /opt, /usr/local, or something of that sort. On HPC
 servers, it is very common to install software in modules. I am not
 sure how well aquainted the CMake crowd is with the module system [1]
 so I'll post a brief explanation.
 
 HPC servers often have a large amount of users with varying
 requirements. Therefore, it is common to require, say, two different
 versions of a library, or the same library for two different
 compilers. As an example, a machine I'm currently using has several
 modules for the FFTW library. Example:
 paulanto@rocks:~/Rayleigh2D $ module avail fftw
 fftw/2.1.5  fftw/3.2.2(default)
 So, there's two different fftw versions available, and I'm currently
 using the default one as such:
 paulanto@rocks:~/Rayleigh2D $ module load fftw
 paulanto@rocks:~/Rayleigh2D $ module list
 Currently Loaded Modulefiles:
  1) fftw/3.2.2
 There we go. Now what does it mean to load a module? Well, basically,
 the module command works by adjusting environment variables:
 paulanto@rocks:~/Rayleigh2D $ module show fftw
 /share/apps/modulefiles/fftw/3.2.2:
 prepend-path CPATH /share/apps/modulessoftware/fftw/fftw-3.2.2/include
 prepend-path FPATH /share/apps/modulessoftware/fftw/fftw-3.2.2/include
 prepend-path LD_LIBRARY_PATH
 /share/apps/modulessoftware/fftw/fftw-3.2.2/lib
 prepend-path LIBRARY_PATH
 /share/apps/modulessoftware/fftw/fftw-3.2.2/lib We see that the fftw
 module sets various paths, and that these will all be different based on
 the exact version I'm using on the current machine. Hence, I can't tell
 beforehand, in my CMakeLists.txt, where to search for, say, libfftw3.a.
 
 So why am i ranting on about this? Well, basically
 find_package(FFTW3)
 does not find the fftw library, and other libraries I'm using (hdf5,
 mkl, ...) share the same fate. Previously I've just hand-added all
 sorts of include_directories and link_directories but I'm getting fed
 up and want to use the more elegant find_package approach, at least
 where possible. So, what am I asking?
 1) Is there a standard way for CMake to interact with modules?
 2) Is there a standard way to tell FindXXX.cmake (where XXX=fftw,
 hdf5, mkl, etc) where to search for libraries?
 3) Can I convince CMake to include link and include directores from
 the environment variables, like LIBRARY_PATH, FPATH etc?
 4) How do I handle LIBRARY_PATHs with multiple entries, such as this one?
 paulanto@rocks:~/Rayleigh2D $ echo $LIBRARY_PATH
 /share/apps/modulessoftware/fftw/fftw-3.2.2/lib:/share/apps/modulessoftware
 /hdf5/hdf-5.1.8.5-intel/lib:/share/apps/modulessoftware/openmpi/openmpi-1.4
 .3-intel/lib:/share/apps/modulessoftware/intel/compilers/11.1.059/lib/intel
 64:/share/apps/modulessoftware/intel/compilers/11.1.059/ipp/em64t/lib:/shar
 e/apps/modulessoftware/intel/compilers/11.1.059//mkl/lib/em64t:/share/apps/
 modulessoftware/intel/compilers/11.1.059/tbb/intel64/cc4.1.0_libc2.4_kernel
 2.6.16.21/lib
 
 Perhaps I'm not asking the right questions, but hopefully, some can
 tell me what I _should_ be asking. Or even better, the answer.
 
 Cheers
 Paul
 
 

[CMake] Disabling C for C++-only projects

[Johannes Zarl]

Hi,

Out of curiosity (and thinking about saving a couple of seconds during the 
first cmake run) I tried just to use C++ as language for some KDE program.

It turns out that without C enabled, standard modules like FindKDE, FindQt4 
and FindJPEG don't run because they use the CheckSymbolExists module.

I'm wondering if this counts as a bug in FindQt4 and FindKDE, because after 
all these two projects are C++, so any platform test should IMO be using the 
same compiler as the build-process does? 

Cheers,
  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Disabling C for C++-only projects

[Johannes Zarl]

On Wednesday 25 July 2012 22:20:55 Clinton Stimpson wrote:
 On Wednesday, July 25, 2012 10:06:27 PM Johannes Zarl wrote:
  I'm wondering if this counts as a bug in FindQt4 and FindKDE, because
  after all these two projects are C++, so any platform test should IMO be
  using the same compiler as the build-process does?
 
 This has already been fixed in FindQt4 since CMake 2.8.6.

...using cmake 2.8.9-rc1 from debian. 

But I'm absolutely fine with Alexander's statement that this is a (very low 
priority) bug. This means that my understanding of 
CheckSymbolExists and CheckCXXSymbolExists is not totally wrong and that it is 
basically ok to make a project without the C language being enabled.

Sorry about the noise ;-)

Cheers,
  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Disabling C for C++-only projects

[Johannes Zarl]

Am 26.07.2012, 17:53:01 schrieb Alexander Neundorf:
 On Thursday 26 July 2012, Johannes Zarl wrote:
  On Wednesday 25 July 2012 22:20:55 Clinton Stimpson wrote:
   This has already been fixed in FindQt4 since CMake 2.8.6.
  
  ...using cmake 2.8.9-rc1 from debian.
 
 if you use it together with FindKDE4.cmake, you get the copy of
 FindQt4.cmake coming with kdelibs, which apparently does not yet have
 these fixes applied.

Yes, that's it. Thanks for the info!

  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Bug fix requests for the *next* release of CMake...

[Johannes Zarl]

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

Powered by www.kitware.com

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

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

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

Re: [CMake] Total cmake newbie needs some help

[Johannes Zarl]

On Saturday, 18. August 2012, 00:16:41, Edgar wrote:
 I have these problems -
 1) Cmake cannot find ZLIB
 2) Cmake cannot find LIBPNG

 There are some .cmake files named FindALLEGRO, and FindFREETYPE, and
 those work properly. Do I need to create similar cmake files for zlib
 and libpng?

Those two are standard cmake modules[1][2]. You only have to point them to the 
location of your zlib/libpng installation. You can help cmake by setting the 
environment variable CMAKE_PREFIX_PATH to a colon-separated list of paths 
(e.g. /myopt:/usr/local).

In your case it might even suffice to set the cmake variable ZLIB_ROOT (libpng 
depends on zlib and therefore FindPNG.cmake will bail out if zlib is not 
found).

 3) There are undefined reference errors during the linking process for
 the OpenLayer demos, and I don't know how to properly link the necessary
 libraries using cmake.

You should read up on target_link_libraries [3] for that. Normally the usage 
pattern is something like the following:

FIND_PACKAGE(FOO REQUIRED)
TARGET_LINK_LIBRARIES(someTarget ${FOO_LIBRARIES})

Cheers,
  Johannes


[1] http://www.cmake.org/cmake/help/v2.8.9/cmake.html#module:FindZLIB
[2] http://www.cmake.org/cmake/help/v2.8.9/cmake.html#module:FindPNG
[3] 
http://www.cmake.org/cmake/help/v2.8.9/cmake.html#command:target_link_libraries
--

Powered by www.kitware.com

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

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

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

Re: [CMake] New wiki page CMake Live Cycle Considerations

[Johannes Zarl]

Thanks for the roses, Alex ;-)

On Monday, 8. October 2012, 20:24:32, Alexander Neundorf wrote:
 Hi,
 
 I just found this new page in the cmake wiki and I think this is very
 useful information:
 http://www.cmake.org/Wiki/CMake_Live_Cycle_Considerations
 
 Please help keeping it up-to-date
 
 Great work, Jzarl ! :-)
 Alex
--

Powered by www.kitware.com

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

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

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

Re: [CMake] New wiki page CMake Live Cycle Considerations

[Johannes Zarl]

On Tuesday, 9. October 2012, 12:25:51, Matt Williams wrote:
 On 8 October 2012 19:24, Alexander Neundorf a.neundorf-w...@gmx.net wrote:
  Hi,
  
  I just found this new page in the cmake wiki and I think this is very
  useful information:
  http://www.cmake.org/Wiki/CMake_Live_Cycle_Considerations
 
 Looks great. I was looking for something like this recently. However,
 shouldn't it be Life Cycle rather than Live Cycle?

Thanks, this is fixed now.

Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] How to use CMAKE_POLICY?

[Johannes Zarl]

Sorry if I add to the confusion, but shouldn't set cmake_minimum_required 
automatically set all policies newer than the specified version to old?

  Johannes

On Monday, 17. December 2012, 17:57:18, Alexander Neundorf wrote:
 On Monday 17 December 2012, David Cole wrote:
  I thought we wanted them to switch to the new behavior... Isn't that the
  goal of emitting warnings from policy implementations...?
 
 ...but not as long as the project still wants to keep the old minimum
 required cmake version (or am I mixing things up) ?
 
 Alex
 --
 
 Powered by www.kitware.com
 
 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html
 
 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ
 
 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

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

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

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

Re: [CMake] The else() in CMAKE_TOOLCHAIN_FILE

[Johannes Zarl]

Hi,

On Tuesday, 2. April 2013, 06:42:47, Ashi wrote:
 I think I find something to explain this: the config.cmake(the
 CMAKE_TOOLCHAIN_FILE) is reloaded several times. on first-load, the A is
 set, but on second-load and later-load, the A is not set. I think I can get
 around this problem when A is kept set. However, I don't know how can I
 keep the value set in cmake. Could anyone give me some suggestion? Thanks!

I'm not entirely sure what you're trying to do, but it seems like you would 
want to make A, B, and C into cache variables. That way subsequent cmake runs 
will use the same value...

  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Compiling object files.

[Johannes Zarl]

Hi Daniel,

On Wednesday, 3. April 2013, 16:06:36, Daniel Carrera wrote:
 Summary: How do I use CMake to compile object files? Or is this the
 wrong question to ask? (i.e. *should* I be compiling object files?)

Short answer: normally you don't and you shouldn't add statements to compile 
object files.

CMake is a build system generator, not a build-system in itself. I.e. you only 
tell cmake I want to build library A from source files a.cpp and b.cpp, and I 
want to link my application C , which is created from c.cpp, to the library 
A. CMake then generates the build system (e.g. Makefiles or a Visual Studio 
solution) for you.

 Details:
 -
 I am starting to learn CMake, so I am not even sure I am formulating
 my questions the right way... I have a large Makefile that I want to
 try to convert to CMake. I did not write the Makefile and I know
 little about build systems. But I am interested in CMake and I want to
 experiment anyway. 

If you have problems with the terminology and concepts behind cmake, I would 
recommend browsing through the wiki ( 
http://www.cmake.org/Wiki/CMake#Basic_Introductions ). While it can be 
overwhelming at first, there is a wealth of information to be found there.

 My first question is how to convert something like
 this:
 
 cparam.o:  cparam.f90 cparam.local cparam.inc cparam_pencils.inc
 if [  ]; then \
 rm -f cparam.inc; \
 rm -f cparam_pencils.inc; \
 ln -s cparam.inc cparam.inc; \
 ln -s cparam_pencils.inc cparam_pencils.inc; \
 fi
 $(FC) $(FFLAGS) $(FFLAGS_GENERAL) $(F90FLAGS) -o cparam.o -c
 cparam.f90
 
 
 I cannot imagine what the if statement could possibly accomplish, but
 I trust that CMake would make the whole thing unnecessary. 

The if statement is effectively just a block-comment. You can just ignore it 
and its contents.

 So I figure
 (hope) that all I have to do is tell CMake to make the object file
 cparam.o. The problem is that I cannot find anything in the
 instructions for making object files. All I see is commands like:
 
 
 add_executable(hello  hello.f90 world.f90)
 
 add_library(particles backend.f90 vector.f90 const.f90)
 
 
 There is no add_object function or anything like it... Maybe I am
 going about it the wrong way. Maybe I should not be thinking in terms
 of making object files at all. Perhaps I should be planning to do
 something like:
 
 add_executable(myprogram ${HUGE_LIST_OF_200_FILES})

That's the right way to go. Although if you have over 200 input files, you 
might want to group them into libraries if that's appropriate.

 My worry with this approach is that I see no room to convert the
 Makefile incrementally. I was thinking of compiling just one object
 file, check that that works and has the right symbols, and then move
 to the next object file. Whereas this other option looks like an all
 or nothing proposition.

Converting incrementally can't be done IMO (at least not without significant 
overhead). Since you would probably use the Makefile generator of cmake, you 
would probably just end up with cmake overwriting your makefiles or similar 
problems.

I hope that cleared up some of the confusion. Please do ask again if there are 
problems...

  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] CTest / CDash integration

[Johannes Zarl]

Probably someone else can give you a better answer, but I ended up doing the 
following:

ctest \
  --build-and-test $SOURCE_DIR $BUILD_DIR \
  --build-generator Unix Makefiles --build-makeprogram make \
  -j $PARALLEL_JOBS \
  --build-options -DCMAKE_CXX_COMPILER=$CXX -DCMAKE_C_COMPILER=$CC \
  --test-command ctest -D Nightly

I.e. the CTEST_SOURCE_DIRECTORY and CTEST_BINARY_DIRECTORY variables are set
by the --build-and-test sourcedir builddir argument, and the build options 
are only needed to pass extra variables to your build system.

HTH,
  Johannes

On Wednesday, 10. April 2013, 16:09:10, Martin Baute wrote:
 Sorry, but I have to keep complaining about the documentation. Please
 excuse the ranting.
 
 Just one example from the manual:
 
 ctest --build-options: Add extra options to the build step.
 This option must be the last option with the exception of
 --test-command
 
 End of available information.
 
 I have not been able to figure out which CTEST_* variable these options
 end up in, or how I could make them actually *affect* the build.
 
 I am also still looking for a reference of variables used by CTest.
 
 Quite obviously it is required to set both CTEST_SOURCE_DIRECTORY and
 CTEST_BINARY_DIRECTORY in your script, as CTest keeps telling you if
 you
 try to execute an empty script. I wonder if it wouldn't be easier if
 CTest
 would assume the current directory as BINARY_DIR and the script
 directory
 as SOURCE_DIR by default, but that might be just me.
 
 That I have to set CTEST_COMMAND manually when I obviously just called
 the
 executable, conveniently passing a working invocation in argv[0]).
 Strange.
 
 CTEST_SITE / CTEST_BUILD_NAME constitute the identification sent to the
 CDash server, as I found out perusing some example scripts on the Wiki,
 none of which really explaining what is done. Nice, but why ain't I
 told
 in plain English?
 
 As SVN user, I have to set CTEST_CHECKOUT_COMMAND myself (to something
 resembling svn checkout ${MY_REPOSITORY} ${CTEST_SOURCE_DIRECTORY}.
 Figured it out, works. But apparently CTEST_UPDATE_COMMAND is something
 else entirely, as CTest insists on appending update --non-interactive
 on its own accord...
 
 It is possible to trial  error your way around all this, but I would
 REALLY prefer to have a reference list, telling me which features I
 might
 be missing, or how I should escape quotation marks and semicolons in a
 -DCMAKE_PREFIX_PATH= statement. Or why a statement that works when
 given
 as CTEST_CONFIGURE_COMMAND fails when passed in ctest_configure(
 OPTIONS ).
 
 Hence, again my question: Is the man page and the half-dozen pages in
 the
 Wiki really all there is in freely available documentation on CTest?
 
 Regards,

--

Powered by www.kitware.com

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

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

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

Re: [CMake] The source directory

[Johannes Zarl]

Hi,

On Thursday, 18. April 2013, 09:02:13, 中野佑香 wrote:
 $ tar -xvzf gromacs-4.6.1.tar.gz
 $ cd gromacs-4.6.1
 $ mkdir build
 $ cd build
 $ cmake ..
 
 However, I got an error.
 ---
 CMake Error: The source directory
 /home/okayuka/Gromacs does not appear to contain CMakeLists.txt.
 Specify --help for usage, or press the help button on the CMake GUI.
 ---
 Inside gromacs-4.6.1 directory,
 there is certainly CMakeLists.txt.
 
 For this, I think cmake mistaking  /home/okayuka/Gromacs for
 /home/okayuka/Gromacs/gromacs-4.6.1 as ' the source directory'.

Looks pretty strange to me. To me this sounds just like what you would get if 
you had made a symlink:
$ tar -xvzf gromacs-4.6.1.tar.gz
$ mkdir build
$ cd gromacs-4.6.1
$ ln -s ../build .
$ cd build
$ cmake ..

 
 Would you please tell me how correct this mismatch of the source directory?

Do you get the same error if you point cmake to the absolute path of the 
source directory instead of ..?

Cheers,
  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Wiki: version compatibility matrix

[Johannes Zarl]

Hi,

Am 23.05.2013, 19:38:26 schrieb Alexander Neundorf:
 the matrix is getting a bit out of date, the last update is for 2.8.8.
 Can you try to create an updated version ?

No problem, I'll do it somewhere in the next few weeks.

  Johannes
--

Powered by www.kitware.com

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

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

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

Re: [CMake] Versioning and release/distribution management with cmake and git

[Johannes Zarl]

Hi,

On Monday, 23. September 2013, 23:41:19, Roger Leigh wrote:
 Another minor annoyance I've run into is that when I define a function and
 make use of a global variable, it appears to expand the variable during
 definition, rather than evaluating it when I call the function.  Is it
 possible to make the function evaluate the variable lazily at
 invocation time rather than when defined?

Can you condense this into a compact example? Last time I checked, the 
variables defined at function definition time are not preserved:

begin cmake snippet
set( global_var foo)
set( global_cache_var foo CACHE STRING undocumented)
function(testclosure)
message(global_var is ${global_var})
message(global_cache_var is ${global_cache_var})
endfunction()

set( global_var bar)
set( global_cache_var bar )
testclosure()
end cmake snippet

yields:
global_var is bar   


   
global_cache_var is bar

Kind regards,
  Johannes
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] How to write a correct wrapper of MESSAGE()?

[Johannes Zarl]

I guess you search for something like this:

function(info)
set(msg)
foreach(i RANGE ${ARGC})
set(msg ${msg}${ARGV${i}})
endforeach()
message(STATUS [info] ${msg})
endfunction()

message(Foo:bar;baz space FOO)
info(Foo:bar;baz space FOO)
message(two words)
info(two words)

...which yields the following output:

Foo:bar;baz spaceFOO
-- [info] Foo:bar;baz spaceFOO
twowords
-- [info] twowords

The IN LISTS signature of foreach seems to do additional list splitting, 
leading to (foo;bar baz) appearing as 3 elements. Accessing the ARGV array 
by the positional indices (e.g. ${ARGV0}) prevents the splitting.

HTH,
  Johannes

On Wednesday, 9. October 2013, 05:33:26, Clark WANG wrote:
 On Sat, Oct 5, 2013 at 1:38 AM, Matthew Woehlke
 matthew.woeh...@kitware.com
 
  wrote:
  
  On 2013-09-27 04:18, Clark WANG wrote:
  I'm trying to write some MESSAGE() wrappers like info(), warning(),
  fatal(), etc which may be a bit easier to use. But I failed to simulate
  the
  correct MESSAGE() behavior no matter I use MACRO or FUNCTION. For
  example: [snip]
  
  FUNCTION vs MACRO shouldn't make a difference in argument parsing AFAIK.
  The difference is primarily that FUNCTION creates a scope, while MACRO
  operates in the scope from which it is called.
  
  The behavior of MESSAGE seems to concatenate multiple arguments with no
  separators. So maybe you could do something like:
  
  set(msg )
  foreach(part IN LISTS ARGN)
  
set(msg ${msg}{$part})
  
  endforeach()
  # ...do stuff with ${msg}
 
 This does not work either. For example:
 
 $ cat CMakeLists.txt
 cmake_minimum_required(VERSION 2.8)
 
 FUNCTION(info_f)
 set(msg )
 foreach(part IN LISTS ARGN)
   set(msg ${msg}${part})
   endforeach()
 message([info_f] ${msg})
 ENDFUNCTION()
 
 MACRO(info_m)
 set(msg )
 foreach(part IN LISTS ARGN)
   set(msg ${msg}${part})
   endforeach()
 message([info_m] ${msg})
 ENDMACRO()
 
 message(foo;bar)
 info_f(foo;bar)
 info_m(foo;bar)
 $ cmake .
 foo;bar
 [info_f] foobar
 [info_m]
 $
 
  (I like ARGN since it is 'unnamed positional arguments'. Since you have
  no named arguments, ARGV == ARGN, but generally speaking I can't think
  of why you'd ever need to use ARGV.)
 
 Good point.
 
  --
  Matthew
  
  --
  
  Powered by www.kitware.com
  
  Please keep messages on-topic and check the CMake FAQ at:
  http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
  
  
  Kitware offers various services to support the CMake community. For more
  information on each offering, please visit:
  
  CMake Support:
  http://cmake.org/cmake/help/**support.htmlhttp://cmake.org/cmake/help/s
  upport.html CMake Consulting:
  http://cmake.org/cmake/help/**consulting.htmlhttp://cmake.org/cmake/hel
  p/consulting.html CMake Training Courses:
  http://cmake.org/cmake/help/**training.htmlhttp://cmake.org/cmake/help/
  training.html
  
  Visit other Kitware open-source projects at http://www.kitware.com/**
  opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.h
  tml
  
  Follow this link to subscribe/unsubscribe:
  http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailma
  n/listinfo/cmake

--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] ARGC != list(LENGTH ARGV) and ARGV0 != list(GET ARGV 0)

[Johannes Zarl]

 CMake will not expand a string into a list when passed as arguments. It
 would do when using a variable:

While this is true, it's also not the whole truth (and I guess is that this is 
bothering Clark). Consider the following two function calls:

foo1(a;b;c)
foo2(a;b c)

Of course cmake recognises foo1 as having one parameter, and foo2 as having 2 
parameters. And if you do use names arguments in your function, or access the 
function arguments by their positional arguments, it works as expected:

function(foo2)
  message(Arg0: ${arg0}) # Arg0: a;b
  message(${ARGC} arguments.) # 2 Arguments.
endfunction()

If, however you try to access the argument list as a whole, you fall in the 
list of lists trap. CMake can not have lists as elements of other lists. 
Trying to use the ARGV or ARGN lists in the above example will not achieve 
what you are trying to do, because when cmake assembles the list of arguments, 
the (for lack of a better word) list property is lost:

set(mylist)
list(ADD mylist a;b)
list(LENGTH mylist n)
message( length is ${n}) # length is 2

Cheers,
  Johannes
  

--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] How to write a correct wrapper of MESSAGE()?

[Johannes Zarl]

On Monday, 14. October 2013, 19:07:06, Matthew Woehlke wrote:
  The IN LISTS signature of foreach seems to do additional list
  splitting, leading to (foo;bar baz) appearing as 3 elements.
  Accessing the ARGV array by the positional indices (e.g. ${ARGV0})
  prevents the splitting.
 
 Really? That... is surprising. I thought the whole point of 'IN LISTS'
 was to take a variable that already contains a list and NOT do
 additional splitting (the way 'foreach(NAME ${LIST})' would)...

While the behaviour here is hardly what one would expect, the list is not 
really split.

What happens, is the following:
 1) Function info gets two parameters: foo;bar and baz
 2) The ARGV list is created by adding the parameters to the list:
set(ARGV)
list(ADD ARGV foo;bar) # here the foo;bar list is flattened
list(ADD ARGV baz)
 Since a list cannot contain another list, we get a flattened representation
 of  the arguments: ARGV == foo;bar;baz
 3) foreach(name IN LISTS ARGV) only gets to see the flattened representation
 contained in ARGV.

  Johannes
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

[CMake] How to test for the usability of a target

[Johannes Zarl]

Hi,

I'd like to make some code in my build system dependent on the existance of a 
target. Basically I'd like to write something like this:

if(TARGET optional_lib)
  add_library(bar ${bar_srcs})
  target_link_library(bar optional_lib)
endif()

The problem I have is that for a couple of reasons the CMakelists file for bar 
needs to be read before optional_lib. Therefore the TARGET optional_lib test 
fails even though I can link bar successfully against optional_lib.

As a simple test case, consider the following:

#CMakeLists.txt:
cmake_minimum_required ( VERSION 2.8.9 )
add_executable ( main ${CMAKE_CURRENT_SOURCE_DIR}/main.c )
target_link_libraries ( main foo )
if ( NOT TARGET foo )
message(foo is not a target)
endif()
add_library(foo ${CMAKE_CURRENT_SOURCE_DIR}/foo.c)
##

#foo.c:
int FOO=23;
##

#main.c:
extern int FOO;
int main() {
  return FOO;
}
##

Running CMake on this project prints foo is not a target, but main is built 
and linked successfully and correctly.

I'm currently working around the issue by letting the optional lib set a cache 
variable and testing for the variable instead of the target. Is there a way to 
actually get the information from the bulid system, or is this a hard limit of 
the CMake parser?

Cheers,
  Johannes
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] How to test for the usability of a target

[Johannes Zarl]

On Wednesday, 16. October 2013, 01:22:09, Matthew Woehlke wrote:
 If you *REALLY* need to know about all your targets before you decide on
 linking, then you're going to have to implement multi-pass project
 parsing. This is possible - see e.g. VTK - but makes the configuration
 process much more difficult to follow, can lead to serious maintenance
 issues, etc. The less magic involved in your build system, the better.

Ok, I'll just stick with the current setup, then. At least that's relatively 
easy to understand and doesn't complicate the build proces...

 Personally, I'd say this smells like poor design that needs to be
 rethought. Maybe what you really want is a plugin system?

It *is* poor design in the build system. It's just that sometimes working 
around a technical issue is easier than changing the organisation of thing ;-)

Thanks,
  Johannes

--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] How to test for the usability of a target

[Johannes Zarl]

On Wednesday, 16. October 2013, 19:45:32, Alexander Neundorf wrote:
 On Tuesday 15 October 2013, Johannes Zarl wrote:
  I'd like to make some code in my build system dependent on the existance
  of a target. Basically I'd like to write something like this:
  
  if(TARGET optional_lib)
  
add_library(bar ${bar_srcs})
target_link_library(bar optional_lib)
  
  endif()
  
 Can generator expressions maybe be used for that ?
 They are evaluated at generate time, so at a time when the target is know
 to exist or not.

Yes, that should probably work for my use case. I hadn't thought of that.

Thanks!
  Johannes
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] How to write a correct wrapper of MESSAGE()?

[Johannes Zarl]

On Thursday, 17. October 2013, 07:12:51, Clark WANG wrote:
 When I'm using CMake more and more I find it's not a real serious
 language. It's so tricky.

I can see why you are frustrated. I don't think it's all bad though. Hopefully 
CMake3 will be used for some language cleanups at the expense of breaking some 
backwards-compatibility...

  Johannes
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

[CMake] Wiki update needed: CMake/Tutorials/How to create a ProjectConfig.cmake file

[Johannes Zarl]

Hi,

I noticed that the tutorial for creating ProjectConfig files[1] in the wiki is 
not really up to date anymore. To be precise, the CMakePackageConfigHelpers 
cmake module is not mentioned on the page.

The main author of the tutorial goes by the username Themiwi.

@Themiwi: if you are reading this: could drop me a quick note whether you have 
the time to update the wiki page or not?

Thanks,
  Johannes


[1] CMake/Tutorials/How to create a ProjectConfig.cmake file: 
http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file
--

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] CMake and shared|static/release|debug?

[Johannes Zarl]

Hi,

On Tuesday, 4. February 2014, 23:41:55, Littlefield, Tyler wrote:
 I've tried this a few different ways and ran into issues. If someone
 wouldn't mind pointing out where I'm going wrong, I would appreciate it.
 (for example if there's a better way to do what I'm trying).

It would help if you also included a textual description of the thing you want 
to achieve and your issues. Since the cmake compiler does not do what you want 
it to do, it is quite plausible that the people on this list having a good 
understanding of cmake will misinterpret your cmake code...

That aside, as Jakub pointed out, it seems that you try to reimplement the 
CMAKE_BUILD_TYPE support on your own.

As to the shared library stuff: CMake can already build shared and static 
libraries in the same build:

set( MYLIB_SRCS mylibsource1.cxx mylibsource2.cxx)
add_library( mylib-static STATIC ${MYLIB_SRCS})
add_library( mylib-static SHARED ${MYLIB_SRCS})

If you want to make it a choice, you could do it like this:

set( BUILD_LIBTYPE SHARED CACHE STRING SHARED or STATIC )
# enforce string in the gui:
set_property(CACHE BUILD_LIBTYPE PROPERTY STRINGS SHARED STATIC)
if ( NOT BUILD_LIBTYPE STREQUAL STATIC )
  set ( BUILD_LIBTYPE SHARED CACHE STRING  FORCE)
endif()

add_library( mylib-static ${BUILD_LIBTYPE} ${MYLIB_SRCS})

HTH,
  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Overriding found jpeg

[Johannes Zarl]

On Thursday, 6. February 2014, 13:30:54, Ramin Kamal wrote:
 Thanks! I tried that, but it still finds the system library. Here's my test
 setup:

I tried with basically the same steps, and it works for me.

 
 % cd /usr/lib
 % cp libjpeg.* /tmp/myjpeg/lib/
 [...]
 -- Found JPEG: /usr/lib64/libjpeg.so
 *path is /usr/lib64/libjpeg.so*

I see that you are using the libjpeg.so from /usr/lib for your /tmp/myjpeg 
directory, but the system libjpeg is in /usr/lib64. Could it be that the 
libjpeg in your custom directory is just not compatible? Does the problem 
appear even when you are copying the libjpeg.so from lib64 instead?

Cheers,
  Johannes

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Explanation....

[Johannes Zarl]

Hello Theo,

On Friday, 11. April 2014, 14:20:36, Theodore Papadopoulo wrote:
 ::-B-::  - This shows that B is indeed parsed as OPTIONAL
 
 A
 A- Fine I'm in the else part of the if
 OPTIONAL
 HERE - Fine.

... I guess OPTIONAL should read TOTO. You say it's fine, but it's 
probably not what you expected.

Let's take this step by step:

if (${arg} STREQUAL TOTO)
- if (TOTO STREQUAL TOTO)
- if (B STREQUAL B)

So, the expression evaluates to true.

 B
 HERE - ???

Now this should not come as a surprise:

if (${arg} STREQUAL TOTO)
- if (B STREQUAL TOTO)
- if ( B STREQUAL B)

You could add a prefix to your if expression (I'm sure you have seen this 
technique in configure scripts*g*):

if ( _ASDF_${arg} STREQUAL _ASDF_TOTO)

HTH,
  Johannes


P.S.: To get better visibility on mailing lists, it's best if you start a new 
thread instead of just replying to a message and changing the subject line.


-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Explanation....

[Johannes Zarl]

Hi,

On Monday, 14. April 2014, 19:23:19, Theodore Papadopoulo wrote:
  if (${arg} STREQUAL TOTO) - if (TOTO STREQUAL TOTO) - if
  (B STREQUAL B)
 
 What I do not follow is why there is an implicit evaluation of TOTO
 into B (in both this case or the next I explicitely asked for a
 string containing the content of the variable ${arg}, if I had
 intended the content of the variable which name is in ${arg} I would
 have written ${${arg}}.

If it is any consolence to you, this is one of the most-hated (anti-)features 
of cmake. The best you can do is to embrace this oddity (it's not going to go 
away soon), and use a different idiom:

Instead of ``${var} STREQUAL VALUE'', write:

IF ( var MATCHES ^VALUE$ )
- The MATCHES expression only does string/variable expansion on the right 
side. Therefore you get a well-defined behaviour regardless of any possible 
aliasing effects on variable names and values.

 Of course, you are right about what happened, it is just very unsafe.
 That means that if I'm using as a variable name the name of a constant
 used in some other module, there will be very unexpected failures

You are totally right. I guess if there was a way to change this in a 
backwards-compatible way, cmake developers would not hesitate to do so.

 For example taking /usr/share/cmake/Modules/FeatureSummary.cmake as an
 example, if I set a variable PROPERTIES with a value might (untested)
 provoke quite unexpected results (if(NOT ${_props} STREQUAL
 PROPERTIES)). Or if I do set(0 1) before calling
 CheckLanguage.cmake (if(CMAKE_${lang}_COMPILER AND ${result}
 STREQUAL 0)).

You can have even more fun by redefining some version strings:

set(MY_VERSION 2.8.15)
set(2.8.15 hehehe)
if (MY_VERSION VERSION_EQUAL 2.8.15 )
message(All as expected...)
else()
message(I'm so evil!)
endif()
# You can probably guess what this prints out ;-)

IMO one thing that *could* be done would be to deprecate the unsafe 
expressions and replace them with some safe version.

 I realize now that this is what probably means the
  if(variable|string STREQUAL variable|string)
 in the cmake manual. But in my reading that was meaning some
 overloading so that
 
 TOTO is a variable so evaluated into ${TOTO}
 but TOTO remains a string and is not evaluated any further.
 
 At least that what I thought (basically at some type system
 differentiating variables and strings)... I'm clearly wrong as:
 
 set(TOTO B)
 if (B STREQUAL TOTO)
 message(AhAh)
 endif()

What helped me to understand it was to see this as a two-step procedure:

1) Parsing: ${variable} gets replaced by its value
2) Execution: IF is called with the strings as argument.

At step 2, the IF statement cannot possibly determine how its arguments looked 
before expansion.


  if ( _ASDF_${arg} STREQUAL _ASDF_TOTO)
 
 Well I knew the technique, but thought it was mainly for protection
 againts empty strings (which ${arg} should be equivalent). Not sure
 it makes the thing safer though.
 
 Well I guess I need to go and see cmake source code, as I cannot
 understand cery well its evaluation rules.

Sorry for my mistake in the first mail. I wrote my response rather quick, not 
pausing to think of better alternatives. Had I invested more time, I would've 
given you the solution using MATCHES that I explained above. Sorry for the 
inconvenience...

Cheers,
  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Explanation....

[Johannes Zarl]

On Wednesday, 16. April 2014, 12:03:30, Rolf Eike Beer wrote:
  Instead of ``${var} STREQUAL VALUE'', write:
  
  IF ( var MATCHES ^VALUE$ )
 
 NO, please don't! I try hard to kill all those as it requires
 compiling a regular expression for a simple string match. Just change it
 to something that is no valid variable name, i.e. will never get
 expanded:

In principle, you are right. Not too sure, though, whether such a big NO 
is warranted. A quick test shows the overhead to be existing, yet not too 
severe:

foreach(arg RANGE 1)
#a) if (  ${foo} STREQUAL  ${arg})
#b) if ( foo MATCHES ^${arg}$)
message(Found it!)
endif()
endforeach()

Method b) has to compile 10.000 regexes, yet the runtime is only 30% worse. 
And that is even though this example does the opposite of the normal use-case 
of the regex, i.e. keeping one fixed regex and matching the variables against 
it. I doubt that the overhead is even measurable in the average build 
system.

#a)
$ time cmake .
-- Configuring done
-- Generating done
-- Build files have been written to: /home/zing/scratch/foo

real0m0.210s
user0m0.136s
sys 0m0.012s

#b)
$ time cmake .
-- Configuring done
-- Generating done
-- Build files have been written to: /home/zing/scratch/foo

real0m0.278s
user0m0.220s
sys 0m0.004s

Or are you talking about memory overhead?


 
 if ( ${arg} STREQUAL  TOTO)

Kudos to you for presenting a (the only?) *safe* prefix.

  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Explanation....

[Johannes Zarl]

On Wednesday, 23. April 2014, 18:54:39, Matthew Woehlke wrote:
  if ( ${arg} STREQUAL  TOTO)
 
 set( TOTO evil)

You sure? When I checked, this did not work. Also, the following gives me a 
syntax error:

set ( foo Evil!)
message( ${ foo})

  Syntax error in cmake code at
/home/zing/scratch/cmake_testbed/CMakeLists.txt:100
  when parsing string
${ foo}
  syntax error, unexpected cal_SYMBOL, expecting } (7)

 See also
 http://permalink.gmane.org/gmane.comp.programming.tools.cmake.devel/9936.

This is totally different, in that it uses an unsafe prefix. Just like the 
_ASDF_ I used in my first response, the x *can* be the beginning of a 
variable name. The space can not start a vaariable name.

Cheers,
  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Explanation....

[Johannes Zarl]

On Thursday, 24. April 2014, 17:34:40, Matthew Woehlke wrote:
 On 2014-04-24 04:53, Johannes Zarl wrote:
  On Wednesday, 23. April 2014, 18:54:39, Matthew Woehlke wrote:
  if ( ${arg} STREQUAL  TOTO)
  
  set( TOTO evil)
  
  You sure? When I checked, this did not work.
 
 Are *you* sure? :-)

Yes, I am. For the specific use-case given in this thread (the STREQUAL), the 
prefix *is* safe to use. I still prefer the MATCHES syntax, as it is not too 
much overhead and prods the programmer to think about why it was used and what 
is happening.

And of course, David Cole is totally right when he says:

 It's just ridiculous to waste time trying to justify the existing
 behavior. It's more confusing than useful, and ought to be changed.


 Right; *explicit* expansion is limited in what characters are allowed.
 As David Cole points out, you must expand such variables indirectly. Of
 course, implicit expansion counts as indirect expansion, which is why
 there is no safe character/prefix that can guarantee implicit expansion
 won't occur.

I'm always happy to learn something new. How would you manage to make the 
following if statement trigger?

set( arg value)
if ( ${arg} STREQUAL  TOTO )
  message ( arg equals 'TOTO', and arg equals 'value' )
endif()


 (And - again as David Cole already noted - you didn't get an error in
 the set() command, did you?)

No, but the if statement didn't trigger, either.


 On 2014-04-24 06:31, David Cole wrote:
  I, for one, would fully support breaking backwards compatibility to fix
  this, and be strict with variable and macro and function name
  identifiers.
 
 Of course, the *real* problem is implicit expansion. The permissiveness
 of variable naming makes it harder to work around this, but would be
 less of an issue if implicit expansion was less eager.

I aggree 100% with both of you, here.

Cheers,
  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

[CMake] Typo in cmake-packages(7)

[Johannes Zarl]

Hi,

In cmake-packages(7) [1], there is a typo that prevents the example from 
working correctly.

The command
 configure_file(cmake/ClimbingStatsConfig.cmake
   ${CMAKE_CURRENT_BINARY_DIR}/ClimbingStats/ClimbingStatsConfig.cmake
   COPY_ONLY
 )

should use COPYONLY, not COPY_ONLY.

Cheers,
  Johannes



P.S.: I really like the new documentation website. Kudos to whoever had the 
idea for this!


[1] http://www.cmake.org/cmake/help/git-master/manual/cmake-
packages.7.html#creating-packages
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Install path for package files

[Johannes Zarl]

As is also written in the stackoverflow answer, this information can be found 
in the cmake documentation for find_package[1]:

 prefix/   (W)
 prefix/(cmake|CMake)/ (W)
 prefix/name*/   (W)
 prefix/name*/(cmake|CMake)/ (W)
 prefix/(lib/arch|lib|share)/cmake/name*/  (U)
 prefix/(lib/arch|lib|share)/name*/(U)
 prefix/(lib/arch|lib|share)/name*/(cmake|CMake)/  (U)
 
 On systems supporting OS X Frameworks and Application Bundles the following
 directories are searched for frameworks or bundles containing a
 configuration file: prefix/name.framework/Resources/  
  (A)
 prefix/name.framework/Resources/CMake/  (A)
 prefix/name.framework/Versions/*/Resources/ (A)
 prefix/name.framework/Versions/*/Resources/CMake/   (A)
 prefix/name.app/Contents/Resources/ (A)
 prefix/name.app/Contents/Resources/CMake/   (A)

Just use any directory based on your target platform and you're fine.

[1] http://www.cmake.org/cmake/help/v3.0/command/find_package.html

HTH,
  Johannes

On Friday, 3. October 2014, 12:22:57, Alexander Lamaison wrote:
 Noah Roberts roberts.n...@gmail.com
 writes:
 
 snip
 
  I gather I need to create a BlahModule.cmake file that implements the
  package finding stuff.  I want to install this wherever cmake will find
  it.  I don't want to put it in some place in the system and then expect
  dependent CMakeLists.txt files to set that path when using
  find_package.
 
 snip
 
  So what is the variable I use in the install() function for the
  DESTINATION parameter to do this?  I assume there must be one...  I
  can't seem to find it in the documentation though.
 
 Me neither.  This answer [1] lists the places that CMake looks for the
 BlahConfig.cmake file so on Unix it's fairly simple.  Set the
 DESTINATION to 'lib' which will install it to
 /usr/local/lib/BlahConfig.cmake where, presumable, find_package will
 locate it.  I don't understand how this is meant to work on Windows,
 though.  How is CMake meant to know which root to start thee search
 under?
 
 [1] http://stackoverflow.com/a/11965673/67013
 
 Alex

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] 2 libs stuck together !

[Johannes Zarl]

Hi,

It would be a lot easier to help you if you tried to minimize the 
CMakeLists.txt file before posting it to the list. The file as you posted it 
contains many unrelated stuff and even commented-out lines.

Not wanting to look at the whole thing as it is, my advice to you is to search 
for the lines in which you add the pthread and opencv_calib3d lines. Maybe you 
used quotes incorrectly when adding these lines...

Cheers,
  Johannes

On Thursday, 9. October 2014, 14:06:29, jay75 wrote:
 i am working on ros indigo, ubuntu 14.04 trusty, opencv 2.4.9
 
 i get this message:
 /usr/bin/ld: cannot find -lopencv_calib3dlibpthread
 
 now, libpthread.so.0  and libopencv_calib3d.so are two separate libs in
 /usr/lib/x86_64-linux-gnu/, which i have added successfully to my
 link_libraries. what am i doing wrong? here is my cmakelists.txt :
 cmake_minimum_required(VERSION 2.8.3)
 project(hal_main)
 
 find_package(cmake_modules REQUIRED)
 find_package(Eigen REQUIRED)
 find_package(Boost REQUIRED thread date_time system filesystem
 program_options python )
 
 ## Find catkin macros and libraries
 ## if COMPONENTS list like find_package(catkin REQUIRED COMPONENTS xyz)
 ## is used, also find other catkin packages
 find_package(catkin REQUIRED COMPONENTS
   actionlib
   actionlib_msgs
   message_generation
   roscpp
   rospy
   std_msgs
   genmsg
   visualization_msgs
   clam_controller
   clam_msgs
   pcl_ros
   cv_bridge
   eigen_conversions
   moveit_msgs
   geometry_msgs
   moveit_ros_planning
   moveit_ros_planning_interface
   tf
   tf_conversions
   moveit_simple_grasps
   cmake_modules
   moveit_core
   # eigen_conversions
 )
 
 
 
 find_package(OpenCV REQUIRED )
 find_package(OpenCV 2 REQUIRED )
 #find_package(OpenCV 2 REQUIRED COMPONENTS calib3dlibpthread)
 
 include_directories(${EIGEN_INCLUDE_DIRS})
 
 add_definitions(${EIGEN_DEFINITIONS})
 
 #SET( CMAKE_MODULE_PATH /usr/share/cmake-2.8/Modules/ )
 #set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH}
 ${CMAKE_SOURCE_DIR}/share/cmake_modules/cmake/Modules/)
 
 find_package(MySQL REQUIRED COMPONENTS libmysqlcppconn.so.7.1.1.3)
 include_directories(${MYSQL_INCLUDE_DIRS})
 add_definitions(${MYSQL_DEFINITIONS})
 #link_directories(/usr/lib/mysql/plugin/${MYSQL_LIBRARY_DIRS})
 
 
 
 #find_package(OpenCV2 REQUIRED)
 #find_package(mysql REQUIRED)
 ## System dependencies are found with CMake's conventions
 # find_package(Boost REQUIRED COMPONENTS system)
 
 
 ## Uncomment this if the package has a setup.py. This macro ensures
 ## modules and global scripts declared therein get installed
 ## See http://ros.org/doc/api/catkin/html/user_guide/setup_dot_py.html
 # catkin_python_setup()
 
 
 ## Declare ROS messages, services and actions ##
 
 
 ## To declare and build messages, services or actions from within this
 ## package, follow these steps:
 ## * Let MSG_DEP_SET be the set of packages whose message types you use in
 ##   your messages/services/actions (e.g. std_msgs, actionlib_msgs, ...).
 ## * In the file package.xml:
 ##   * add a build_depend and a run_depend tag for each package in
 MSG_DEP_SET
 ##   * If MSG_DEP_SET isn't empty the following dependencies might have
 been ## pulled in transitively but can be declared for certainty
 nonetheless: ## * add a build_depend tag for message_generation
 ## * add a run_depend tag for message_runtime
 ## * In this file (CMakeLists.txt):
 ##   * add message_generation and every package in MSG_DEP_SET to
  #find_package(catkin REQUIRED COMPONENTS actionlib_msgs geometry_msgs
 moveit_msgs )
 ##   * add message_runtime and every package in MSG_DEP_SET to
 ## catkin_package(CATKIN_DEPENDS ...)
 ##   * uncomment the add_*_files sections below as needed
 ## and list every .msg/.srv/.action file to be processed
 ##   * uncomment the generate_messages entry below
 ##   * add every package in MSG_DEP_SET to generate_messages(DEPENDENCIES
 ...)
 
 ## Generate messages in the 'msg' folder
  add_message_files(
FILES
instr_set_arm.msg
instr_set_legs.msg
object.msg
  )
 
 ## Generate services in the 'srv' folder
 # add_service_files(
 #   FILES
 #   Service1.srv
 #   Service2.srv
 # )
 
 ## Generate actions in the 'action' folder
  add_action_files(
FILES
arminstr.action
leginstr.action
objrecog_posit.action
sendcommand.action
 
  )
 
 ## Generate added messages and services with any dependencies listed here
  generate_messages(
DEPENDENCIES
actionlib_msgs
std_msgs
geometry_msgs
moveit_msgs
 
  )
 
  catkin_package(
   CATKIN_DEPENDS
   actionlib
   actionlib_msgs
   message_generation
   roscpp
   rospy
   std_msgs
   genmsg
   visualization_msgs
   clam_controller
   clam_msgs
   pcl_ros
   cv_bridge
   eigen_conversions
   moveit_msgs
   geometry_msgs
   moveit_ros_planning
   moveit_ros_planning_interface
   tf
   tf_conversions
   moveit_simple_grasps
   moveit_core
 

Re: [CMake] Is this the proper way to define a package config?

[Johannes Zarl]

Hi,

Assuming you are not a boost developer / your changes won't be upstreamed, 
then creating a BoostConfig.cmake file won't do you much good. If someone wants 
to use your project, he/she will have to patch the locally installed boost 
version to include a BoostConfig.cmake file.

You might want to have a look into the FindBoost[1] module of cmake.

XXXConfig.cmake files are intended to be written by the creator of a package, 
FindXXX.cmake packages are intended as a workaround when a package does not 
contain an XXXConfig.cmake file and are usually written by a consumer of a 
package.

HTH,
  Johannes

[1] http://www.cmake.org/cmake/help/v3.0/module/FindBoost.html

On Friday 17 October 2014 00:18:34 Robert Dailey wrote:
 I have a local package of boost built on Windows. It is always
 relative to the root of my project at a consistent structure and
 location. I wanted to define an import target for this and thought it
 might be best to define a BoostConfig.cmake package config file at the
 root of the boost lib directory. Is this the right approach? The code
 is below.
 
 Note that I do not have this working just yet because I don't know how
 to properly setup the interface link libraries. Could use some
 guidance here too... thanks.
 
 add_library( Boost STATIC IMPORTED GLOBAL )
 
 file( GLOB boost_debug_libs ${CMAKE_CURRENT_LIST_DIR}/lib/win32/debug/*.lib
 ) file( GLOB boost_release_libs
 ${CMAKE_CURRENT_LIST_DIR}/lib/win32/release/*.lib )
 
 set_target_properties( Boost PROPERTIES
 IMPORTED_LOCATION_DEBUG lib/win32/debug
 IMPORTED_LOCATION_RELEASE lib/win32/release
 INTERFACE_INCLUDE_DIRECTORIES include
 INTERFACE_LINK_LIBRARIES
 $$CONFIG:Debug:${boost_debug_libs}
 $$CONFIG:Release:${boost_release_libs}
 )
 
 set( Boost_INCLUDE_DIRS include )
 set( Boost_LIBRARIES Boost )

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

[CMake] Diagnostics for unclosed generator expressions?

[Johannes Zarl]

Hi,

Today I learned the hard way that cmake does not provide any diagnostic about 
unclosed generator expressions.

Consider the following:
add_test(
  NAME generator_expression_unclosed 
  COMMAND
  ${CMAKE_COMMAND} -E echo $0:Unclosed expression gives a warning?
)

cmake happily accepts this without any diagnostic, whereas regular variables 
are diagnosed correctly:

message(STATUS ${test)

gives:

  Syntax error in cmake code at
/home/zing/scratch/cmake_testbed/CMakeLists.txt:143
  when parsing string
${unclosed
  syntax error, unexpected $end, expecting } (10)


Should I file a bug report on this issue?

Cheers,
  Johannes

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] 64 bit build of wxWidgets-2.8.12 is not found

[Johannes Zarl]

Hello Robert,

I don't have a test-environment handy, but it seems like FindwxWidgets checks 
for the vc_x64 library directory prefix, not for vc_amd64:

# /usr/share/cmake-3.0/Modules/FindwxWidgets.cmake:511:
if(MINGW)
  set(WX_LIB_DIR_PREFIX gcc)
elseif(CMAKE_CL_64)
  set(WX_LIB_DIR_PREFIX vc_x64)
else()
  set(WX_LIB_DIR_PREFIX vc)
endif()


The wxWidgets changelog[1] seems to suggest that _x64 is the correct name. 
Maybe this is a bug in the wxWidgets installer?

Cheers,
  Johannes


[1] https://github.com/wxWidgets/wxWidgets/blob/WX_3_0_2/docs/changes.txt#L520


On Wednesday 10 December 2014 16:47:38 Robert Pollak wrote:
 Hello,
 
 I am using:
 - Windows 7 Professional 64 Bit
 - Visual Studio 2010 Professional
 - CMake 3.0.1
 
 and I have installed wxMSW-2.8.12-Setup.exe to L:\wxWidgets-2.8.12-vc10\
 and created 32 bit and 64 bit shared library builds there (see footnote
 [1]).
 
 Now I want to use the 64-bit wxWidgets libraries in a CMake-based project.
 
 For that, I have started with a minimal CMakeLists.txt in an empty folder:
  cmake_minimum_required(VERSION 3.0.1)
  
  find_package(wxWidgets REQUIRED core base)
 
 and created a 64 bit configuration cmake-win64-libs-vc10.conf next to it:
  set(wxWidgets_ROOT_DIR L:/wxWidgets-2.8.12-vc10 CACHE PATH wxWidgets
  base directory FORCE) set(wxWidgets_LIB_DIR
  L:/wxWidgets-2.8.12-vc10/lib/vc_amd64_dll CACHE PATH wxWidgets
  libraries directory FORCE) set(wxWidgets_CONFIGURATION msw CACHE PATH
  wxWidgets configuration FORCE)
 When I now call my configure-win64-vc10.bat there:
  setlocal
  rmdir /S /Q build
  mkdir build
  cd build
  set WXWIN=L:\wxWidgets-2.8.12-vc10
  cmake -C ..\cmake-win64-libs-vc10.conf ^
  
-G Visual Studio 10 Win64 ^
..
  
  cd ..
  endlocal
 
 , I get the error
 
  CMake Error at C:/Program Files 
(x86)/CMake/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 
(message):
Could NOT find wxWidgets (missing: wxWidgets_FOUND)
  
  Call Stack (most recent call first):
C:/Program Files
(x86)/CMake/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake
:343 (_FPHSA_FAILURE_MESSAGE) C:/Program Files
(x86)/CMake/share/cmake-3.0/Modules/FindwxWidgets.cmake:869
(FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:4 (find_package)
 
 However, a corresponding 32-bit configuration works!
 The only differences of my 32-bit and 64-bit configurations are
 * the wxWidgets_LIB_DIR: vc_amd64_dll vs. vc_dll (both directories are
 existing and filled with the corresponding dlls) * the CMake generator:
 Visual Studio 10 Win64 vs. Visual Studio 10
 
 This looks to me like a bug of FindwxWidgets.cmake.
 Can anyone confirm? How can I debug this?
 
 
 Best regards,
 Robert
 
 
 
 [1] with
 
  call C:\Program Files (x86)\Microsoft Visual Studio
  10.0\VC\vcvarsall.bat x86 set WXWIN=D:\libraries\wxWidgets-2.8.12-vc10
  cd \wxWidgets-2.8.12-vc10\build\msw
  nmake /f makefile.vc BUILD=debug   SHARED=1
  nmake /f makefile.vc BUILD=release SHARED=1
 
 resp.
 
  call C:\Program Files (x86)\Microsoft Visual Studio
  10.0\VC\vcvarsall.bat x86_amd64 set
  WXWIN=D:\libraries\wxWidgets-2.8.12-vc10
  cd \wxWidgets-2.8.12-vc10\build\msw
  nmake /f makefile.vc TARGET_CPU=AMD64 BUILD=debug   SHARED=1
  nmake /f makefile.vc TARGET_CPU=AMD64 BUILD=release SHARED=1

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] CMake Version Compatibility Matrix

[Johannes Zarl]

Hi,

 Is there any chance that the version compatibility matrix will be
 updated for cmake 3.x features?

Short answer: no.

Longer answer:
I've written and maintained the compatibility matrix before.

The reasons I've stopped maintaining the page:
(1) Distilling the changes between versions is quite some manual effort 
(diffing 
the help text and checking whether something some change reflects a change in 
cmake or just a doc change) .
(2) The documentation format changed in cmake 3, which would have meant a very 
big one-time effort toget the differences between 2.8 and 3.
(3) I still believe that this could be done much better by including 
annotations in the documentation itself (Available since:, Deprecated 
in:).

Hope that explains my reasons,
  Johannes

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] ExternalProject: how to avoid reinstalling after 'make clean'?

[Johannes Zarl]

Hi Cedric,

This is something that ExternalProject cannot really do for you in an 
automatic/safe way. When you do a make clean, you wipe out all knowledge about 
the installed package.

However, you can implement this yourself: Before you do the 
ExternalProject_Add(eigen ...) call, you can call find_package(eigen) and if 
you find the package, you just skip the ExternalProject_Add.

Cheers,
  Johannes



On Tuesday 28 April 2015 12:04:50 Cedric Doucet wrote:
 Hello!
 
 No one knows how to avoid spurious installations with external projects?
 
 Thank you,
 
 Cédric
 
 - Mail original -
 
  De: Cedric Doucet cedric.dou...@inria.fr
  À: cmake@cmake.org
  Envoyé: Vendredi 24 Avril 2015 11:35:54
  Objet: ExternalProject: how to avoid reinstalling after 'make clean'?
  
  Hello,
  
  I use the ExternalProjet_Add function to download and install third-party
  libraries.
  Here is an example of a CMakeLists file containing such a call:
  
  =
  cmake_minimum_required (VERSION 2.6)
  
  project (example CXX)
  
  set(CMAKE_VERBOSE_MAKEFILE ON)
  
  include(ProcessorCount)
  ProcessorCount(N)
  if(NOT N EQUAL 0)
  set(CMAKE_BUILD_FLAGS -j${N})
  endif()
  
  include(ExternalProject)
  set(EXTERNAL_DIR ${CMAKE_CURRENT_BINARY_DIR})
  ExternalProject_Add(eigen
  PREFIX ${EXTERNAL_DIR}/eigen
  DOWNLOAD_DIR ${EXTERNAL_DIR}/eigen/download
  SOURCE_DIR ${EXTERNAL_DIR}/eigen/src
  BINARY_DIR ${EXTERNAL_DIR}/eigen/build
  STAMP_DIR ${EXTERNAL_DIR}/eigen/stamp
  INSTALL_DIR ${EXTERNAL_DIR}/eigen/install
  URL http://bitbucket.org/eigen/eigen/get/3.2.4.tar.gz
  URL_MD5 4d0d77e06fef87b4fcd2c9b72cc8dc55
  CMAKE_ARGS -D CMAKE_INSTALL_PREFIX=INSTALL_DIR
  )
  
  =
  
  Everything works fine, except after calling make clean.
  Thanks to URL_MD5, the third-party library is not downloaded again.
  However, configuration, build and install steps are performed again
  whereas
  the library has not been uninstalled during cleaning.
  
  How could I tell to ExternalProject_Add not to configure/build/install my
  library unless this library has been removed from my computer?
  
  Thank you very much for your help!
  
  Cédric

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] cmp0065

[Johannes Zarl]

Hi,

On Wednesday 06 July 2016 08:43:44 you wrote:
> > #if defined(WIN32)
> > #endif
> 
> not WIN32 that way... as in add_executable( something WIN32 ... )  (or not
> WIN32)

I'm not sure I can follow. I thought you want to have compile time definitions 
like "-DSOMETHING" for GCC or "/DSOMETHING" for MSVC.
If that's what you want, then use the already defined macros for your target 
platform/OS. For Windows, the correct macro is "_WIN32" (sorry I forgot the 
underscore before).

A comprehensive list of these macros can be found here:
https://sourceforge.net/p/predef/wiki/OperatingSystems/

If that's not what you want, it would help if you could elaborate a little, or 
maybe even provide a minimum working example.

 
> > target_compile_definitions( yourTarget PRIVATE COMPILE_SHELL)
> > https://cmake.org/cmake/help/v3.4/command/target_compile_definitions.html
> > 
> > Is that what you are searching for?
> 
> it says "tems will populate theCOMPILE_DEFINITIONS
>  t:COMPILE_DEFINITIONS> property
> of"
> sounds like that will trigger the same CMP0065 warnings.

Did you verify that? I cannot fathom how using target_compile_definitions 
could trigger a CMP0065 warning. But maybe I'm just reading the docs 
completely wrong...
Btw. the documentation states that CMP0065 does not warn by default, but 
silently reverts to the old behavior if it's not set.


Cheers,
  Johannes


P.S.: Checking this using a minimum example does not trigger any warning for 
me on cmake 3.5.2:

--CMakeLists.txt:
cmake_minimum_required(VERSION 3.5)
project(cmake-test)
add_executable(myExe main.cpp)
target_compile_definitions(myExe PRIVATE MY_DEFINITION)
target_compile_definitions(myExe PRIVATE VERSION_STRING="0.8.15")

--main.cpp:
#include 
#ifdef _WIN32
#warning "Target platform is windows 32 or 64 bit!"
#endif
int main(int argc, char** argv)
{
#ifdef MY_DEFINITION
   std::cout << argv[0] << "compiled with MY_DEFINITION!" << std::endl;
#endif
   std::cout << argv[0] << VERSION_STRING << std::endl;
   return 0;
}

For quoted definitions, I usually use configure_file to create a platform 
header.
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Check_include_file is supposed make a definition?

[Johannes Zarl-Zierl]

On Wednesday 10 June 2015 00:48:06 J Decker wrote:
 CHECK_INCLUDE_FILE(stdint.h HAVE_STDINT_H)
 
 is this supposed to create some sort of ADD_DEFINITION( -DHAVE_STDINT_H) ?

No.

 if not what else do I have to do to make that work?

IF(HAVE_STDINT_H)
  ADD_DEFINITION(HAVE_STDINT_H)
ENDIF()

If you want to do this always, you can write a wrapper function, of course...

Cheers,
  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] How does :: actually works?

[Johannes Zarl-Zierl]

Hi,

 I tried several times now to find documentation about how to define
 and use target names which seem to have namespaces, like Qt ones.
 
 For example: add_executable( MyProject::some_target ... )

AFAIK target namespaces are intended for imported targets, not regular 
targets:

A NAMESPACE with double-colons is specified when exporting the targets for 
installation. This convention of double-colons gives CMake a hint that the 
name is an IMPORTED target when it is used by downstreams with the 
target_link_libraries() command. This way, CMake can issue a diagnostic if the 
package providing it has not yet been found.
[1]


[1] 
http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html?highlight=namespace

 I can't find any documentation or even name for this.
 Is it considered a namespace?
 In any way I found nothing specific to this syntax in the wiki.

The concept is called namespace in cmake, just as you assumed. I don't know 
if there's anything about it in the wiki, but the official documentation has a 
(very) short description in the cmake_packages[1] page, as well as in the 
documentation for the export command.

Cheers,
  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] How does :: actually works?

[Johannes Zarl-Zierl]

On Monday 15 June 2015 16:40:10 Klaim - Joël Lamotte wrote:
 So far I didn't get what imported targets helps with, so I'm a bit lost on
 the usefulness of namespaces
 but I am sure that I am missing something.

Imported targets improve the handling of find_package stuff. In the old days, 
the common pattern for using another library as dependency was as follows:

find_package(XXX)
include_directories( ${XXX_INCLUDE_DIR} )
add_definitions( ${XXX_DEFINITIONS} )
target_link_library(YourTarget ${XXX_LIBRARIES} )

Sometimes you don't need the add_definitions part, and sometimes the variable 
names are a little bit different. Most of the time you inadvertedly add 
definitions and include directories for other targets, too.


With imported targets, you can combine everything that's needed to use a 
library into an imported target, making the above pattern simpler and less 
error-prone:

find_package(XXX)
target_link_library(YourTarget XXX)

With more complex libraries, you often have different components, and that's 
when namespaces come in handy:

find_package(XXX COMPONENTS Base Advanced)
target_link_library(YourTarget XXX::Base)
Find_package(YYY COMPONENTS Base)
target_link_library(YourOtherTarget XXX::Advanced YYY::Base)

Does this answer your question?

Cheers,
  Johannes



-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] How does :: actually works?

[Johannes Zarl-Zierl]

On Monday 15 June 2015 22:43:41 you wrote:
 Just a last question: I assume that most find module scripts distributed
 with cmake are
 not using this feature at the moment, right?

Sadly, no.

 After reading your explaination I looked at documentation for FindBoost and
 FindGTest
 which are both used in all my projects and they dont seem to provide import
 targets.
 Are there plans to update the cmake scripts distributed with CMake

On the one hand, FindPackage modules are, as far as I'm aware, slowly being 
updated to use imported targets. On the other hand, quite a few packages are 
missing a maintainer[1]. If you are using a package and want it to provide 
imported targets, I think your best bet is to propose a patch for the module 
and get it into cmake.

That said, its worth mentioning that FindPackage modules are only intended for 
legacy projects which do not provide a PackageConfig.cmake file. If you are 
writing a new project, especially if it's based on cmake, you should write a 
PackageConfig.cmake file instead [2].

 or is it just assumed that projects willing to use importing targets will
 write them somewhere before using them?

Creating imported targets on your own is not the way to go. Better file a bug 
report or write a patch to add the functionality and get that into cmake.
IMO, until the official module provides imported targets, you're better off 
using 
the old way.

Cheers,
  Johannes

[1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#List
[2] http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] using source files in build directory

[Johannes Zarl-Zierl]

Hi,

For header files, that's quite a normal thing to do - you just need to add the 
CMAKE_CURRENT_BINARY_DIR to your include directories.

For .cpp files, you can write your target so that it is referencing the source 
file in the binary directory. I.e.:

configure_file(
  ${CMAKE_CURRENT_SOURCE_DIRECTORY}/file1.cpp.in
  ${CMAKE_CURRENT_BINARY_DIRECTORY}/file1.cpp COPYONLY)
add_executable( target1 ${CMAKE_CURRENT_BINARY_DIRECTORY}/file1.cpp)

Is that sufficient for your needs?

If you rather need a real wildcard way to override arbitrary source files, 
then you're probably out of luck. You could still write a wrapper around 
add_executable and add_library that inspects source directory and binary 
directory, but that might not be worth the effort...

  Johannes

On Thursday 22 October 2015 15:13:08 Srinath Vadlamani wrote:
> Hello All,
>   I am aware of out-of-source builds.  I want to add modified source files
> to the out of source build directory and have CMake use these modified
> files.
> 
> Below is my example:
> $pwd
> 
> $ls
> CmakeLists.txt CMake README src tests doc ...
> $mkdir build1
> $cd build1
> $cp ../src/file1.cpp .
> $ 
> $ccmake  
> $make -j N
> $ 
> 
> Now I want to make another build directory that houses a few other modified
> files:
> 
> $cd 
> $mkdir build2
> $cd build2
> $cp ../src/file1.cpp . && cp ../src/file2.cpp .
> $
> $ccmake  
> $make -j N
> $ but file2 mods helped>
> 
> 
> . and so on.  The point is that the build directory allowing for
> modified source files helps preserve executables and the dependent source
> files for code management.  Some may now chime in with opinions on version
> control usage, but I'm trying to understand if it is possible to do what I
> described and is possible with Autotools.
> 
> Thank you for your time,
> <>Srinath
> 
> =
> Srinath Vadlamani
> =
> 
> On Thu, Oct 22, 2015 at 3:02 PM, Gonzalo  wrote:
> > El 21/10/15 a las 17:45, Srinath Vadlamani escribió:
> > 
> > Hello All,
> > 
> >   Is it possible to have CMake use source files in some particular order
> > 
> > that are placed in the out-of-source build directory?  This is allows for
> > the convenience of having multiple builds in different build directories
> > due to a few file changes while preserving the files themselves?
> > 
> > You are aware that you can do out of source builds, right?
> > 
> > $ mkdir build-linux64
> > $ cd build-linux64
> > $ cmake .. # plus any options you want
> > $ make
> > 
> > --
> > Gonzalo Garramuñoggarr...@gmail.com

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] C++11 flag not being added

[Johannes Zarl-Zierl]

Hi,

CXX_STANDARD is a target property, not a global one. You can either set 
CXX_STANDARD for every target that needs it, or set it globally by changing 
the default value.

You can do the latter by setting the variable CMAKE_CXX_STANDARD  before 
defining any target that depends on it:

set(CMAKE_CXX_STANDARD 11)

HTH,
  Johannes

On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote:
> I have the following two lines in my CMakeLists.txt
> 
> set_property(GLOBAL PROPERTY CXX_STANDARD 11)
> set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED)
> 
> However when compiling some of my source files, the -std=c++11 flag is not
> added.
> 
> Just for good measure I added:
> target_compile_features(my_target PRIVATE cxx_strong_enums) to the target
> that was having the problem.
> 
> Not sure if it matters, but in this case the compile error I’m getting is
> complaining because I’m referencing a fully scoped enum.  If I explicitly
> include -std=c++11 in my compile flags, everything works.
> 
> I’m thinking I’m probably just misunderstanding how CXX_STANDARD works, but
> any help would be appreciated.
> 
> -Matt

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] General cross platform stating place

[Johannes Zarl-Zierl]

Hi,

On Monday 07 September 2015 23:47:35 Aaron Gray wrote:
> cmake_minimum_required(VERSION 2.6)

Just as a side note: if you need to support cmake 2.6, that's fine. However, 
if you are starting a new project and do not *need* to limit yourself to cmake 
2.6, develop for a cmake version that as new as can be supported by your 
target platforms. (Even if you chose the newest cmake it will get kind of old 
within the lifetime of your project *g*)


> set(CMAKE_AR /usr/bin/ar CACHE FILEPATH "Archiver")

Why do you set CMAKE_AR?

> It runs fine on Windows with MSVC, seems to be failing on MSYS :-

MSVC doesn't use CMAKE_AR, so there should be no problems here. MSYS obviously 
tries to use CMAKE_AR, which you set to the unlikely (on windows) path of 
/usr/bin/ar.

  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Johannes Zarl-Zierl]

> > I.e. it could be replaced with a string of the same length or a
> > shorter one, but not a longer one.
> > 
> > CMake works around this by extending the build RPATH artificially with
> > ":" at the end I think, patchelf works around this by making the whole
> > executable one page bigger if the new entry is longer.
> 
> Just an implementation notes, doesn't change the fact that it can be
> done and it's designed to be modifiable.

This is only nitpicking about a side-topic, but: Just because it can be done 
does not mean that it was designed for that purpose.
You argument is like saying that a wrench was designed to be used as a hammer 
(after all, you can hit a nail with it).

If one were to follow that argument, it would be very hard *not* to design 
something for a given purpose.

> > If RPATH was _designed_ to be patchable, tools could just do it,
> > instead of having to implement workarounds for longer strings. E.g.
> > the linker would support a command line argument how much space it
> > should reserve for the RPATH entry, or something like that.
> 
> I think it's not possible. As far as I know there is no limitation for
> path size on Linux for example. Hence it's not possible to predict what
> size for path to library user want to use by setting RPATH.

If RPATH were *designed* to be modifiable, it would need provisions to account 
for arbitrary path lengths.
One possible solution (not necessarily the best, or even a good one) would be 
to make RPATH a fixed-length field, part of which is a pointer to the next 
entry, if any.

Regards,
  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Version compatibility?

[Johannes Zarl-Zierl]

Hi Rob,

I've stopped working on it when 3.0 came out. Since the whole thing was very 
much manual work (diff'ing documentation pages and checking whether some 
change was only better documentation or a real change in cmake), it was too 
much effort to continue long-term.

  Johannes

On Saturday 23 April 2016 10:32:15 Rob McDonald wrote:
> Is there a continuation of the CMake version -- feature mapping table?
> 
> https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix
> 
> I found this to be quite useful, but need something that continues into 3.X.
> 
> Rob

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] cmp0065

[Johannes Zarl-Zierl]

Hi,

On Tuesday 05 July 2016 23:46:16 J Decker wrote:
> https://cmake.org/cmake/help/v3.4/policy/CMP0065.html
> while I like the idea it suggests, I don't use the flags for -rdynamic so
> this is meaningless to me

I'm not sure I understood you correctly, but if the policy is meaningless to 
you, it shouldn't affect you...

> https://cmake.org/cmake/help/v3.4/prop_tgt/ENABLE_EXPORTS.html#prop_tgt:ENAB
> LE_EXPORTS
>   SET_PROPERTY(TARGET ${project} APPEND PROPERTY COMPILE_DEFINITIONS
> TARGET_LABEL=${TARGET_LABEL};TARETNAME=\"${TARGETNAME}\" )
> 
> or
> 
> SET_PROPERTY( TARGET ${project} APPEND PROPERTY COMPILE_DEFINITIONS
> "CONSOLE_SHELL" )
> 
> to indicate it's non-WIN32

First of all, there are the usual standard definitions provided by the 
compiler, so you can just use 

#if defined(WIN32)
#endif

to check whether the compilation happens for windows or another platform.

If you have the need for additional definitions, it seems to me that the usual 
command:

target_compile_definitions( yourTarget PRIVATE COMPILE_SHELL)
https://cmake.org/cmake/help/v3.4/command/target_compile_definitions.html

Is that what you are searching for?

> I noted at the bottom of that the the default behavior will eventually be
> phased out... but then can we have some other flag to phase it back in?

You can always set policies to “OLD” to revert to the old behavior (until it 
is finally phased out). In the case of cmp0065 the documentation explains what 
you can do to have the same behavior with the policiy enabled:
Just set the ENABLE_EXPORTS property on the targets that need to export their 
symbols.

HTH,
  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] libsndfile in windows

[Johannes Zarl-Zierl]

On Dienstag, 21. März 2017 15:24:13 CET you wrote:
> > Did you try asking on the libsndfile mailing list?
> I did .but there was no response .

Ok then.

> I had written cmakelists.txt to compile and build .
> I was able to successfully built it in linux , but in windows I was not
> able to do it .
> Do you have nay leads on that ?

Reading the description that you linked to, I see that they have only done a 
partial port to cmake and still require autotools. If you want to compile on 
other platforms you'll need to get rid of those non-portable parts.

I would probably look at any pull requests and issues for that repository and 
look for cmake-related reports. Maybe someone else is already fixing the 
issues?

Otherwise, you can try porting the non-portable parts yourself and ask on this 
list if you have problems in your cmake code.

Cheers,
  Johannes

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] libsndfile in windows

[Johannes Zarl-Zierl]

Hi,

On Dienstag, 21. März 2017 10:57:42 CET aishwarya selvaraj wrote:
> I'm very new to all this , So Could anyone please guide me on what to do
> next .

Did you try asking on the libsndfile mailing list? They are more likely to know 
about the issue you're dealing with.

Try here:
http://www.mega-nerd.com/libsndfile/lists.html

Cheers,
  Johannes

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Should configuration package files define module package variables?

[Johannes Zarl-Zierl]

Hi,


On Freitag, 25. August 2017 11:21:50 CEST Robert Dailey wrote:
> However, what I'm wondering is even though the import targets should
> contain all information about include directories, libraries, etc,
> should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES
> variables?

This depends very much on the target audience of your config.cmake file. My 
personal opinion is that you can skip those variables entirely for new 
projects. (Somebody please correct me if I'm wrong!)

> It seems like Module packages are being deprecated
> in favor of Config packages, because it puts the responsibility of
> maintaining find package logic on the upstream maintainer (config
> package) instead of on CMake (module packages it ships with).

Yes. This has been the case since cmake 2.8 or so. A general rule of thumb for 
module vs. config:
If you are the upstream: create a config  package.
If the upstream is somebody else, but uses cmake: submit a patch and get them 
to provide a config package.
If the upstream does not use cmake: they can still provide a config package.
If all else fails: add a module to your project to find the upstream library.

Cheers,
  Johannes

P.S.: And yes: creating a config package has a steep learning curve. Link [2] 
has all the information you need, but it is hardly a nice tutorial...
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Using find_package() portably?

[Johannes Zarl-Zierl]

On Mittwoch, 22. November 2017 11:32:22 CET Carsten Fuchs wrote:
> That is, follow-up question: near the "..." above, we have got a target
> "libjpeg", but how do I get the variables JPEG_INCLUDES, JPEG_LIBRARIES
> etc. that `find_package(JPEG)` normally provides so that the last line
> with the `target_link_libraries()` works?
> I guess that defining them in `../ExtLibs/libjpeg/CMakeLists.txt` is wrong.

You've found an ugly corner in CMake ;-)

The problem in this specific case is that CMake ships with a FindJPEG module 
that does not define modern import libs, but uses the old way of defining 
_LIBRARIES and _INCLUDE_DIRS.
IMO this highlights one of the main problems with find modules: nobody really 
maintains them.

If JPEG had proper imported targets, your code could look like this:

find_package(JPEG)   # without "REQUIRED"

if (NOT JPEG_FOUND)
   ...
   # Proceed with the shipped copy of libjpeg:
   add_subdirectory(../ExtLibs/libjpeg ../ExtLibs/libjpeg)
endif()

target_link_libraries(main_program JPEG::JPEG)

You just have to make sure that your shipped libjpeg creates the proper 
namespaced target:
add_library(JPEG ...)
add_library(JPEG::JPEG ALIAS JPEG)

HTH,
  Johannes

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Using find_package() portably?

[Johannes Zarl-Zierl]

Hello Carsten,

On Samstag, 25. November 2017 11:46:44 CET Carsten Fuchs wrote:
> Thanks for your reply, but how can I proceed from here?
> 
> In order to be able to write in the parent script something that works
> in either case, that is,
> 
> target_link_libraries(main_program )

Well, that's one way, but that doesn't really provide any benefit above the 
original solution (i.e. just define the JPEG_INCLUDES and JPEG_LIBRARIES 
variables accordingly).

> it seems that I either
> 
>- have to make a copy of FindJPEG.cmake, customize it to define
> target JPEG::JEPG and ship it along with my project,

Either that or you define it yourself:
find_package(JPEG)
if (JPEG_FOUND)
 add_library(JPEG::JPEG UNKNOWN IMPORTED)
 set_property(
  TARGET JPEG::JPEG
  PROPERTY IMPORTED_LOCATION ${JPEG_LIBRARIES}
  )
 set_property(
  TARGET JPEG::JPEG PROPERTY
  INTERFACE_INCLUDE_DIRECTORIES ${JPEG_INCLUDES}
 )
endif()

I admit it's not a huge benefit over just using the variables. The advantages:
- you get slightly better error handling
- your target_link_libraries commands are slightly more readable.

>- or write my `../ExtLibs/libjpeg/CMakeLists.txt` so that it globally
> defines JPEG_LIBRARIES and JPEG_INCLUDE_DIRS

That will work, too.


Cheers,
  Johannes

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream

[Johannes Zarl-Zierl]

Hi Mateusz,

On Montag, 21. Mai 2018 19:39:16 CEST Mateusz Loskot wrote:
> The FindLZ4 discussion basically ended with suggestion from Brad that,
> instead of adding Find-module to CMake, I should approach LZ4 project
> and add Config-file to the library itself.
> Then I argued taht Config-files are more complex and I don't feel like
> asking projects, which I don't maintain myself, to accept the extra
> complexity

There's more that we (as CMake community) could do to make it easier for non-
cmake projects to add a config file, and I think this is a worthwhile goal.

Currently, if the maintainer of an autotools-based project is willing to add a 
cmake config file, he or she basically needs to be an expert on cmake. There's 
no official template or guide on how to create a cmake config file without 
relying 
on a cmake module to do the work.

If there was a good guide, or maybe even some tooling, cmake config files would 
not be much more work for the maintainer as pkg-config files.

> I call CMake to accept *any* Find-module, filtering only based on
> quality of CMake
> idiomatic scripting.

"Filtering based on quality" being the important part.

> If CMake does not want Find-* modules within the source tree, then
> - set up https://gitlab.kitware.com/cmake/find-modules
> - move all existing Find-modules in there
> - relax maintenance rules to accept *any* Find-module, provided
> --- CMake scripting is decent quality (e.g no community downvotes or
> rejecting reviews for period of quarantine)
> --- CI passing tests
> - finally, include the complete find-modules archive in the installer
> so it is deployed
>aside of CMake itself

That seems like a reasonable way to deal with the situation. Maybe this would 
also encourage better quality of the (current) core find-modules. If you take a 
look at those, they are in wildly different shape regarding their quality.

> If CMake does not care about Find-modules, it should not care or
> should care about
> them equally

ACK.

Cheers,
  Johannes

-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Contribute Find-module to CMake vs Config-file to upstream

[Johannes Zarl-Zierl]

On Dienstag, 22. Mai 2018 11:13:18 CEST Brad King wrote:
> > not be much more work for the maintainer as pkg-config files.
> 
> There is a proposal here:
> 
>   https://mwoehlke.github.io/cps/

This looks quite promising!
Do you know whether there's a shared interest on the pkg-config and autotools 
side?

Even without pkg-config joining the effort, it should be much easier to 
convince projects to create a .cps file than some "arcane" cmake-config scripts.

Cheers,
  Johannes
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] conditions and included subprojects

[Johannes Zarl-Zierl]

he main project level
> > 
> > 
> > - but if the sub project is being built standalone, the option is not
> > defined and should be set e.g. in cmake-gui
> > 
> > 
> >  
> > 
> > 
> > If I write now in the sub project
> > 
> > 
> >  
> > 
> > 
> > IF(THAT_OPTION)
> > 
> > 
> > ...
> > 
> > 
> >  
> > 
> > 
> > this will be true if THAT_OPTION was set to ON in the main project.
> > So far so good. But the expression is now so "clever" that it cannot
> > distinguish between THAT_OPTION being set to OFF in the main project,
> > or THAT_OPTION not being defined at all - like in a standalone build!
> > 
> > 
> >  
> > 
> > 
> > One way would be to have an additional option or variable
> > BUILDING_MAINPROJECT which is set to ON or TRUE in the main project
> > and can be checked. However, I have so far not seen any
> > CMakeLists.txt with such a code, so ... what are the experts doing in
> > such a case?
> > 
> > 
> >  
> > 
> > 
> > Thanks and regards,
> > 
> > 
> > Cornelis
> > 
> > 
> >  
> > 
> > -- Powered by www.kitware.com Please keep messages on-topic and check
> > the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers
> > various services to support the CMake community. For more information
> > on each offering, please visit: CMake Support:
> > http://cmake.org/cmake/help/support.html CMake Consulting:
> > http://cmake.org/cmake/help/consulting.html CMake Training Courses:
> > http://cmake.org/cmake/help/training.html Visit other Kitware open-
> > source projects at http://www.kitware.com/opensource/opensource.html
> > Follow this link to subscribe/unsubscribe:
> > https://cmake.org/mailman/listinfo/cmake



-- 
Johannes Zarl-Zierl
Information management

JOHANNES KEPLER UNIVERSITY LINZ
Altenberger Straße 69
4040 Linz, Austria
P +43 732 2468 3898
johannes.zarl-zi...@jku.at
www.jku.at
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Changes to cmake_minimum_required() for 3.12

[Johannes Zarl-Zierl]

Hi,

Just giving my 2 cents:
If the preferred solution is the "POLICY_NEW_UNTIL" wording, then why not make 
this accepted as well? This way, you can deprecate the backwards-compatible 
version in a few years and remove it some time thereafter. In the end, you'll 
get a cleaner solution...

Cheers,
  Johannes


On Montag, 2. Juli 2018 08:43:57 CEST Craig Scott wrote:
> On Mon, Jul 2, 2018 at 4:04 AM, Alan W. Irwin 
> 
> wrote:
> > On 2018-07-01 08:12+1000 Craig Scott wrote:
> > 
> > Older CMake versions
> > 
> >> will see the extra dots as being version component separators and will
> >> end
> >> up effectively ignoring the max part.
> > 
> > This explanation of how "..." will be interpreted by older CMake
> > versions makes sense, but it wasn't obvious to me without that
> > explanation.  And I suspect other build-system developers/maintainers
> > would also benefit from the explanation.  Therefore, please explicitly
> > include the above explanation in the latest documentation of both the
> > cmake_minimum_required and cmake_policy commands.
> 
> I've updated the merge request to incorporate this feedback.
> 
> https://gitlab.kitware.com/cmake/cmake/merge_requests/2180



-- 
Johannes Zarl-Zierl
Information management

JOHANNES KEPLER UNIVERSITY LINZ
Altenberger Straße 69
4040 Linz, Austria
P +43 732 2468 3898
johannes.zarl-zi...@jku.at
www.jku.at
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] simple find_package example

[Johannes Zarl-Zierl]

Am Dienstag, 7. August 2018, 14:48:26 CEST schrieb Randy Heiland:
> Hmm, well if that's the case, how does one generate the HelloConfig.cmake
> file?

The official documentation is here:
https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html

> Although, for my particular situation, my question about wanting to
> generate a "Find" file still remains, I think. I have a library which is,
> potentially, useful to several projects. I assume there's some sort of
> "Find" template for any such lib, i.e., a project needs to be able to
> locate a lib (static or dynamic) and headers, cross-platform.

Im almost positively sure that you don't want a FindXYZ.cmake, but a 
XYZConfig.cmake file instead. These are the main differences between Find-
module packages and config-file packages:

Find-Module packages:
- are written and maintained independently of the "consumed" project
  (usually because the project does not support CMake)
- are usually shipped by the consuming project
- are hard to get right (they have to deal with strange installations, or old 
versions of the software, etc.)

Config-file packages:
- are generated by the "consumed" project
- are shipped by the consumed project
- have tooling to ensure correctness


For the consuming project, there's no visible difference between both (you 
call "find_package(XYZ)" and cmake uses whatever it finds. In principle, it's 
even possible to use both together (note: please don't).

That said, the official documentation can be a bit overwhelming at first.
You probably can write some kind of cmake-2.6-style Find-Module package in 
less time, but the time to do it "right" is worth your effort.

Just start by reading the documentation and don't hesitate to ask when you hit 
a problem…

Cheers,
  Johannes



-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Querying project dependencies from the UNIX command-line

[Johannes Zarl-Zierl]

Hi Ardi,

Am Mittwoch, 18. Juli 2018, 11:31:50 CEST schrieb ardi:
> For example, I'd like to type "somecommand /path/to/someproject" at
> the UNIX command line, and get this output:
> [...]
> Furthermore, if another command could show optional requisites, it
> would be really great: "anothercommand /path/to/someproject"
> 
> Project /path/to/someproject can optionally use the following when being
> built: 
> [...]
> So, can I get this functionality from plain CMake/CPack ? Or would I
> need additional tools (Note: I know about Hunter, but first I'd like
> to know if plain CMake does already offer this feature).

I don't think there's something that gives you exactly what you described, 
especially not for a random CMake project.

If you can add some commands to the CMakeLists.txt, though, then the 
FeatureSummary module may suit your needs.

Basically, you include the module an then add a cmake command like this:
feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES)

When you run cmake, you'll get a summary of which packages have been found/not 
found, and the required version if you supplied one for the corresponding 
find_package command.

Cheers,
  Johannes



-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Recommandations for public custom macro/functions installation

[Johannes Zarl-Zierl]

Hi David,

On Dienstag, 17. April 2018 11:58:12 CEST David Demelier wrote:
> I personally do not want to prefix all my options in my project with
> the project name prefix, I think that would be a bit ugly, and I do
> want this macro to build and install the documentation.

Just replying to this topic of your message: you may want to reconsider. The 
cmake gui allows you to group options automatically by prefix. This de-clutters 
the options considerably.

On a related note: even without grouping, looking through the options of a 
project in ccmake or cmake-gui is so much easier when they are prefixed (and 
therefore easily identifiable).

Cheers,
  Johannes


-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] Recommandations for public custom macro/functions installation

[Johannes Zarl-Zierl]

On Dienstag, 17. April 2018 13:48:39 CEST David Demelier wrote:
> On Tue, 2018-04-17 at 12:25 +0200, Johannes Zarl-Zierl wrote:
> > Just replying to this topic of your message: you may want to
> > reconsider. The
> > cmake gui allows you to group options automatically by prefix. This
> > de-clutters
> > the options considerably.
> 
> I didn't know that! Nice catch. I'll reconsider using prefix then. I've
> usually named my options WITH_FOO, do you recommend to use
> PROJECT_WITH_FOO or WITH_PROJECT_FOO then?

Personally, I prefer PROJECT_WITH_FOO because it also works when I have 
additional options PROJECT_ADDITIONAL_OPTION...


Cheers,
  Johannes


-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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

Re: [CMake] find_package Config vs Module mode

[Johannes Zarl-Zierl]

Hi Joachim,

Am Samstag, 20. Oktober 2018, 13:22:04 CEST schrieb Joachim Wuttke:
> If Config mode is the newer, preferred way to find a package, I would expect
> find_package to first try Config mode, and only fall back to Module mode if
> no config scripts can be found. However, according to the find_package doc
> page, it is just the other way round.
> 
> Why?

The reason as far as I understand it is that you, as the consumer of a 
library, might want to customize the find_package process. Since find_package 
modules are usually shipped by your own code[1], it's not a problem that the 
module eclipses the config package.

> How to enforce that new config scripts are used if there are still FindXXX
> modules around?

First of all, purge the FindXXX modules from your own code base if you don't 
use them.
Otherwise, append the "CONFIG" keyword to the find_package call as described 
in the docs[2].

If you want to keep the FindXXX module around for compatibility with older 
versions of a library, then an even better solution is to fix your FindXXX 
module to call find_package(...CONFIG) and skip the search if a config file is 
found.

Cheers,
  Johannes



[1] apart from the modules shipped with cmake
[2] 
https://cmake.org/cmake/help/latest/command/find_package.html#full-signature-and-config-mode


-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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