elucideye / drishti

Real time eye tracking for embedded and mobile devices.
BSD 3-Clause "New" or "Revised" License
390 stars 82 forks source link

3rd parties enhancement #88

Open ruslo opened 7 years ago

ruslo commented 7 years ago

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:

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:

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:

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

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:

headupinclouds commented 7 years ago

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 commented 7 years ago

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.