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)
find_package(Qt5Widgets REQUIED)
target_compile_definitions(... USE_QT_GUI)
else()
find_package(WxWidgets REQUIRED)
target_compile_definitions(... USE_WXWIDGETS_GUI)
endif()
endif()
if(USE_SECURITY)
find_package(OpenSSL REQUIRED)
target_compile_definitions(... USE_OPENSSL)
endif()
if(BUILD_TESTS)
find_package(GTest REQUIRED)
...
endif()
if(GENERATE_DOCUMENTATION)
find_package(Doxygen REQUIRED)
...
endif()
So instead of violating DRY and duplicating this information in some
*newly* created format for spec file, like:
option(USE_GUI) && WINDOWS && option(USE_QT): Qt
option(USE_GUI) && !WINDOWS && option(USE_QT): WxWidgets
option(USE_GUI) && WINDOWS && option(USE_WXWIDGETS): WxWidgets
...
option(USE_SECURITY): OpenSSL
option(BUILD_TESTS): GTest
option(GENERATE_DOCUMENTATION): Doxygen
We can use CMake code:
if(USE_QT)
install_package(Qt)
find_package(Qt5Widgets REQUIED)
target_compile_definitions(... USE_QT_GUI)
else()
install_package(WxWidgets)
find_package(WxWidgets REQUIRED)
target_compile_definitions(... USE_WXWIDGETS_GUI)
endif()
I think spec files used in many package managers because of obstructions
that are not applying to CMake or which CMake is able to solve, some
examples:
* python requirements.txt - no need to have a built system at all
* cocoapods - it's hard to customize/extend Xcode project to support it
(one of the reason why such tools like CMake exist)
* brew/apt-get/emerge - (don't have any spec files actually, set
dependencies in README file) because widely used tools like Makefile is
not designed to do even a simple task like finding libraries, other
tools like autotools are too complex to extend/use (again, that's why
CMake exist)
* ... your examples here ...
Cheers, Ruslo
--
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
