Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3rd parties enhancement #88

Open
ruslo opened this issue Sep 27, 2016 · 2 comments
Open

3rd parties enhancement #88

ruslo opened this issue Sep 27, 2016 · 2 comments

Comments

@ruslo
Copy link
Collaborator

ruslo commented Sep 27, 2016

There are an improvement ideas about CMake/Hunter/Polly that have mentioned in few bugs which may have influence on Drishti. This bug will summarize them. Though most of them can be fixed simply in Drishti itself or workarounded somehow, it may be useful to know the whole picture. Probably those pieces of the puzzle will form a new directions.

CMake

Automatic grouping in IDE (Xcode/Visual Studio)

I have a bunch of Python modules in Sugar for such job. But this functionality require to have Python installed and require patching of CMakeLists.txt. If such feature will be implemented in CMake then we can simply add set(CMAKE_IDE_AUTOMATIC_LAYOUT TRUE) or even have this feature ON by default (introduce new CMake policy).

Mirror CMake option to C++ definition

This is kind of widely used pattern of transparent connectivity of CMake and C++ levels. Though I think that drishti_mirror_definition should be applied for targets (i.e. call target_compile_definitions instead of add_definitions).

Size of installed files

Introduce two features:

  • New command file(SIZE ...)
  • Add option for printing installed sizes using file(SIZE ...), like CMAKE_INSTALL_SIZE_INFO=K (K - kilobytes, M - megabytes, H - human readable, see man ls)

Testing of installed libraries

This feature missing in CMake itself, I did mentioned it here for example. The next errors is not covered by regular testing:

  • Missing definitions. Internally package can define macro by add_definitions("-DFOO"). And if macro FOO used in public header then FOO will be defined on build step and not after the install step.
  • Missing find_dependency call. Error happens quite often: after package installed and find_package(CONFIG) called, users got "target Boo::boo is not built by this project, probably find_package is missing". This error means that we have to call find_dependency(Boo) in FooConfig.cmake file.
  • Private headers usage/missing headers. Layout of headers on build step may differs from layout after install. In this case if package is using some private header (header that are not planned to install) there will be no error on build step. And vice versa if we are planning to use some header but forget to install it.

CMake methods for manipulation C++ warnings

The feature described here: https://cmake.org/pipermail/cmake-developers/2016-April/028279.html and I'm planning to implement it anyway (my priorities: CGold, Hunter docs, this feature) since it's an importand part of C++ ecosystem which provide one more benefit of using CMake :) Also it will be closely coupled with Leathers (Leathers is a C++ level of CMake funtionality). Idea based/tested on Sugar modules.

Work with JSON format for GitHub API

This one needed for Hunter for uploading binaries to GitHub using CMake instead of Python scripts. Need to introduce new command/family of commands for working with JSON format, like json(PARSE ...) or string(JSON ...) to parse responses from GitHub. I know that some JSON library already integrated into CMake for server-mode feature so just need to discuss/develop API and implement it. Alternatively kind of GitHub API commands can be introduced, like file(GITHUB_API RELEASE_ID release_id RELEASE "v0.0.1" REPO user/repo), file(GITHUB_API RELEASE_LIST release_list REPO user/repo).

I no longer think it's a good idea. It's better to create service that will handle this stuff and other "remote" things.

Single Compilation Unit

I still haven't used cotire tool however common sense and API I saw make me think that implementing SCU in CMake itself has next benefits:

  • You don't have to patch CMakeLists.txt
  • 3rd party library can be added to final single source file too

It means that if you have add_library(foo foo.cpp) there are next variants:

  • BUILD_SHARED_LIBS=ON build shared library
  • BUILD_SHARED_LIBS=OFF build static library (default)
  • CMAKE_BUILD_SCU=ON: for libraries don't build anything, just save the list of files and add them to the final executable. If such library planned to be installed - install only sources and special directive in *Config.cmake file so user can still use find_package(foo CONFIG REQUIRED) + target_link_libraries(<exe> PUBLIC foo)

Hunter

Uploading binaries to GitHub without use of Python script

This feature is important for having custom/private cache servers when user upload binaries without having fork of the Hunter with upload.* branches. The main difference is about the fact that upload.* do operations step-by-step, e.g. if there are A, B, C dependent packages then first we run upload.A, then upload.B, then upload.C. When user have one job for it he should wait for all A, B, C packages built in one single step. If A+B+C takes longer then 50 minutes (or other timeout) there will be no packages uploaded at all. For this feature we need CMake support (see JSON/GitHub API).

Alternative approach will be to use custom front-end server that will handle requests from Hunter and redirect them to the back-end. Different back-ends can be implemented depending on user's settings: S3 bucket, GitHub repository, Sourceforge, custom server, etc. I see it like this: user enter the site with service, login with credentials, set back-end for the upload. Then using same credentials Hunter send request about upload. Server check credentials, determine user, determine user's back-end and redirect request. I have very poor experience with web development so can't say any implementation details for now.

Managing compilers with Hunter

Alternative to using clang from Xcode or brew. The benefits is that we can control build options and version of compilers using CMake code and Hunter packages, store them to binary cache server, etc.
Basic issue is here: https://github.com/ruslo/hunter/issues/495

Thaw

I have an idea about creating super tool for bootstraping. This tool will include:

  • functionality of Polly (something based on aliasing, some will be moved to Hunter)
  • install-ci-dependencies.py: install latest CMake verion (or precise)
  • Implement aliasing system: https://github.com/ruslo/CMake/issues/3 (instead of implementing it in CMake, my proposal was rejected)
  • Hunter root maintenance: https://github.com/ruslo/hunter/issues/173
  • Reporting human readable/understandable difference between toolchains-id so user can easily find the way how to tweak his environment to use cache server
@headupinclouds
Copy link
Collaborator

headupinclouds commented Sep 28, 2016

Automatic grouping in IDE (Xcode/Visual Studio)

This one is fairly low priority. I've pushed an initial update for the drishti_world target (that loses the automatic grouping provided by multiple modules/libraries) using this approach:

  source_group("core\\Header Files" FILES ${DRISHTI_CORE_HDRS_PUBLIC})  
  source_group("core\\Source Files" FILES ${DRISHTI_CORE_SRCS})

which provides basic namespace + header and source grouping. I think this is good enough for now, given the more urgent functionality issues.

@ruslo
Copy link
Collaborator Author

ruslo commented Jan 18, 2017

I have a bunch of Python modules in Sugar for such job

Need to take a closer look at this feature:

I think it's exactly what I do but in CMake.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants