Below you can find a list of tasks that are not worth putting in a bug tracker.
Mostly because they involve some refactoring, or because they would cause so many changes we are not sure if/when we will tackle them.
Feel free to add your own ideas here.
It maybe a good idea to remove the compatibility with pure cmake tests.
Instead, only use qi_create_test and generate custom files instead (thus we no longer have to parse cmake-generated cmake code)
It became easier to write code like this
qi_create_test(... NIGHTLY)
qi_create_test(.... PERF)
Introduce options like WITH_TESTS, WITH_PERF_TESTS instead of having to deal with BUILD_TESTS and enable_testing()
qibuild does lots of black magic so that you can find dependencies and headers paths from the sources and build dir of your project, without using the “global cmake registry” or any other tricks.
However:
The solution is simple: After building a dependency, install it to QI_WOKTREE/root and just set CMAKE_INSTALL_PREFIX to QI_WOKTREE/root
This will work with any build system, (provided they have correct install rules), and will force people to have correct install rules.
Say you find a foo-config.cmake somewhere... If you try to do
find_package(FOO)
qi_create_bin(bar)
qi_use_lib(bar FOO)
This may or may not work: it depends of what the foo-config.cmake does: qi_use_lib , qi_stage_lib expects some variables (FOO_INCLUDE_DIRS, FOO_LIBRARIES) to be in the cache
It may be cleaner to add a qi_export function
find_package(FOO)
# works out of the box if foo follows CMake conventions
qi_export(foo)
# can specify alternative variable names (here the case is wrong)
qi_export(foo
LIBRARIES ${Foo_LIBRARY}
)
Basically, go from
find_package(EIGEN3)
include_directories(${EIGEN3_INCLUDE_DIRS})
include_directories("include")
qi_stage_header_only_lib(foo DEPENDS EIGEN3)
To
qi_create_header_only_lib(foo ${public_headers})
qi_use_lib(foo EIGEN3)
qi_stage_lib(foo)
where foo is a header-only library depending on Eigen3
At the very least name, version and arch.
Tracking dependencies may be a good idea, too.
This will allow to replace qitoolchain add-package foo foo.zip with qitoolchain add-package foo.zip with makes much more sense
Also : use XML for persistent storage of toolchain packages and add override config files to track the packages the user manually adds or removes
This will solve the bug qitoolchain remove-package boost; qitoolchain update that makes boost reappear in the toolchain.
It’s the future ! We already removed compatibility with Python 2.6, and python3 is now the default version on most linux distros.
parser.get_* functions should be usable with **kwargs too:
def get_worktree(args=None, **kwargs):
options = dict()
if args:
options = vars(args[0])
else:
options = kwargs
qisrc.parser.get_projects(worktree, args) -> qisrc.parser.get_projects(args) (just get the worktree from the args)
replace qisys.interact.ask_choice Instead of a return_int option, use something like: ask_choice(message, choices, display_fun=None, allow_none=False)
display_fun will be called on each choice to display them to the user, returning either an element from the choices list, or None if the user did not enter anything and allow_none is True
Use same API as shutil in qisys.sh and qisys.archive: