We present a system of plug-ins for GCC that allows GCC to load GIMPLE transformations at run-time. This system reduces the support effort required for GCC by separating transformations from the core compiler. It also makes it possible for developers not connected with the GCC project to develop and distribute transformations independently. We demonstrate two plug-ins we have developed with this system, one of which reduces the effort required to develop transformations significantly by allowing visualization of the GCC controlflow graph and the GIMPLE tree structure. We enumerate portions of the compiler that could be extracted into plug-ins, and describe future applications of the plug-in system. 1

Abstract. Modern software codebases are frequently large, heterogeneous, and constantly evolving. The languages and tools for software construction, including code builds and configuration management, have not been well-studied. Developers are often faced with using 1) older tools (like make) that do not scale well, 2) custom build scripts that tend to be fragile, or 3) proprietary tools that are not portable. In this paper, we study the build issue as a domain-specific programming problem. There are a number of challenges that are unique to the domain of build systems. We argue that a central goal is compositionality—that is, it should be possible to specify a software component in isolation and add it to a project with an assurance that the global specification will not be compromised. The next important goal is to cover the full range of complexity—from allowing very concise specifications for the most common cases to providing the flexibility to encompass projects with unusual needs. Dependency analysis, which is a prerequisite for incremental builds, must be automated in order to achieve compositionality

Reuse between software systems is often not optimal. An important reason is that while at the functional level well-known modularization principles are applied for structuring functionality in modules, this is not the case at the build level for structuring files in directories. This leads to a situation where files are entangled in directory hierarchies and build processes, making it hard to extract functionality and to make functionality suitable for reuse. Consequently, software may not come available for reuse at all, or only in rather large chunks of functionality, which may lead to extra software dependencies.

The GNU automatic software configuration tools, Autoconf, Automake, and Libtool, were designed to help the portability of software to multiple platforms. Such autotools also help improve the readability of code and speed up the development cycle of software packages. In this paper we quantify how helpful such autotools are to the open-source software development process. We study several large packages that use these autotools and measure the complexity of their code. We show that total code size is not an accurate measure of code complexity for portability; two better metrics are the distribution of CPP conditionals in that code and the number of new special-purpose Autoconf macros that are written for the package.

Introduction This note gives some practical information on the configuration and usage of the Replica Catalog used in the CERN DataGrid testbed. Some basic knowledge of LDAP directories, the Unix operating system, and of the Globus Replica Catalog is assumed, however, for ease of reference, a short review of LDAP and the Replica Catalog is given. 1.1 LDAP directories A directory is a kind of remotely accessed, and usually distributed, database. While a general purpose database (e.g., a relational database) can handle complex transactions (both updates and queries) on highly structured data, a directory is oriented towards straightforward lookup operations on simple data, such as "find the telephone number of Mr. J. Random", or "find the names of all employees who have a degree in Indo-European Philology". More complex queries are possible, but directories are not necessarily optimized for them. Typically, the information contained in a directory is not accessed directly by the end u

The GNU automatic software configuration tools, Autoconf, Automake, and Libtool, were designed to help the portability of software to multiple platforms. Such autotools also help improve the readability of code and speed up the development cycle of software packages. In this paper we quantify how helpful such autotools are to the open-source software development process. We study several large packages that use these autotools and measure the complexity of their code. We show that total code size is not an accurate measure of code complexity for portability; two better metrics are the distribution of CPP conditionals in that code and the number of new special-purpose Autoconf macros that are written for the package. We studied one package in detail—Am-utils, the Berkeley Automounter. As maintainers and developers of this package, we tracked its evolution over ten years. This package was ported to dozens of different platforms and in 1997 was converted to use GNU autotools. We show how this conversion (autotooling) resulted in a dramatic reduction in code size by over 33%. In addition, the conversion helped speed code development of the Am-utils package by allowing new features and ports to be integrated easily: for the first year after the conversion to GNU autotools, the Am-utils package grew by over 70 % in size, adding many new features, and all without increasing the average code complexity. 1

Production of a large-scale software system involves quite a few software components. It is very common to develop such software components in a distributed environment consisting of multiple computer systems connected by computer networks. In order to support effective software development in a distributed environment, a mechanism to combine a large number of components, which are distributed over the network, into a single system in a systematic way is quite essential. Object Make is a tool that automates the building process of software systems consisting of software components that are stored in the file systems of distributed computer systems, as if they are stored in a single file system. Software developers are not required to transfer these remote components to their own local computer systems explicitly, even if the computer systems do not share a common file system. This paper will give an overview of the distributed software build process for large-scale software systems using Object Make.