In my team I decided to use Python3 script to manage the project written in C++. Thus I use the script in order to gather all functionality above the project in one place. I use it for:
For example I call: ./foo.py stat to collect stats. There is a bunch utilities inside. I operate with them using sys and os.
I find it nice, but I'm afraid that it's a bad practice and ultimately it will turn into problems and also that this is a bad taste.
Here are the questions:
Whether using python scripts for those tasks is a good solution seems quite project specific to me, and trying to answer such a question might not be adequate. Let me nevertheless try to categorize a bit.
- launching make
- launching test make
- compile docs
You should ask yourself why invoking make, make test and make docs isn't enough. The python layer in between seems an overkill to me, as I can't think of a scenario where it adds so much more convenience. If the make invocation is too complicated (e.g. because lots of arguments have to be specified), I would first try to work on the Makefile itself to make it easier to use.
- collect statistics
Makes sense to me.
- check coding style
"Coding style" means an awful lot of things, but when you try to enforce naming conventions, function length or code formatting, I'd advice you to use clang-tidy and clang-format to not reinvent the wheel. These tools are quite powerful and can be controlled by a configuration file that can be part of your project. If it's convenient to call these tools from a python script, or use a python script to generate a compile_commands.json, that's seems fine to me.
In general, different tasks require different tools, and I wouldn't try to build a universal wrapper around those tools to create a holistic interface, as your python scripts will grow over time (what about version control, packaging for debug/release...) until it becomes hard to manage. Prefer small, simple scripts that do one thing (by the way, this might the case in your approach, I can't tell).
To comment on some of the last questions of your post,
- Is it a common practice?
Small scripts for specific tasks like generating some repo statistics: yes. A large, handwritten tool for managing builds, releases, documentation: I'd say no.
- If it's not then why?
Cross-platform functionality like this is extremely hard to get right, as there is an infinite number of edge cases. Rolling your own tools can simply consume too much time. Instead, configuring existing tools carefully might be the most efficient strategy. Plus, if you go with established tools, (new) developers are likely to be used to it.