Re: [cmake-developers] automatically download library

2015-10-09 Thread Ruslan Baratov via cmake-developers 

On 08-Oct-15 18:06, Marsel Galimullin wrote:
The idea is that CMake has possibility to contact with package 
managers for download necessary libraries.

If “find_package” can’t find a library, it need to call apt-get install.
Example:
auto_downland(apt-get)
find_package (Boost COMPONENTS system thread REQUIRED) 
re:{possibility to contact with package managers} *if* you have a 
suitable package manager. And even if you have one result may differs 
for different platforms, e.g.:


* OSX, brew install boost => 1.58
* Ubuntu, apt-get install boost-dev => 1.54

Note that 'find_package(Boost)' can find any user-installed libraries or 
non-host packages for cross-compile, like building Android on Linux, or 
iOS on OSX (both issues can be solved by using ExternalProject + 
superbuild). If you and your users are okay with that then it's should 
be not so hard to implement this CMake module.


On 06-Oct-15 15:22, Marsel Galimullin wrote:


Hello!
I'm student of the University LETI and as a masrer'sthesis I want to 
developan extension to CMake. It is expected that this extension will 
automatically download missinglibrary ifinstruction such as 
«find_package (Boost COMPONENTS system thread REQUIRED)» can not find 
the package. Could you give me some advices where to begin and which 
the best direction to design, developand whether to do it?


So with all this peculiarities I've described above this will be not 
such an easy task as you might expect. You can start one from scratch 
for education or fun (or both) but if you want to do some really helpful 
stuff my advice to you is to feed "cmake package manager" request to 
your web search engine and investigate existing solutions.


On 08-Oct-15 18:41, Ryan Schmidt wrote:

On Oct 8, 2015, at 10:06 AM, Marsel Galimullin wrote:


The idea is that CMake has possibility to contact with package managers for 
download necessary libraries.
If “find_package” can’t find a library, it need to call apt-get install.
Example:
auto_downland(apt-get)
find_package (Boost COMPONENTS system thread REQUIRED)

I understand the idea, and I'm telling you that if you need this for your own 
personal project -- one that will never be included in a package management 
system -- then do whatever you like. But if you are proposing this as something 
that should be included in cmake, and you are suggesting that it could be used 
by any project that wants to -- even in projects that might someday be included 
in a package management system -- then I can tell you that this would not be 
welcomed by the people who maintain those package management systems. I am such 
a person. If I were tasked with the request to add to my package management 
system a project that wanted to control the installation of its own 
dependencies, or that in some other way tried to be in charge of downloading 
its dependencies, I would either have to rip all that code out, or more likely 
I would reject the request to add that project as being too labor-intensive. It 
is the package management system's job to download and install dependencies, 
not the job of the project's build system.

re:{I would either have to rip all that code out, or more likely I would 
reject the request to add that project as being too labor-intensive} 
this can be solved easily by adding option which is set to OFF by default:


option(USE_SUPERTOOL "Download host packages automatically" OFF)
function(auto_download ...)
  if(NOT USE_SUPERTOOL)
# do nothing
return()
  endif()
  # do install
endfunction()
auto_download(...) # by default do nothing
find_package(Boost COMPONENT system thread REQUIED) # find the packages 
you are expecting


On 08-Oct-15 18:23, Brad King wrote:

On 10/08/2015 11:06 AM, Marsel Galimullin wrote:

The idea is that CMake has possibility to contact with package managers
for download necessary libraries.
If “find_package” can’t find a library, it need to call apt-get install.
Example:
  auto_downland(apt-get)
  find_package (Boost COMPONENTS system thread REQUIRED)

This does not provide enough information to know what package to install.
This problem is not in scope for a build system.  Another tool should
be used to install dependencies ahead of time before running CMake.
The source tree could come with some kind of dependency spec file for
such a tool to use but this would be independent of the build system.

-Brad

re:{The source tree could come with some kind of dependency spec file 
for such a tool to use but this would be independent of the build 
system} As the one who is using such approach in my product I disagree 
with that completely :) CMake code and dependencies are in fact coupled 
strongly. For example:


   option(USE_GUI "Use some GUI for this project" OFF)
   if(USE_GUI)
  if(WIN32)
option(USE_QT "Use Qt GUI" ON)
  else()
option(USE_WXWIDGETS "Use WxWidgets GUI" ON)
  endif()

  # check at least one and not both

  if(USE_QT)

Re: [cmake-developers] [CMake 0015769]: OS X: Filesystem timestamp checks use only 1s resolution

2015-10-09 Thread Ruslan Baratov via cmake-developers 

On 10-Oct-15 01:00, Ruslan Baratov via cmake-developers wrote:

On 08-Oct-15 21:03, Mantis Bug Tracker wrote:

The following issue has been ASSIGNED.
==
https://cmake.org/Bug/view.php?id=15769  
==

Reported By:Ruslan Baratov
Assigned To:Brad King
==
Project:CMake
Issue ID:   15769
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: resolved
Target Version: CMake 3.5
Resolution: fixed
Fixed in Version:   CMake 3.5
==
Date Submitted: 2015-10-05 10:37 EDT
Last Modified:  2015-10-08 14:03 EDT
==
Summary:OS X: Filesystem timestamp checks use only 1s
resolution
Description:
`cmake --build` command doesn't trigger reconfiguration of the project on OS X
when CMakeLists.txt changed.

Example:

add_executable(foo foo.cpp) # file foo.cpp exists

cmake -H. -B_builds
cmake --build _builds
# OK

change:
add_executable(foo foo.cpp boo.cpp) # file boo.cpp not exists
cmake --build _builds
# expected error, but no error reported

Ready-to-run example can be found:
https://github.com/forexample/cmake-osx-no-reconfigure-bug

Log from OS X machine:
*https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83701171

Log for similar test on Linux machine:
*https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83702953

CMake on Linux machine run reconfigure command and report an error:
   cmake -H. -B_builds --check-build-system CMakeFiles/Makefile.cmake 0
   -- Configuring done
   CMake Error at CMakeLists.txt:4 (add_executable):
 Cannot find source file:
   boo.cpp

same error expected on OS X machine
==

--
  (0039511) Brad King (manager) - 2015-10-05 14:45
  https://cmake.org/Bug/view.php?id=15769#c39511  
--

I can reproduce this when running 'make' directly without 'cmake --build':

  -cmake --build _builds
  +(cd _builds; make)

The problem is that the filesystem and/or make tool seem to have 1s timestamp
resolution.  If I change the script to do "sleep 1" before the last "cp
CMakeBad.txt CMakeLists.txt" then it works.

--
  (0039512) Brad King (manager) - 2015-10-05 14:52
  https://cmake.org/Bug/view.php?id=15769#c39512  
--

The issue may be where CMake decides whether it needs to re-run:

  
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileTimeComparison.cxx;hb=v3.3.2#l147

The STAT_HAS_ST_MTIM code path may not be taken on this platform.

--
  (0039513) Brad King (manager) - 2015-10-05 14:54
  https://cmake.org/Bug/view.php?id=15769#c39513  
--

Indeed, on OS X "struct stat" has:

  struct timespec st_mtimespec;

instead of

  struct timespec st_mtim;

--
  (0039518) Brad King (manager) - 2015-10-06 13:27
  https://cmake.org/Bug/view.php?id=15769#c39518  
--

For reference, I've started a fix for this on the KWSys side here:

  http://review.source.kitware.com/20258/  


--
  (0039519) Brad King (manager) - 2015-10-06 14:04
  https://cmake.org/Bug/view.php?id=15769#c39519  
--

It looks like the underlying HFS filesystem only has 1s resolution:

  https://en.wikipedia.org/wiki/HFS_Plus

This may not be possible to fix without a "sleep 1" in the test script.

--
  (0039548) Brad King (manager) - 2015-10-08 14:01
  https://cmake.org/Bug/view.php?id=15769#c39548  
--

After the KWSys side learned to use st_mtimespec I've updated CMake too:

  cmFileTimeComparison: Port to OS X nanosecond times
  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d27b407  


--
  (0039549) Brad King (manager) - 2015-10-08 14:03

Re: [cmake-developers] CXX_STANDARD and linking

2015-10-09 Thread CHEVRIER, Marc 
No problem for me to keep broken behavior of SolarisStudio.
Let me know when C++ Standard support including linking part is implemented, I 
can help you to validate it on Solaris SPARC.

Thanks.

Marc




On 08/10/15 19:24, "cmake-developers on behalf of Brad King" 
 wrote:

>On 10/08/2015 11:38 AM, Brad King wrote:
>> On 10/07/2015 03:22 PM, Stephen Kelly wrote:
>>> The CMake 3.3 behavior of this is the same as it has always been since 
>>> introducing compile-features for SolarisStudio. 
>> 
>> Well that behavior was broken.  We never had a nightly dashboard for it.
>> Now I got nightly testing set up and it fails many tests without my changes.
>
>OTOH I should not have rushed in this change for 3.4.  We can just let
>it act as 3.3 did and no one will be worse off.  Then we can pick this
>up in post-3.4 development.  Reverted for now:
>
> Revert topic 'compiler-features-solaris'
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=340d0897
>
>I've scheduled this for the 'release' branch for 3.4.0-rc2.
>
>-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
-- 

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] [CMake 0015769]: OS X: Filesystem timestamp checks use only 1s resolution

2015-10-09 Thread Ruslan Baratov via cmake-developers 

On 08-Oct-15 21:03, Mantis Bug Tracker wrote:

The following issue has been ASSIGNED.
==
https://cmake.org/Bug/view.php?id=15769
==
Reported By:Ruslan Baratov
Assigned To:Brad King
==
Project:CMake
Issue ID:   15769
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: resolved
Target Version: CMake 3.5
Resolution: fixed
Fixed in Version:   CMake 3.5
==
Date Submitted: 2015-10-05 10:37 EDT
Last Modified:  2015-10-08 14:03 EDT
==
Summary:OS X: Filesystem timestamp checks use only 1s
resolution
Description:
`cmake --build` command doesn't trigger reconfiguration of the project on OS X
when CMakeLists.txt changed.

Example:

add_executable(foo foo.cpp) # file foo.cpp exists

cmake -H. -B_builds
cmake --build _builds
# OK

change:
add_executable(foo foo.cpp boo.cpp) # file boo.cpp not exists
cmake --build _builds
# expected error, but no error reported

Ready-to-run example can be found:
https://github.com/forexample/cmake-osx-no-reconfigure-bug

Log from OS X machine:
* https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83701171

Log for similar test on Linux machine:
* https://travis-ci.org/forexample/cmake-osx-no-reconfigure-bug/builds/83702953

CMake on Linux machine run reconfigure command and report an error:
   cmake -H. -B_builds --check-build-system CMakeFiles/Makefile.cmake 0
   -- Configuring done
   CMake Error at CMakeLists.txt:4 (add_executable):
 Cannot find source file:
   boo.cpp

same error expected on OS X machine
==

--
  (0039511) Brad King (manager) - 2015-10-05 14:45
  https://cmake.org/Bug/view.php?id=15769#c39511
--
I can reproduce this when running 'make' directly without 'cmake --build':

  -cmake --build _builds
  +(cd _builds; make)

The problem is that the filesystem and/or make tool seem to have 1s timestamp
resolution.  If I change the script to do "sleep 1" before the last "cp
CMakeBad.txt CMakeLists.txt" then it works.

--
  (0039512) Brad King (manager) - 2015-10-05 14:52
  https://cmake.org/Bug/view.php?id=15769#c39512
--
The issue may be where CMake decides whether it needs to re-run:

  
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmFileTimeComparison.cxx;hb=v3.3.2#l147

The STAT_HAS_ST_MTIM code path may not be taken on this platform.

--
  (0039513) Brad King (manager) - 2015-10-05 14:54
  https://cmake.org/Bug/view.php?id=15769#c39513
--
Indeed, on OS X "struct stat" has:

  struct timespec st_mtimespec;

instead of

  struct timespec st_mtim;

--
  (0039518) Brad King (manager) - 2015-10-06 13:27
  https://cmake.org/Bug/view.php?id=15769#c39518
--
For reference, I've started a fix for this on the KWSys side here:

  http://review.source.kitware.com/20258/

--
  (0039519) Brad King (manager) - 2015-10-06 14:04
  https://cmake.org/Bug/view.php?id=15769#c39519
--
It looks like the underlying HFS filesystem only has 1s resolution:

  https://en.wikipedia.org/wiki/HFS_Plus

This may not be possible to fix without a "sleep 1" in the test script.

--
  (0039548) Brad King (manager) - 2015-10-08 14:01
  https://cmake.org/Bug/view.php?id=15769#c39548
--
After the KWSys side learned to use st_mtimespec I've updated CMake too:

  cmFileTimeComparison: Port to OS X nanosecond times
  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8d27b407

--
  (0039549) Brad King (manager) - 2015-10-08 14:03
  https://cmake.org/Bug/view.php?id=15769#c39549
--
Marking

[cmake-developers] Xcode build settings and BullseyeCoverage

2015-10-09 Thread Roman Wüger 
Hello,

 

I’m trying to configure and build a project with the “Xcode” generator and
the bullseye coverage tool.

Without the bullseye coverage tool it works fine but if I want to use it I
had to do the following workaround:
http://www.bullseye.com/help/tool-xcode.html

 

In short words, the clang and clang++ ExecPath would be changed from “clang”
=> “$(PLATFORM_DEVELOPER_BIN_DIR)/clang” and “clang++” =>
“$(PLATFORM_DEVELOPER_BIN_DIR)/clang++”

 

Before I made the changes, CMake finds clang/clang++ under
“/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolch
ain/usr/bin/clang”, with the changes CMake tries to find clang/clang++ under
“/Applications/Xcode.app/Contents/Developer/usr/bin/clang” which doesn’t
exist.

And I got the following error:

 

-- The C compiler identification is unknown

-- The CXX compiler identification is unknown

CMake Error at CMakeLists.txt:3 (project):

  No CMAKE_C_COMPILER could be found.

 

 

 

CMake Error at CMakeLists.txt:3 (project):

  No CMAKE_CXX_COMPILER could be found.

 

 

 

-- Configuring incomplete, errors occurred!

 

 

However, without the changes I could build the project with “cmake –build .
-- -showBuildSettings” which gives me the following information

 

.

.

.

PLATFORM_DEVELOPER_APPLICATIONS_DIR =
/Applications/Xcode.app/Contents/Developer/Applications

PLATFORM_DEVELOPER_BIN_DIR =
/Applications/Xcode.app/Contents/Developer/usr/bin

PLATFORM_DEVELOPER_LIBRARY_DIR =
/Applications/Xcode.app/Contents/Developer/Library

PLATFORM_DEVELOPER_SDK_DIR =
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Develop
er/SDKs

PLATFORM_DEVELOPER_TOOLS_DIR =
/Applications/Xcode.app/Contents/Developer/Tools

PLATFORM_DEVELOPER_USR_DIR =
/Applications/Xcode.app/Contents/Developer/usr

PLATFORM_DIR =
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform

.

.

.

 

Why doesn’t find CMake Xcode with the modified path?

 

Is there also a way to set generator specific things during configure time?

At the moment it is only possible with the build command: “cmake -build . --
PLATFORM_DEVELOPER_BIN_DIR=PointToSomething” which sets the build settings
for Xcode

 

 

Thanks in advance

 

Best Regards

Roman

-- 

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] automatically download library

2015-10-09 Thread Марсель Галимуллин 

Thanks for your comments.

08.10.2015 18:41, Ryan Schmidt пишет:

On Oct 8, 2015, at 10:06 AM, Marsel Galimullin wrote:


The idea is that CMake has possibility to contact with package managers for 
download necessary libraries.
If “find_package” can’t find a library, it need to call apt-get install.
Example:
auto_downland(apt-get)
find_package (Boost COMPONENTS system thread REQUIRED)

I understand the idea, and I'm telling you that if you need this for your own 
personal project -- one that will never be included in a package management 
system -- then do whatever you like. But if you are proposing this as something 
that should be included in cmake, and you are suggesting that it could be used 
by any project that wants to -- even in projects that might someday be included 
in a package management system -- then I can tell you that this would not be 
welcomed by the people who maintain those package management systems. I am such 
a person. If I were tasked with the request to add to my package management 
system a project that wanted to control the installation of its own 
dependencies, or that in some other way tried to be in charge of downloading 
its dependencies, I would either have to rip all that code out, or more likely 
I would reject the request to add that project as being too labor-intensive. It 
is the package management system's job to download and install dependencies, 
not the job of the project's build system.



--
Kind regards,

Marsel Galimullin.


--

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] ITK NIfTI broken Oct 6

2015-10-09 Thread Kevin H. Hobbs 
The ITK dashboard builds on bubbles, murron, and k450e all started
failing at the configure step on October 6.

These builds all use the development version of CMake.

There were no remarkable changes in ITK that night, however there were
some interesting updates to CMake.

The errors are in the third party library NIfTI and look like this :

CMake Error at
Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:18 (install):
  install TARGETS given no LIBRARY DESTINATION for shared library target
  "znz".


CMake Error at
Modules/ThirdParty/NIFTI/src/nifti/znzlib/CMakeLists.txt:28 (install):
  install FILES given no DESTINATION!



signature.asc
Description: OpenPGP digital signature
-- 

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