Re: [cmake-developers] Review request: FindTBB module

2016-03-31 Thread Andreas Schuh 
Hi all,

I also came across these FindTBB modules while in need for one. As the more 
recent one from the OGRE project did not support MSVS 2015 yet, and also does 
not create import targets for a more convenient and “modern” CMake use of the 
TBB library targets, I wrote my own module.

Features:
- Makes use of COMPONENTS argument of find_package to look for the different 
TBB libraries.
- Adds IMPORTED library targets with IMPORTED_* and INTERFACE_* properties set 
appropriately.
- Considers TBB_ROOT as user hint and bases library search on root derived from 
TBB_INCLUDE_DIR otherwise.
- Uses PATH_SUFFIXES instead of full search paths as done by OGRE FindTBB 
module to take advantage of CMake’s default search paths.
- Checks TBB_VERSION against VERSION argument of find_package using 
find_package_handle_standard_args.

This module is part of my CMake BASIS project which, among other things, 
consists of custom CMake functions and modules which attempt to standardise and 
reduce the CMake code needed by most projects (in research). These CMake BASIS 
Modules can be found on GitHub: 
https://github.com/schuhschuh/cmake-basis-modules.

Would be great if someone could review the FindTBB module at


https://github.com/schuhschuh/cmake-basis-modules/blob/develop/FindTBB.cmake

and provide some feedback about what needs to be modified before it can be 
added to the official CMake Modules.

Best,
Andreas

> On 12 Mar 2015, at 00:04, Klaim - Joël Lamotte  wrote:
> 
> 
> ​Hi,
> 
> did you manage to improve over the DaxToolkit FindTBB module?
> 
> Thanks for your time.
> -- 
> 
> 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-developers

-- 

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

[cmake-developers] Fwd: [CMake 0016022]: GenerateExportHeader DEFINE_NO_DEPRECATED define conflicts

2016-03-19 Thread Andreas Schuh 
Hi,

regarding this issue report, I’ve just attached a patch 
<https://cmake.org/Bug/file_download.php?file_id=5646=bug> for the current 
HEAD of the master branch that fixes the issue. Please have a look and it would 
be great if somebody could apply it. It currently causes problems in particular 
for projects using VTK, which may need this patch to be applied as well, given 
that it ships its own copy of the GenerateExportHeader module.

Cheers,
Andreas

> Begin forwarded message:
> 
> From: Mantis Bug Tracker <man...@public.kitware.com>
> Subject: [cmake-developers] [CMake 0016022]: GenerateExportHeader 
> DEFINE_NO_DEPRECATED define conflicts
> Date: 16 March 2016 at 21:28:00 GMT
> To: cmake-developers@cmake.org
> 
> 
> The following issue has been SUBMITTED. 
> == 
> https://cmake.org/Bug/view.php?id=16022 
> ========== 
> Reported By:Andreas Schuh
> Assigned To:
> == 
> Project:CMake
> Issue ID:   16022
> Category:   Modules
> Reproducibility:always
> Severity:   minor
> Priority:   normal
> Status: new
> == 
> Date Submitted: 2016-03-16 17:27 EDT
> Last Modified:  2016-03-16 17:28 EDT
> == 
> Summary:GenerateExportHeader DEFINE_NO_DEPRECATED define
> conflicts
> Description: 
> The header file generated by generate_export_header adds a
> 
>#define DEFINE_NO_DEPRECATED 0|1
> 
> macro which is used to decide whether or not to define the respective macro 
> with
> the desired library prefix and base name. But this macro has the same name for
> all libraries and is not undefined when it is no longer needed. In my project,
> this for example created a conflict with the VTK library which uses such
> generated header file which must of course be included in the public header
> files.
> 
> To solve this conflict, I am using now (temporarily) a custom
> exportheader.cmake.in template file by changing the
> _GENERATE_EXPORT_HEADER_MODULE_DIR path to a directory in my project after
> including the GenerateExportHeader module. Find the modified template file
> attached.
> 
> There is certainly a better fix for this bug.
> == 
> 
> Issue History 
> Date Modified    Username   FieldChange   
> == 
> 2016-03-16 17:27 Andreas Schuh  New Issue
> 2016-03-16 17:28 Andreas Schuh  File Added: exportheader.cmake.in 
>   
> 
> ==
> 
> -- 
> 
> 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-developers

-- 

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

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

2015-09-18 Thread Andreas Schuh 
Hi,

Being able to alias imported targets would be a great feature. Just an
addition to the exports discussion, I also don't think it is necessary.
Besides the EXPORT_NAME property I was not aware of either, I would instead
expect to see an

  add_library (old_name ALIAS new_name)

in the ProjectConfig.cmake(.in) file after importing the new_name library
target. This would make it more clear that it is just an alias for the
actual new exported/imported target. Also no need to maintain copies of
identical imported target properties. I would find this more appealing than
exporting the same target twice but with different name. I would think this
was just done before because of the missing ability to alias an imported
target.

Andreas
On 15 Sep 2015 21:36, "Tamás Kenéz"  wrote:

> Thank you, I was not aware of the EXPORT_NAME target property.
> Tamas
>
> On Tue, Sep 15, 2015 at 7:36 PM, Stephen Kelly  wrote:
>
>> Tamás Kenéz wrote:
>>
>> >> For example, if an ALIAS can be IMPORTED, does it makes sense that it
>> can
>> > be
>> >> exported with export() and install(EXPORT)?
>> >
>> > Yes: couple of months ago I was adding install(EXPORT) to an existing
>> > CMakeList. The name of the library target which I had to export was not
>> > correct as export target name but I was not able change the library
>> target
>> > name because of backward compatibility. Being able to export an alias
>> > would have helped.
>>
>> I still think exporting should be a follow up to allowing IMPORTED ALIAS.
>> Just too keep the branch and discussion as short as possible.
>>
>> Nevertheless, I think you wouldn't need ALIAS targets for your use-case.
>> They are more than you need. You don't need the aliases anywhere except
>> for
>> exporting. So, we could design something which allows you to export
>> aliases,
>> but be completely separate from ALIAS targets.
>>
>> For example,
>>
>>  add_library(foo ${foo_SRCS})
>>  set_target_property(foo EXPORT_NAMES foo foo_old_name)
>>
>>  ...
>>
>>  install(EXPORT ...)
>>
>> resulting in a generated file containing
>>
>>  add_library(foo IMPORTED)
>>  ...
>>
>>  add_library(foo_old_name IMPORTED)
>>  ...
>>
>> where each of the generated targets get the same target properties.
>>
>> Note that there is already an EXPORT_NAME target property
>>
>>  http://www.cmake.org/cmake/help/v3.3/prop_tgt/EXPORT_NAME.html
>>
>> but it is not a list, so the task would probably be to deprecate that one
>> and add EXPORT_NAMES.
>>
>> I filed
>>
>>  http://public.kitware.com/Bug/view.php?id=15745
>>
>> Thanks,
>>
>> Steve.
>>
>>
>>
>> --
>>
>> 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-developers
>>
>
>
> --
>
> 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-developers
>
-- 

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

[cmake-developers] Improved FindPythonInterp.cmake module

2012-04-12 Thread Andreas Schuh 
Hi CMake folks,

I run into a problem with CMake 2.8.4 which relates to the bug
http://public.kitware.com/Bug/view.php?id=12338 . In particular, the
issue that not the default python executable was found, but the most
recent version that is installed. Thus, before noticing that this
seems to be fixed in CMake 2.8.6, I implemented my own
FindPythonInterp.cmake module for a project I am working on.

As the new implementation also considers the PythonInterp_FIND_VERSION
and PythonInterp_FIND_VERSION_EXACT variables, I thought it might
still be of interest for future CMake releases, either just as
reference or to replace the current FindPythonInterp.cmake module in
which case the copyright and license notices may be altered so it
works for distribution as part of CMake.

Andreas


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

Re: [cmake-developers] Improved FindPythonInterp.cmake module

2012-04-12 Thread Andreas Schuh 
Indeed, I should have looked at the most recent version instead of
this old patch found in the bug tracker. That module looks great.

On Thu, Apr 12, 2012 at 12:34 PM, Rolf Eike Beer e...@sf-mail.de wrote:
 Am Donnerstag, 12. April 2012, 11:57:10 schrieb Andreas Schuh:
 Hi CMake folks,

 I run into a problem with CMake 2.8.4 which relates to the bug
 http://public.kitware.com/Bug/view.php?id=12338 . In particular, the
 issue that not the default python executable was found, but the most
 recent version that is installed. Thus, before noticing that this
 seems to be fixed in CMake 2.8.6, I implemented my own
 FindPythonInterp.cmake module for a project I am working on.

 As the new implementation also considers the PythonInterp_FIND_VERSION
 and PythonInterp_FIND_VERSION_EXACT variables, I thought it might
 still be of interest for future CMake releases, either just as
 reference or to replace the current FindPythonInterp.cmake module in
 which case the copyright and license notices may be altered so it
 works for distribution as part of CMake.

 Please have a look on the version that is currently in the git repository and
 which will be part of the upcoming 2.8.8 release (and is part of both release
 candidates). It should have a pretty decent version selection that also allows
 one to select either python 2 or python 3 as well as exact versions.

 Greetings,

 Eike
--

Powered by www.kitware.com

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

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

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