Concepts, Operations, and Feasibility of a Projection-Based Variation Control System S, tefan Stanciulescu˘ Thorsten Berger Eric Walkingshaw Andrzej W ˛asowski IT University of Copenhagen Chalmers | University of Gothenburg Oregon State University IT University of Copenhagen Denmark Sweden USA Denmark [email protected] [email protected] [email protected] [email protected] Abstract—Highly configurable software often uses preproces- // LCD selection sor annotations to handle variability. However, understanding, #ifdef U8GLIB_ST7920 maintaining, and evolving code with such annotations is difficult, //U8GLIB_ST7920_128X64_RRD u8g(0,0,0); mainly because a developer has to work with all variants at a U8GLIB_ST7920_128X64_RRD u8g(0); time. Dedicated methods and tools that allow working on a subset #elif defined(MAKRPANEL) of all variants could ease the engineering of highly configurable // The MaKrPanel display, software. We investigate the potential of one kind of such tools: // ST7565 controller as well projection-based variation control systems integrated with projec- U8GLIB_NHD_C12864 u8g(DOGLCD_CS, DOGLCD_A0); tional editors. For such systems we aim to understand: (i) what #elif defined(VIKI2) || defined(miniVIKI) end-user operations they need to support, and (ii) whether they // Mini Viki and Viki 2.0 LCD, can realize the actual evolution of real-world, highly configurable // ST7565 controller as well software. We conduct an experiment that investigates variability- U8GLIB_NHD_C12864 u8g(DOGLCD_CS, DOGLCD_A0); related evolution patterns and that evaluates the feasibility of a #elif defined(ELB_FULL_GRAPHIC_CONTROLLER) projection-based variation control system by replaying parts of // Based on the Adafruit ST7565 the history of a real-world 3D printer firmware project. Among // (http://www.adafruit.com/products/250) others, we show that the prototype variation control system does U8GLIB_LM6059 u8g(DOGLCD_CS, DOGLCD_A0); indeed support the evolution of a highly configurable system and #else that in general, it does not degrade the code. // for regular DOGM128 display with HW-SPI // HW-SPI Com: CS, A0 U8GLIB_DOGM128 u8g(DOGLCD_CS, DOGLCD_A0); #endif Listing 1. Source code with annotations Consider the example from Listing1. 1 The code represents I. INTRODUCTION several variants related to the printer display that can be used. Understanding the code and what impact would a change have is more difficult because of the many variants. The projectional editing model [35] proposes a mechanism that allows to edit only the variants we are interested in. For example, selecting Tailoring systems to specific needs of users—such as hardware the MARKPANEL feature will give us the following code. environments, runtime platforms or various combinations of features—is becoming increasingly important. Such systems are // The MaKrPanel display, // ST7565 controller as well typically highly configurable by containing massive amounts U8GLIB_NHD_C12864 u8g(DOGLCD_CS, DOGLCD_A0); of variability, which is often realized using static variability annotations, such as conditional compilation directives, e.g. Now the developer can make a change on this variant, that #ifdef in C code [17]. While such annotations are among the contains less code and it is easier to understand than the source most frequently used and most simple variability mechanisms, code in Listing1, and should be able to update the repository their use is known to complicate writing, maintaining (e.g., bug- with the new code. fixing), and evolving (e.g., adding a cross cutting feature) source Various methods and tools that allow working on a dedicated code [10]. Variability annotations obscure the structure and flow subset of all variants have been proposed in the literature [35], of the underlying code [29], since much of the conditionally [21], [3], [18], [16]. These can ease to some degree the included code is often irrelevant for a particular code-editing engineering of highly configurable software, though none of task. In fact, working on all possible variants of the system them has found widespread adoption. In fact, no empirical at once is known to negatively impact the comprehension of data is available that shows how exactly they can be used to source code [24]. Beyond syntax-highlighting and code-folding, 1Source code from Marlin: https://github.com/MarlinFirmware/Marlin/ none of the major IDEs supports editing variant subsets while blob/a83bf18ee1063798e75ad6324b033752e0b1f66f/Marlin/dogm_lcd_ ensuring the consistency of the whole system. implementation.h engineer real-world systems, and what their specific benefits tems [18], [25] that provide editable views based on projections and challenges are. Another kind of tools that provide views specified by developers, and the projectional editing model [35]. on programs, but that are actually adopted in practice [32], All rely on variability realized using annotations embedded in are projectional editors, such as Jetbrains’ Meta Programming code, similar to C’s conditional-compilation directives (e.g., #if System [1] or Intentional’s Domain Workbench [27], [4]. Un- or #ifdef). These annotations carry a Boolean expression over fortunately, they lack dedicated operations related to editing features, called presence condition (PC) in the remainder. The source code with variability. first two systems do not exist anymore and there is hardly any In this paper, we conduct an empirical study to assess the evidence to their usefulness. The third has not been empirically feasibility of such methods and tools that allow working on evaluated and no publicly available tool exists. a dedicated subset of all variants, such as the projectional Kruskal [18], [19] presents an editor that realizes both editing model [35]. Towards building efficient, projection-based concurrent versioning (variability) and sequential versioning methods and tools for engineering highly configurable software, (deltas) relying on variability annotations. Similar to conditional we need to understand what operations users need and how they compilation, code lines are mapped to Boolean PCs, represent- could deal with such operations. To investigate if projection- ing both the variant and the version that specific lines belong based methods and tools can be used to engineer real world to. The editor creates views based on a partial configuration systems, we realize a variation control system that supports the (a conjunction of features) called mask, supporting workflows following workflow: (1) checkout the source code according where developers start with a relatively broad mask (e.g., to a given condition, (2) edit the code, and (3) checkin the projecting on just one feature), potentially restricting the mask edited code. by conjoining other features (i.e., “push” more masks on a Our system combines and extends concepts from prior work, stack), editing code in the views belong to the more restricted such as a projectional editing model [35] and change-oriented masks, and then returning to more broad masks (i.e., “pop” versioning [22]. We describe it using the choice calculus [8], masks from a stack). Code lines with PCs that do not contradict [33], [34], a concise and formal notation that avoids dealing the mask are visible for editing. Several convenience commands with intricate C preprocessor semantics and allows reasoning are available to the user for iterating through variants and for about highly configurable systems. manipulating PCs. Unfortunately, the editor is not available To identify end-user edit operations the system should anymore, and no empirical data on its use exists. support, we analyze the history of a highly configurable open- Lie et al. [22], Munch [25], and Westfechtel et al. [36] present source software system: the 3D printer firmware Marlin. We and evaluate an alternative versioning model based on logical aim at understanding the kinds of changes (patterns) related to changes: change-oriented versioning (CoV). It also unifies variability done by developers. We cross-validate the patterns versioning and variability, by attaching Boolean PCs to file using Busybox, an open-source project implementing shell fragments. It follows a classical checkin/checkout cycle, where tools for embedded systems. Based on the patterns we show a configuration (conjunction of features) determines both how the edit operations for the variation control system can the version and the variant available in the view (i.e., the be implemented. We then conduct an experiment where we workspace), which can be edited. It decouples the projection use our variation control system to replay parts of Marlin’s (called “choice”) from the expression used to checkin the edited history—by applying randomly selected patches to study how view (called “ambition”) to denote to which variants a change the edit operations can be realized using the variation control applies to. In an empirical study the authors translate existing system. In summary, we contribute: C/C++ source code files of gcc into CoV representation in • A projection-based variation control system relying on a a database (EPOSDB-II [12]), and compare the performance checkout/checkin workflow and automatically handling against RCS [30] when checkin version 2.4.0 of gcc. The variability annotations; experiment investigates only performance. It does not show how • End-user edit operations that show the use of the variation feasible it is to actually engineer a real-world system, and how control system, based on identified variability-related code