[cmake-developers] [CMake 0016024]: Add support to use OpenBLAS to FindBLAS/FindLAPACK
The following issue has been SUBMITTED. == https://cmake.org/Bug/view.php?id=16024 == Reported By:J M Dieterich Assigned To: == Project:CMake Issue ID: 16024 Category: Modules Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2016-03-17 17:10 EDT Last Modified: 2016-03-17 17:10 EDT == Summary:Add support to use OpenBLAS to FindBLAS/FindLAPACK Description: OpenBLAS (www.openblas.net) is the successor to GotoBLAS. FindBLAS/FindLAPACK support finding Goto (among other BLAS implmentations) but not OpenBLAS. OpenBLAS is a relatively widely used BLAS as it is fast and free. Find attaches a patch adding support to find OpenBLAS (BLA_VENDOR=OpenBLAS) for both FindBLAS, FindLAPACK. == Issue History Date ModifiedUsername FieldChange == 2016-03-17 17:10 J M Dieterich New Issue 2016-03-17 17:10 J M Dieterich File Added: add_openblas.diff == -- 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] Patch to only consider build dependencies between files in the source directory
Hi Brad, >> + // If it's an absolute path, check if it starts with the source >> + // direcotory: >> + return ( ( path.find( SourceDir ) != 0 ) && >> + ( path.find( BinaryDir ) != 0 ) ); > > Please look at using strncmp and a check that the following character > is a nul terminator or '/'. Otherwise an external location with > a common prefix may be mistaken for part of the project. Not sure what scenario you have in mind here. :-/ std::string::find should only return 0 if the source directory path or binary directory path is what the evaluated path begins with. Why should we worry what the path continues with? I was wondering about possibly using strncmp, but thought that performance-wise std::string::find should be fine as well here. I'm not at all against changing the code, I just don't understand yet what setup the current code would not handle correctly. > Also please add documentation in a > > Help/variable/CMAKE_DEPENDS_IN_PROJECT_ONLY.rst > > file and update Help/manual/cmake-variables.7.rst to reference it. Will do. Was just not sure where to add this documentation. Cheers, Attila -- 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] [CMake 0016022]: GenerateExportHeader DEFINE_NO_DEPRECATED define conflicts
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 ModifiedUsername 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
Re: [cmake-developers] Startup Project Configuration [mantis 15578]
On 03/18/2016 12:38 PM, Taylor Braun-Jones wrote:
> Here's Davy's patch rebased against current master with a unit test
> added. Tested on Visual Studio 2013 only. Let me know if I screwed up
> the rebase. Some conflicts weren't totally obvious to me how to
> handle.
Thanks!
I decided to rename the existing test first:
Tests: Rename RunCMake.{SolutionGlobalSections => VSSolution}
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5c1f4da8
Then I applied the change with some minor fixups:
VS: Add option to choose the `.sln` startup project (#15578)
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cdfd837a
The main difference is that we now check that the named target
exists. If not we warn and ignore the property. I added a test
for that too.
Please check that the revised version works for you.
Thanks,
-Brad
--
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
