-
Notifications
You must be signed in to change notification settings - Fork 0
Automating the Toolchain
| Item | Value |
|---|---|
| Guideline Number | 10 |
| Guideline Responsible (Name, Affiliation) | Asbjørn Djupdal, NTNU |
| Guideline Reviewer (Name, Affiliation) | Antonio Paolillo, HIPPEROS |
| Guideline Audience (Category) | Application Developer |
| Guideline Expertise (Category) | Toolchain Designer |
| Guideline Keywords (Category) | Toolchain |
Automate as much as practically possible with scripts.
Experience with different projects for different IDEs has shown the usefulness of using command line build tools. Also, running large numbers of experiments has shown the importance of scripting for reducing error-prone human input during the experiment runs.
Recommended implementation method of the guideline along with a solid motivation for the recommendation
While GUI IDEs are convenient for certain operations and for certain stages of the tool learning process, sometimes productivity can be enhanced by switching partially or fully to command line tools and scripting languages. Most development tools, such as Xilinx SDSoC, can be completely controlled from the command line and scripted. Time should be spent to learn these capabilities, and use them when doing development following the generic development process explained in D4.4 chapter 1.
Examples of operations suited for scripts:
-
Automating the build process. Using GNU makefiles or CMake can be more dependable and easier in the long run, compared to specifying build configurations inside some unstandardised GUI tool. This is especially true when several developers work on the same project. Specifying the build process in this way is also a requirement for other automated operations, such as end-to-end automated testing. This way of building is also much more suited for version control systems.
-
Repetitive and/or error prone operations. Example: Regression testing a new build on the target platform, when interactive debugging capabilities are not needed.
-
Complex operations where the steps are unlikely to be remembered to the next time it is required. Example: Running an experiment on the target platform and creating reports from program runs
-
Using the toolchain on systems where a GUI is impossible or impractical. Example: The toolchain is installed on a build server and the network connection to the developer desktop is too slow for comfortably forwarding the GUI.
The analysis tool (D4.4) has been realised, partly due to the scripting capabilities of the GNU and Xilinx development tools. Makefiles are generated automatically which control the build process and ties all tools together. Most functionality of the tools provided by TULIPP are available from the command line, and is thus scriptable.
Although development time when using tools such as CMake is perceived to be reduced significantly, it is difficult to quantify, or prove, this advantage. The same goes for other usages of scripting, such as automated tests. However, most experienced developers would probably agree that command line tools and scripting enhances productivity. The analysis tool shows that the possibility to control tools through makefiles can be very useful.
None
TULIPP Guideline Wiki