Sometimes doing HTTP operations it’s required to provide some extra headers. For example, talking to JFrog Artifactory requires the X-JFrog-Art-Api header w/ API key.
I propose to add EXTRA_HEADERS <string>... named parameter to the file(UPLOAD|DOWNLOAD ...) signature.
P.S. I’m ready to make an MR for this.
P.S.S. The other thing that will be nice to have is a configurable HTTP method to be able to talk to various REST APIs. For example, upload could be done via POST, PUT, CREATE, or even PATCH methods. There is HTTP DELETE method which is also nice to have (e.g. to delete files from Artifactory repos), but currently I’ve got no clear idea how to extend file signature for this.
@zaufi you’ve been proposing many CMake language features that imply you’re using it as a general-purpose scripting language. Why? It’s meant for configuring project build trees and simple glue scripts. Interacting with REST APIs is well outside that scope. I don’t think we should grow the language that much.
One can use find_program()/find_package(...) and execute_process do arbitrary things in a true general-purpose language like Python.
I’ve added a custom target to build ABI dumps. The result dumps I want to store in JFrog Artifactory at the release build step. The master builds gonna check the ABI changes against the latest release.
Having “external” scripts in Python, means I have to start at lease one repo and full featured Python project which includes: tests, setup.py, building package, add CI builds, add a private pypi repo and deploy built packages to it, manage to preinstall of this CLI tool into my docker images used to build my projects, use find_program in my CMake project, add custom target or output…
All that pain in the ass could be done w/ couple REST API requests to Artifactory…
That is why I strongly believe http() command is a better way.
No sure why you say that.
You can perfectly use a prebuilt python docker image (or any other prebuilt image that contains the tools you need to do REST request) and use it to run a python script which would be stored in your current repo as an helper script just as CMakeLists.txt or other xxx.cmake may be.
I don’t get why you would need a full-blown python module for that?
You may pass anything coming from a CMake build (CI) step as build artifact to the one that needs it.
I don’t know which CI you use but I bet any CI could use various docker images for various step/jobs?