DOCSLIB.ORG

Using GNU Autotools May 16, 2010 1 / 162 A

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Using GNU Autotools May 16, 2010 1 / 162 A Foreword Tool Versions Foreword (1/2) Foreword (2/2) This document was updated for the following releases of the Autotools: This presentation targets developers familiar with Unix development tools GNU Autoconf 2.65 (November 2009) (shell, make, compiler) that want to learn Autotools. GNU Automake 1.11.1 (December 2009) The latest version of this document can be retrieved from GNU Libtool 2.2.6b (November 2009) GNU Gettext 0.17 (November 2007) http://www.lrde.epita.fr/~adl/autotools.html These were the last releases at the time of writing. Please mail me corrections and suggestions about this document at [email protected]. The usage of these tools has improved a lot over the last years. Do not send me any general question about the Autotools. Use the Some syntaxes used here will not work with older tools. appropriate mailing list instead ([email protected], or This a deliberate choice: [email protected]). New users should learn today’s recommended usages. Make sure you have up-to-date tools and do not bother with old releases. A. Duret-Lutz Using GNU Autotools May 16, 2010 1 / 162 A. Duret-Lutz Using GNU Autotools May 16, 2010 2 / 162 Title Page Part I Using GNU Autotools The GNU Build System Alexandre Duret-Lutz 1 Goals [email protected] Portable Packages Uniform Builds 2 Package Use Cases May 16, 2010 The User Point of View The Power User Point of View Copyright c 2010 Alexandre Duret-Lutz The Packager Point of View http://creativecommons.org/licenses/by-sa/2.0/ The Maintainer Point of View 3 The configure Process Trivial source code examples displayed in this tutorial (such as the C files, Makefile.ams, and configure.acs of all the ‘amhello’ 4 Why We Need Tools projects) can be reused as if they were in the public domain. A. Duret-Lutz Using GNU Autotools May 16, 2010 3 / 162 A. Duret-Lutz Using GNU Autotools May 16, 2010 4 / 162 Goals Portable Packages Goals Portable Packages Portable Packages Sources of Non-Portability in C 1 Goals Consider C functions... Portable Packages that do not exist everywhere (e.g., strtod()) Uniform Builds that have different names (e.g., strchr() vs. index()) 2 Package Use Cases that have varying prototypes The User Point of View (e.g., int setpgrp(void); vs. int setpgrp(int, int);) The Power User Point of View that can behave differently (e.g., malloc(0);) The Packager Point of View that might require other libraries The Maintainer Point of View (is pow() in libm.so or in libc.so?) that can be defined in different headers 3 The configure Process (string.h vs. strings.h vs. memory.h) 4 Why We Need Tools How should a package deal with those? A. Duret-Lutz Using GNU Autotools May 16, 2010 5 / 162 A. Duret-Lutz Using GNU Autotools May 16, 2010 6 / 162 Goals Portable Packages Goals Portable Packages Possible Solutions Code Cluttered with #if/#else Excerpt of ffcall-1.10’s alloc trampoline() #i f ! defined(CODE EXECUTABLE ) static long pagesize = 0; #i f d e f i n e d (EXECUTABLE VIA MMAP DEVZERO) static int zero fd ; Slice the code with lots of #if/#else #endif i f (! pagesize) { Create substitution macros #i f d e f i n e d (HAVE MACH VM) pagesize = vm page size; Create substitution functions #else pagesize = getpagesize(); The latter two are to be preferred. #endif #i f d e f i n e d (EXECUTABLE VIA MMAP DEVZERO) zero fd = open(”/dev/zero”, O RDONLY, 0 6 4 4 ) ; i f (zero f d < 0) { fprintf(stderr , ”trampoline: Cannot open /dev/zero! \ n”); abort (); } #endif } #endif A. Duret-Lutz Using GNU Autotools May 16, 2010 7 / 162 A. Duret-Lutz Using GNU Autotools May 16, 2010 8 / 162 Goals Portable Packages Goals Portable Packages Substitution macros Substitution functions If strdup() does not exist, link your program with a replacement definition such as Excerpt of coreutils-5.2.1’s system.h strdup.c (from the GNU C library) #if ! HAVE FSEEKO && ! defined fseeko char ∗ # define fseeko(s, o, w) ((o) == ( long ) (o) \ strdup ( const char ∗ s ) ? fseek (s, o, w) \ { : ( e r r n o = EOVERFLOW, −1)) size t len = strlen (s) + 1; #endif void ∗new = malloc (len); if ( new == NULL) Then use fseeko() whether it exists or not. return NULL ; return ( char ∗) memcpy (new, s, len); } A. Duret-Lutz Using GNU Autotools May 16, 2010 9 / 162 A. Duret-Lutz Using GNU Autotools May 16, 2010 10 / 162 Goals Uniform Builds Goals Uniform Builds Uniform Builds Need for Automatic Configuration 1 Goals Portable Packages Maintaining a collection of #define for each system by hand is Uniform Builds cumbersome. Requiring users to add the necessary -D, -I, and -l compilation 2 Package Use Cases options to Makefile is burdensome. The User Point of View Complicated builds hinder the acceptance of free software. The Power User Point of View The Packager Point of View The Maintainer Point of View In 1991 people started to write shell scripts to guess these settings for some GNU packages. 3 The configure Process Since then the configure script is mandatory in any package of the GNU project. 4 Why We Need Tools A. Duret-Lutz Using GNU Autotools May 16, 2010 11 / 162 A. Duret-Lutz Using GNU Autotools May 16, 2010 12 / 162 Goals Uniform Builds Goals Uniform Builds configure’s Purpose GNU Coding Standards configure http://www.gnu.org/prep/standards/ Practices that packages of the GNU project should follow: program behavior Makefile src/Makefile config.h how to report errors, standard command line options, etc. configure probes the systems for required functions, libraries, and coding style tools configuration then it generates a config.h file with all #defines Makefile conventions as well as Makefiles to build the package etc. A. Duret-Lutz Using GNU Autotools May 16, 2010 13 / 162 A. Duret-Lutz Using GNU Autotools May 16, 2010 14 / 162 Package Use Cases The User Point of View Package Use Cases The User Point of View The User Point of View Standard Installation Procedure ~ % tar zxf amhello-1.0.tar.gz 1 Goals ~ % cd amhello-1.0 Portable Packages ~/amhello-1.0 % ./configure Uniform Builds ... ~/amhello-1.0 % make 2 Package Use Cases ... The User Point of View ~/amhello-1.0 % make check The Power User Point of View ... The Packager Point of View ~/amhello-1.0 % su The Maintainer Point of View Password: /home/adl/amhello-1.0 # make install 3 The configure Process ... 4 Why We Need Tools /home/adl/amhello-1.0 # exit ~/amhello-1.0 % make installcheck ... A. Duret-Lutz Using GNU Autotools May 16, 2010 15 / 162 A. Duret-Lutz Using GNU Autotools May 16, 2010 16 / 162 Package Use Cases The User Point of View Package Use Cases The User Point of View Standard Makefile Targets Standard File System Hierarchy ‘make all’ Build programs, libraries, documentation, etc. Directory variable Default value (Same as ‘make’.) prefix /usr/local ‘make install’ Install what needs to be installed. exec-prefix prefix bindir exec-prefix/bin ‘make install-strip’ Same as ‘make install’, then strip debugging libdir exec-prefix/lib symbols. ... ‘make uninstall’ The opposite of ‘make install’. includedir prefix/include ‘make clean’ Erase what has been built (the opposite of ‘make datarootdir prefix/share all’). datadir datarootdir ‘make distclean’ Additionally erase anything ‘./configure’ mandir datarootdir/man created. infodir datarootdir/info ‘make check’ Run the test suite, if any. ... ‘make installcheck’ Check the installed programs or libraries, if supported. ~/amhello-1.0 % ./configure --prefix ~/usr ‘make dist’ Create PACKAGE-VERSION.tar.gz. ~/amhello-1.0 % make ~/amhello-1.0 % make install A. Duret-Lutz Using GNU Autotools May 16, 2010 17 / 162 A. Duret-Lutz Using GNU Autotools May 16, 2010 18 / 162 Package Use Cases The User Point of View Package Use Cases The Power User Point of View Standard Configuration Variables The Power User Point of View ‘./configure’ automatically detects many settings. You can force some of them using configuration variables. 1 Goals Portable Packages CC C compiler command Uniform Builds CFLAGS C compiler flags CXX C++ compiler command 2 Package Use Cases The User Point of View CXXFLAGS C++ compiler flags The Power User Point of View LDFLAGS linker flags The Packager Point of View CPPFLAGS C/C++ preprocessor flags The Maintainer Point of View ... See ‘./configure --help’ for a full list. 3 The configure Process ~/amhello-1.0 % ./configure --prefix ~/usr CC=gcc-3 \ 4 Why We Need Tools CPPFLAGS=-I$HOME/usr/include LDFLAGS=-L$HOME/usr/lib A. Duret-Lutz Using GNU Autotools May 16, 2010 19 / 162 A. Duret-Lutz Using GNU Autotools May 16, 2010 20 / 162 Package Use Cases The Power User Point of View Package Use Cases The Power User Point of View Overriding Default Configuration Settings with config.site Parallel Build Trees (a.k.a. VPATH Builds) Recall that old command ~/amhello-1.0 % ./configure --prefix ~/usr CC=gcc-3 \ Objects files, programs, and libraries are built where configure was run. CPPFLAGS=-I$HOME/usr/include LDFLAGS=-L$HOME/usr/lib ~ % tar zxf ~/amhello-1.0.tar.gz Common configuration settings can be put in prefix/share/ config.site ~ % cd amhello-1.0 ~/amhello-1.0 % cat ~/usr/share/config.site ~/amhello-1.0 % mkdir build && cd build test -z "$CC" && CC=gcc-3 ~/amhello-1.0/build % ../configure test -z "$CPPFLAGS" && CPPFLAGS=-I$HOME/usr/include ~/amhello-1.0/build % make test -z "$LDFLAGS" && LDFLAGS=-L$HOME/usr/lib ... Sources files are in ∼/amhello-1.0/ , Reducing the command to..
Load more

Recommended publications
  • Program Library HOWTO David A
    Program Library HOWTO David A. Wheeler version 1.36, 15 May 2010 This HOWTO for programmers discusses how to create and use program libraries on Linux. This includes static libraries, shared libraries, and dynamically loaded libraries. Table of Contents Introduction...........................................................................................................................3 Static Libraries.......................................................................................................................3 Shared Libraries....................................................................................................................4 Dynamically Loaded (DL) Libraries...............................................................................11 Miscellaneous......................................................................................................................14 More Examples....................................................................................................................18 Other Information Sources...............................................................................................22 Copyright and License.......................................................................................................23 Introduction This HOWTO for programmers discusses how to create and use program libraries on Linux using the GNU toolset. A “program library” is simply a file containing com- piled code (and data) that is to be incorporated later into a program; program libraries allow
    [Show full text]
  • Source Code Trees in the VALLEY of THE
    PROGRAMMING GNOME Source code trees IN THE VALLEY OF THE CODETHORSTEN FISCHER So you’ve just like the one in Listing 1. Not too complex, eh? written yet another Unfortunately, creating a Makefile isn’t always the terrific GNOME best solution, as assumptions on programs program. Great! But locations, path names and others things may not be does it, like so many true in all cases, forcing the user to edit the file in other great programs, order to get it to work properly. lack something in terms of ease of installation? Even the Listing 1: A simple Makefile for a GNOME 1: CC=/usr/bin/gcc best and easiest to use programs 2: CFLAGS=`gnome-config —cflags gnome gnomeui` will cause headaches if you have to 3: LDFLAGS=`gnome-config —libs gnome gnomeui` type in lines like this, 4: OBJ=example.o one.o two.o 5: BINARIES=example With the help of gcc -c sourcee.c gnome-config —libs —cflags 6: gnome gnomeui gnomecanvaspixbuf -o sourcee.o 7: all: $(BINARIES) Automake and Autoconf, 8: you can create easily perhaps repeated for each of the files, and maybe 9: example: $(OBJ) with additional compiler flags too, only to then 10: $(CC) $(LDFLAGS) -o $@ $(OBJ) installed source code demand that everything is linked. And at the end, 11: do you then also have to copy the finished binary 12: .c.o: text trees. Read on to 13: $(CC) $(CFLAGS) -c $< manually into the destination directory? Instead, 14: find out how. wouldn’t you rather have an easy, portable and 15: clean: quick installation process? Well, you can – if you 16: rm -rf $(OBJ) $(BINARIES) know how.
    [Show full text]
  • Red Hat Enterprise Linux 6 Developer Guide
    Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Dave Brolley William Cohen Roland Grunberg Aldy Hernandez Karsten Hopp Jakub Jelinek Developer Guide Jeff Johnston Benjamin Kosnik Aleksander Kurtakov Chris Moller Phil Muldoon Andrew Overholt Charley Wang Kent Sebastian Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Edition 0 Author Dave Brolley [email protected] Author William Cohen [email protected] Author Roland Grunberg [email protected] Author Aldy Hernandez [email protected] Author Karsten Hopp [email protected] Author Jakub Jelinek [email protected] Author Jeff Johnston [email protected] Author Benjamin Kosnik [email protected] Author Aleksander Kurtakov [email protected] Author Chris Moller [email protected] Author Phil Muldoon [email protected] Author Andrew Overholt [email protected] Author Charley Wang [email protected] Author Kent Sebastian [email protected] Editor Don Domingo [email protected] Editor Jacquelynn East [email protected] Copyright © 2010 Red Hat, Inc. and others. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
    [Show full text]
  • GNU Build System
    Maemo Diablo Reference Manual for maemo 4.1 GNU Build System December 22, 2008 Contents 1 GNU Build System 2 1.1 Introduction .............................. 2 1.2 GNU Make and Makefiles ...................... 2 1.2.1 Simplest Real Example .................... 3 1.2.2 Anatomy of Makefile ..................... 6 1.2.3 Default Goal .......................... 7 1.2.4 On Names of Makefiles ................... 7 1.2.5 Questions ........................... 8 1.2.6 Adding Make Goals ..................... 8 1.2.7 Making One Target at a Time ................ 9 1.2.8 PHONY Keyword ...................... 9 1.2.9 Specifying Default Goal ................... 10 1.2.10 Other Common Phony Goals ................ 11 1.2.11 Variables in Makefiles .................... 11 1.2.12 Variable Flavors ........................ 11 1.2.13 Recursive Variables ...................... 12 1.2.14 Simple Variables ....................... 13 1.2.15 Automatic Variables ..................... 14 1.2.16 Integrating with Pkg-Config ................ 15 1.3 GNU Autotools ............................ 16 1.3.1 Brief History of Managing Portability ........... 17 1.3.2 GNU Autoconf ........................ 18 1.3.3 Substitutions ......................... 22 1.3.4 Introducing Automake .................... 24 1.3.5 Checking for Distribution Sanity .............. 29 1.3.6 Cleaning up .......................... 29 1.3.7 Integration with Pkg-Config ................ 30 1 Chapter 1 GNU Build System 1.1 Introduction The following code examples are used in this chapter: simple-make-files • autoconf-automake • 1.2 GNU Make and Makefiles The make program from the GNU project is a powerful tool to aid implementing automation in the software building process. Beside this, it can be used to automate any task that uses files and in which these files are transformed into some other form.
    [Show full text]
  • Studying the Real World Today's Topics
    Studying the real world Today's topics Free and open source software (FOSS) What is it, who uses it, history Making the most of other people's software Learning from, using, and contributing Learning about your own system Using tools to understand software without source Free and open source software Access to source code Free = freedom to use, modify, copy Some potential benefits Can build for different platforms and needs Development driven by community Different perspectives and ideas More people looking at the code for bugs/security issues Structure Volunteers, sponsored by companies Generally anyone can propose ideas and submit code Different structures in charge of what features/code gets in Free and open source software Tons of FOSS out there Nearly everything on myth Desktop applications (Firefox, Chromium, LibreOffice) Programming tools (compilers, libraries, IDEs) Servers (Apache web server, MySQL) Many companies contribute to FOSS Android core Apple Darwin Microsoft .NET A brief history of FOSS 1960s: Software distributed with hardware Source included, users could fix bugs 1970s: Start of software licensing 1974: Software is copyrightable 1975: First license for UNIX sold 1980s: Popularity of closed-source software Software valued independent of hardware Richard Stallman Started the free software movement (1983) The GNU project GNU = GNU's Not Unix An operating system with unix-like interface GNU General Public License Free software: users have access to source, can modify and redistribute Must share modifications under same
    [Show full text]
  • Beginning Portable Shell Scripting from Novice to Professional
    Beginning Portable Shell Scripting From Novice to Professional Peter Seebach 10436fmfinal 1 10/23/08 10:40:24 PM Beginning Portable Shell Scripting: From Novice to Professional Copyright © 2008 by Peter Seebach All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN-13 (pbk): 978-1-4302-1043-6 ISBN-10 (pbk): 1-4302-1043-5 ISBN-13 (electronic): 978-1-4302-1044-3 ISBN-10 (electronic): 1-4302-1044-3 Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Lead Editor: Frank Pohlmann Technical Reviewer: Gary V. Vaughan Editorial Board: Clay Andres, Steve Anglin, Ewan Buckingham, Tony Campbell, Gary Cornell, Jonathan Gennick, Michelle Lowman, Matthew Moodie, Jeffrey Pepper, Frank Pohlmann, Ben Renow-Clarke, Dominic Shakeshaft, Matt Wade, Tom Welsh Project Manager: Richard Dal Porto Copy Editor: Kim Benbow Associate Production Director: Kari Brooks-Copony Production Editor: Katie Stence Compositor: Linda Weidemann, Wolf Creek Press Proofreader: Dan Shaw Indexer: Broccoli Information Management Cover Designer: Kurt Krames Manufacturing Director: Tom Debolski Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013.
    [Show full text]
  • The GNOME Desktop Environment
    The GNOME desktop environment Miguel de Icaza ([email protected]) Instituto de Ciencias Nucleares, UNAM Elliot Lee ([email protected]) Federico Mena ([email protected]) Instituto de Ciencias Nucleares, UNAM Tom Tromey ([email protected]) April 27, 1998 Abstract We present an overview of the free GNU Network Object Model Environment (GNOME). GNOME is a suite of X11 GUI applications that provides joy to users and hackers alike. It has been designed for extensibility and automation by using CORBA and scripting languages throughout the code. GNOME is licensed under the terms of the GNU GPL and the GNU LGPL and has been developed on the Internet by a loosely-coupled team of programmers. 1 Motivation Free operating systems1 are excellent at providing server-class services, and so are often the ideal choice for a server machine. However, the lack of a consistent user interface and of consumer-targeted applications has prevented free operating systems from reaching the vast majority of users — the desktop users. As such, the benefits of free software have only been enjoyed by the technically savvy computer user community. Most users are still locked into proprietary solutions for their desktop environments. By using GNOME, free operating systems will have a complete, user-friendly desktop which will provide users with powerful and easy-to-use graphical applications. Many people have suggested that the cause for the lack of free user-oriented appli- cations is that these do not provide enough excitement to hackers, as opposed to system- level programming. Since most of the GNOME code had to be written by hackers, we kept them happy: the magic recipe here is to design GNOME around an adrenaline response by trying to use exciting models and ideas in the applications.
    [Show full text]
  • Why and How I Use Lilypond Daniel F
    Why and How I Use LilyPond Daniel F. Savarese Version 1.1 Copyright © 2018 Daniel F. Savarese1 even with an academic discount. I never got my money's Introduction worth out of it. At the time I couldn't explain exactly why, but I was never productive using it. In June of 2017, I received an email from someone using my classical guitar transcriptions inquiring about how I Years later, when I started playing piano, I upgraded to use LilyPond2 to typeset (or engrave) music. He was the latest version of Finale and suddenly found it easier dissatisfied with his existing WYSIWYG3 commercial to produce scores using the software. It had nothing to software and was looking for alternatives. He was im- do with new features in the product. After notating eight pressed with the appearance of my transcription of Lá- original piano compositions, I realized that my previous grima and wondered if I would share the source for it difficulties had to do with the idiosyncratic requirements and my other transcriptions. of guitar music that were not well-supported by the soft- ware. Nevertheless, note entry and the overall user inter- I sent the inquirer a lengthy response explaining that I'd face of Finale were tedious. I appreciated how accurate like to share the source for my transcriptions, but that it the MIDI playback could be with respect to dynamics, wouldn't be readily usable by anyone given the rather tempo changes, articulations, and so on. But I had little involved set of support files and programs I've built to need for MIDI output.
    [Show full text]
  • The Glib/GTK+ Development Platform
    The GLib/GTK+ Development Platform A Getting Started Guide Version 0.8 Sébastien Wilmet March 29, 2019 Contents 1 Introduction 3 1.1 License . 3 1.2 Financial Support . 3 1.3 Todo List for this Book and a Quick 2019 Update . 4 1.4 What is GLib and GTK+? . 4 1.5 The GNOME Desktop . 5 1.6 Prerequisites . 6 1.7 Why and When Using the C Language? . 7 1.7.1 Separate the Backend from the Frontend . 7 1.7.2 Other Aspects to Keep in Mind . 8 1.8 Learning Path . 9 1.9 The Development Environment . 10 1.10 Acknowledgments . 10 I GLib, the Core Library 11 2 GLib, the Core Library 12 2.1 Basics . 13 2.1.1 Type Definitions . 13 2.1.2 Frequently Used Macros . 13 2.1.3 Debugging Macros . 14 2.1.4 Memory . 16 2.1.5 String Handling . 18 2.2 Data Structures . 20 2.2.1 Lists . 20 2.2.2 Trees . 24 2.2.3 Hash Tables . 29 2.3 The Main Event Loop . 31 2.4 Other Features . 33 II Object-Oriented Programming in C 35 3 Semi-Object-Oriented Programming in C 37 3.1 Header Example . 37 3.1.1 Project Namespace . 37 3.1.2 Class Namespace . 39 3.1.3 Lowercase, Uppercase or CamelCase? . 39 3.1.4 Include Guard . 39 3.1.5 C++ Support . 39 1 3.1.6 #include . 39 3.1.7 Type Definition . 40 3.1.8 Object Constructor . 40 3.1.9 Object Destructor .
    [Show full text]
  • Using GNU Autotools to Manage a “Minimal Project”
    05AAL Ch 04 9/12/00 10:14 AM Page 21 4 Using GNU Autotools to Manage a “Minimal Project” This chapter describes how to manage a minimal project using the GNU Autotools. For this discussion, a minimal project refers to the smallest possible project that can still illustrate a sufficient number of principles related to using the tools. Studying a smaller project makes it easier to understand the more complex interactions between these tools when larger projects require advanced features. The example project used throughout this chapter is a fictitious command interpreter called ‘foonly’. ‘foonly’ is written in C, but like many interpreters, uses a lexical analyzer and a parser expressed using the lex and yacc tools. The package is developed to adhere to the GNU ‘Makefile’ standard, which is the default behavior for Automake. This project does not use many features of the GNU Autotools. The most note- worthy one is libraries; this package does not produce any libraries of its own, so Libtool does not feature them in this chapter. The more complex projects presented in Chapter 7, “A Small GNU Autotools Project” and Chapter 11, “A Large GNU Autotools Project” illustrate how Libtool participates in the build system. The essence of this chapter is to provide a high-level overview of the user-written files and how they interact. 4.1 User-Provided Input Files The smallest project requires the user to provide only two files. The GNU Autotools generate the remainder of the files needed to build the package are in Section 4.2, “Generated Output Files.”
    [Show full text]
  • The Starlink Build System SSN/78.1 —Abstract I
    SSN/78.1 Starlink Project Starlink System Note 78.1 Norman Gray, Peter W Draper, Mark B Taylor, Steven E Rankin 11 April 2005 Copyright 2004-5, Council for the Central Laboratory of the Research Councils Copyright 2007, Particle Physics and Astronomy Research Council Copyright 2007, Science and Technology Facilities Council The Starlink Build System SSN/78.1 —Abstract i Abstract This document provides an introduction to the Starlink build system. It describes how to use the Starlink versions of the GNU autotools (autoconf, automake and libtool), how to build the software set from a checkout, how to add and configure new components, and acts as a reference manual for the Starlink-specific autoconf macros and Starlink automake features. It does not describe the management of the CVS repository in detail, nor any other source maintainance patterns. It should be read in conjunction with the detailed build instructions in the README file at the top of the source tree (which takes precedence over any instructions in this document, though there should be no major disagreements), and with sun248, which additionally includes platform-specific notes. Copyright 2004-5, Council for the Central Laboratory of the Research Councils Copyright 2007, Particle Physics and Astronomy Research Council Copyright 2007, Science and Technology Facilities Council ii SSN/78.1—Contents Contents 1 Introduction 1 1.1 Quick entry-points . 2 2 Tools 3 2.1 Overview of the Autotools . 3 2.1.1 Autoconf . 5 2.1.2 Automake . 9 2.1.3 Libtool . 13 2.1.4 Autoreconf: why you don’t need to know about aclocal .
    [Show full text]
  • Autotools Tutorial
    Autotools Tutorial Mengke HU ECE Department Drexel University ASPITRG Group Meeting Outline 1 Introduction 2 GNU Coding standards 3 Autoconf 4 Automake 5 Libtools 6 Demonstration The Basics of Autotools 1 The purpose of autotools I It serves the needs of your users (checking platform and libraries; compiling and installing ). I It makes your project incredibly portablefor dierent system platforms. 2 Why should we use autotools: I A lot of free softwares target Linux operating system. I Autotools allow your project to build successfully on future versions or distributions with virtually no changes to the build scripts. The Basics of Autotools 1 The purpose of autotools I It serves the needs of your users (checking platform and libraries; compiling and installing ). I It makes your project incredibly portablefor dierent system platforms. 2 Why should we use autotools: I A lot of free softwares target Linux operating system. I Autotools allow your project to build successfully on future versions or distributions with virtually no changes to the build scripts. The Basics of Autotools 1 3 GNU packages for GNU build system I Autoconf Generate a conguration script for a project I Automake Simplify the process of creating consistent and functional makeles I Libtool Provides an abstraction for the portable creation of shared libraries 2 Basic steps (commends) to build and install software I tar -zxvf package_name-version.tar.gz I cd package_name-version I ./congure I make I sudo make install The Basics of Autotools 1 3 GNU packages for GNU build
    [Show full text]