Safeness of Make-Based Incremental Recompilation

Jørgensen, Niels

doi:10.1007/3-540-45614-7_8

Cited by 6 publications

(2 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The Java API pluto [17] also addresses incremental builds; it comes with a formalization which shows that pluto provides a sound and optimal incremental build system with dynamic dependencies. A notion of safeness has also been studied for Make-based build management with coverage of incremental compilation [27].…”

Section: Declarative Build Managementmentioning

confidence: 99%

Relationship Maintenance in Software Language Repositories

Lämmel

2017

Programming

View full text Add to dashboard Cite

The context of this research is testing and building software systems and, specifically, software language repositories (SLRs), i.e., repositories with components for language processing (interpreters, translators, analyzers, transformers, pretty printers, etc.). SLRs are typically set up for developing and using metaprogramming systems, language workbenches, language definition frameworks, executable semantic frameworks, and modeling frameworks.This work is an inquiry into testing and building SLRs in a manner that the repository is seen as a collection of language-typed artifacts being related by the applications of language-typed functions or relations which serve language processing. The notion of language is used in a broad sense to include text-, tree-, and graphbased languages as well as representations based on interchange formats and also proprietary formats for serialization.The overall approach underlying this research is one of language design driven by work on a particular SLR, YAS, which features a significant number of processed languages and language processors as well as a noteworthy heterogeneity in terms of representation types and implementation languages.The knowledge gained by our research is best understood as a declarative language design for regression testing and build management; we introduce a corresponding language Ueber with an executable semantics which maintains relationships between language-typed artifacts in an SLR.The grounding of the reported research is based on the executable, logic programming-based definition of the Ueber language and its systematic application to the management of YAS which consists of hundreds of language definition and processing components (such as interpreters and transformations) for more than thirty languages (not counting different representation types) with Prolog, Haskell, Java, and Python being used as implementation languages.The importance of this work stems from its objective of helping to understand and maintain relationships in SLRs, thereby directly helping users and developers of SLRs. ACM CCS 2012

show abstract

Section: Declarative Build Managementmentioning

confidence: 99%

Relationship Maintenance in Software Language Repositories

Lämmel

2017

Programming

View full text Add to dashboard Cite

show abstract

“…This section explains what it means for a build to be able to execute incrementally or in parallel, by reference to "safe" Make-based builds as formalized by Niels Jørgensen [6]. To motivate our work, we use Jørgensen's insights into when incremental builds are safe to explain why all-or-nothing builds are so prevalent.…”

Section: Introductionmentioning

confidence: 99%

Grexmk

Ammons

2006

Proceedings of the 2006 International Workshop on Dynamic Systems Analysis

View full text Add to dashboard Cite

Slow builds can be extremely costly; for example, one of our customers loses forty percent of their developers' productivity to waiting on builds. Build avoidance-building only what must be built to integrate a change-solves the problem but makes the build unreliable unless the build script captures all dependences of build outputs on sources. Therefore, in practice, integrating even a minor change often requires rebuilding a large software system from scratch.Our solution can be summarized as "trust but verify". Exploiting the fact that large software systems tend to be composed of loosely coupled parts, we semi-automatically divide a large, all-or-nothing build into many small "mini-builds", without changing the original build. Each mini-build declares its dependences, which are trusted while scheduling mini-builds to integrate a change but verified by executing each mini-build in a sandbox in which only its declared dependences are available.We implemented these ideas in a tool suite called Grexmk and applied Grexmk to two large all-or-nothing builds. On the first build, we demonstrated linear speedups to six build machines. On the second build, we sped up the average time for an incremental build by a factor of 1.2.

show abstract