1
2
3
4
5

#!/bin/bash
 
sudo aptitude markauto $(apt-cache showsrc "$1" \
    | grep Build-Depends \
    | perl -p -e 's/(?:[\[(].+?[\])]|Build-Depends:|,|\|)//g')

It can be invoked as follows (assuming it is in your PATH):

build-dep-rm openoffice.org

I want to emphasize that I did not invent this method, the credits should have to go to the persons that posted the solution on Launchpad.

In this installment a skeleton setup for handling libraries using Libtool will be presented. At the end the methods to link against the static or dynamic libraries will be shown. The created library will be a very trivial one but the created skeleton should be enough to expand on this.

Necessary files and directories

Libraries by convention reside in a different directory, namely ‘lib’ in your project root directory. This section will create the necessary structure and files.

Create the ‘lib’-directory

From the project root directory issue the following command:

mkdir lib

Create lib/print_hello.h

In the newly created ‘lib’-directory add a file ‘print_hello.h’ with the following contents:

#ifndef __PRINT_HELLO_H__
#define __PRINT_HELLO_H__
 
void print_hello(const char* addressee);
 
#endif /* __PRINT_HELLO_H__ */

Create lib/print_hello.c

Of course an implementation is needed. Add the file ‘print_hello.c’ with the following contents in the ‘lib’-directory:

#include <stdio.h>
#include "print_hello.h"
 
void print_hello(const char* addressee)
{
    printf("Hello, %s!\n", addressee);
}

Create lib/Makefile.am

The Automake file ‘Makefile.am’ in the ‘lib’-directory has the contents as shown below. It will be responsible for a library named ‘libfoobar’ against which the application can later link statically or dynamically:

1
2
3
4
5
6
7
8
9
10
11

# NH: Define the libraries that are to be build
lib_LTLIBRARIES = libfoobar.la
 
# NH: Compile flags for the library
libfoobar_la_CFLAGS = -Wall -Werror -pedantic -Wextra
 
# NH: The sources that make up the library.
# NH: Do not forget the header files!
libfoobar_la_SOURCES = print_hello.c print_hello.h
 
MAINTAINERCLEANFILES = Makefile.in

Change existing files

Several files need to be adjusted to allow the build environment to create the library and to let the application make use of it.

Adjust configure.ac

Just below the macro ‘AC_CONFIG_MACRO_DIR’ add the following macro:

32
33
34

# NH: Initialize Libtool providing us with the possibility to build
# NH: (shared) libraries more easily.
LT_INIT

The parameters to ‘AC_CONFIG_FILES’ should be extended with the location of the ‘Makefile’ in the ‘lib’-directory:

53
54
55
56

AC_CONFIG_FILES([
    Makefile
    lib/Makefile
    src/Makefile])

Adjust Makefile.am

The top ‘Makefile.am’ should let Automake know that a ‘Makefile.am’ is to be found in the ‘lib’-directory. Adjust the value for ‘SUBDIRS’ as follows:

6

SUBDIRS = lib src

Libtool leaves some cruft which should be removable when calling the ‘maintainer-clean’ target. So adjust the values

12
13
14
15
16
17
18
19
20

MAINTAINERCLEANFILES = \
    aclocal.m4 \
    configure \
    Makefile.in \
    m4/libtool.m4 \
    m4/lt~obsolete.m4 \
    m4/ltoptions.m4 \
    m4/ltsugar.m4 \
    m4/ltversion.m4

Adjust src/Makefile.am

The ‘Makefile.am’ in the ‘src’-directory should have the following contents:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# NH: Define the program to be build
bin_PROGRAMS = foobar
 
# NH: Define the sources that make up the program
foobar_SOURCES = main.c
 
# NH: Add the include path to the library to the preprocessor flags
foobar_CPPFLAGS = -I$(top_srcdir)/lib
 
# NH: Set the compile flags
foobar_CFLAGS  = -Wall -Werror -pedantic -Wextra
 
# NH: Let the linker know where taht we want to link to libfoobar
foobar_LDADD = $(top_srcdir)/lib/libfoobar.la
 
MAINTAINERCLEANFILES = Makefile.in

Adjust src/main.c

The ‘main.c’ file in the ‘src’-directory should look as follows now if we want to use the new library and the function it provides:

1
2
3
4
5
6
7
8
9
10
11

#include "print_hello.h"
 
int main(int argc, char* argv[])
{
	(void) argc;
	(void) argv;
 
	print_hello("World");
 
	return 0;
}

Rebuild and test the current setup

autoreconf -ivf

The following steps will define the default link behavior, which is most likely to use the dynamic link-library:

./configure && make

If a statically linked application is required just disable dynamic linking:

./configure --disable-shared && make

Run:

src/foobar

This finishes this second installment. This is all there is to build and use libraries with the GNU Autotools.

• They get disorganized
• They are hard to keep up-to-date
• They are not always available
• It is difficult to transfer the knowledge contained in them to another person

So therefore I decided to do what I always do to solve these issues: I publish the knowledge on a subject that I obtained so far on my homepage. It will be series of installments, each building on the knowledge from the previous installments. In this first installment a trivial ‘Hello, World!’ project will be created. Later installments will provide information on:

• Creating and using libraries
• Creating and using unit tests
• Creating documentation with Doxygen
• Creating documentation with Docbook

But more subjects might be added in the future. It is also most likely that new insights will be added to already published parts and I will try to indicate the new additions as good as possible.

Since I consider these my personal notes they are not a replacement for the full GNU Autotools documentation and other resources. For more in-depth information the following on- and off-line resources are recommended:

• The Autotools tutorial by Alexandre Duret-Lutz. It not only provides a nice tutorial in the form of a presentation but also provides a lot of links to other resources.
• Autotools: a practitioner’s guide to Autoconf, Automake and Libtool by John Calcote. based on these he published a book with the same name. Highly recommended.
• One of the first books published on the GNU Autotools was the so-called ‘Goat Book‘ by Gary V. Vaughan, Ben Elliston, Tom Tromey and Ian Lance Taylor. It has since been published on-line and, although it is not the most accessible text on the subject, it still contains a lot of good information.

Although I consider these my notes, complete with rough-edges and warts and all, and by no means a complete tutorial on the subject I do still appreciate any remarks or comments. Nowhere will a setup guide for the used tools be given. These differ to much from system to system and with the use of Google resources with better information than I can provide should be available.

Setup project structure

Go to the directory where you want to store your project, create the project directory and change your current working directory to the newly created one:

cd ~/projects; mkdir foobar; cd !$

Create the source-directory and create the main.c (or .cpp) file there:

mkdir src; cd src; touch main.c; cd ..

Create the directories to hold the M4 macros:

mkdir m4

Create initial files

These files act as placeholders for later development. However by creating them the Autotools tool-chain can be gradually created and tested.

The explanation of the entries are added as comments to the files themselves and are marked as such with ‘NH:’ on each line. This provides the possibility to just remove these comments without removing other possibly more useful comments.

Once entries are commented with ‘NH:’ in a file they will not be commented again in following similar files. So if you miss an explaining comment then please search for it in the sections previous to the one you are reading.

Create src/main.c

Create a ‘main.c’ file in the ‘src’-directory with the following contents:

/* This is just the normal standard ‘Hello, World!’ source code. */
#include 
 
int main(int argc, char* argv[])
{
    (void) argc;
    (void) argv;
 
    printf(“Hello, World!\n”);
    return 0;
}

Create configure.ac

In the project’s root-directory create a ‘configure.ac’ file with the following contents:

# NH: Make sure that a specific minimum version of Autoconf is available
AC_PREREQ([2.67])
 
# NH: Initialize Autoconf. Specify the package's name, version
# NH: and whom to contact for bug-reports
AC_INIT([foobar], [1.0.0], [foobar@heirbaut.nl])
 
# NH: Define the place where to find the auxiliary build files like
# NH: install-sh, config.sub, config.guess etc.
# NH: I do not like them cluttering up my root directory, so I
# NH: put them in a directory named 'config'
AC_CONFIG_AUX_DIR([config])
 
# NH: Initialize Automake. The given options will be passed to
# NH: Automake:
# NH:   -Wall: Turn on all warnings
# NH:   -Werror: Treat Automake warnings as errors
# NH:   -Woverride: Warn on user redefinitions of Automake rules
# NH:                              or variables
# NH:   foreign: Do not build a GNU-standards compliant package. A
# NH:                        GNU package would require more files and setup.
AM_INIT_AUTOMAKE([-Wall -Werror -Woverride foreign])
 
# NH: Define a unique source file that is always available. This
# NH: macro expands to a sanity check to ensure the for example
# NH: not the wrong directory is given with the --srcdir option
AC_CONFIG_SRCDIR([src/main.c])
 
# NH: Let the system know where the local M4 macros are located.
AC_CONFIG_MACRO_DIR([m4])
 
# Checks for programs.
# NH: Find the correct compiler
AC_PROG_CC
 
# Checks for libraries.
 
# Checks for header files.
 
# Checks for typedefs, structures, and compiler characteristics.
 
# Checks for library functions.
 
# Miscellaneous
#NH: Make known to the Makefiles where the config dir is.
AC_SUBST(ac_aux_dir)
 
# NH: Define the files to generate
AC_CONFIG_FILES([
    Makefile
    src/Makefile])
 
# NH: Generate the defined files.
AC_OUTPUT

Create Makefile.am

In the project-root create a ‘Makefile.am’ with the following contents:

# NH: Notify aclocal to scan for the m4 directory for M4 files.
ACLOCAL_AMFLAGS = -I m4
 
# NH: Indicate in which directories relative to this one other
# NH: Makefile.am files are to be found.
SUBDIRS = src
 
# NH: All files added to this one will also be deleted when the
# NH: 'maintainer-clean' target is specified with 'make'. If not
# NH: specified here not all files created by the toolchain will
# NH: be deleted.
MAINTAINERCLEANFILES = \
    aclocal.m4 \
    configure \
    Makefile.in
 
# NH: 'maintainer-clean-local' is a standard target within Autotools
# NH: that can be used as a hook to trigger further actions when the
# NH: 'maintainer-clean' target is called. In this case it makes sure
# NH: that directory specified by 'AC_CONFIG_AUX_DIR' in configure.ac
# NH: is deleted.
maintainer-clean-local:
	-rm -rf $(ac_aux_dir)
 
# NH: A personal target that I use to edit all project files at once
# NH: using my favorite editor.
edit:
	find . \
		-name '*.h' -o \
		-name '*.c' -o \
		-name '*.cpp' -o \
		-name Makefile.am -o \
		-name configure.ac | \
	xargs gvim

Create src/Makefile.am

In the project’s ‘src’-directory create a ‘Makefile.am’:

# NH: Define the program to be build
bin_PROGRAMS = foobar
 
# NH: Define the sources that make up the program
foobar_SOURCES = main.c
 
# NH: Set the compile flags
foobar_CFLAGS  = -Wall -Werror -pedantic -Wextra
 
MAINTAINERCLEANFILES = Makefile.in

Bootstrap and test the current setup

All initial files need to be given to the various tool-chain applications (aclocal, autoconf and automake), to generate the ‘configure’ script. This script will create ‘config.h’ and the ‘Makefile’s’. Here is how:

autoreconf -ivf

Now the application can be build:

./configure && make

And tested:

src/foobar

This finishes this first installment. Have fun experimenting!

Updates

2010-12-26

Added the macro ‘AC_CONFIG_MACRO_DIR’ to ‘configure.ac.

-- Omni completion (^O^N^P) Pattern not found

After a while I found out that the used complete-function ‘omnifunc’ was set to:

ccomplete#Complete

This is the generic completion function for C-based programs and does not work well with C++-programs. To fix this add the following line to .vimrc:

au BufNewFile,BufRead,BufEnter *.cpp,*.hpp set omnifunc=omni#cpp#complete#Main

This should leave you with a working OmniCppComplete plug-in managed from the vim-scripts repositories at GitHub.

• Bovendien is opensourcesoftware minder populair dan Windows, zodat vandalen het vooralsnog grotendeels met rust laten…Echt waar? Zouden de onderzoekers wel eens een gekeken hebben naar de echte getallen over Open Source? Apache, iemand? PHP? Java? Bovendien gaat het begrip Open Source veel verder dan alleen het operating system, dus het begint al door appels met peren te vergelijken.

• Zoals je waarschijnlijk wel weet, bestaan er honderden Linux-distributies. De toon lijkt nu wel gezet. Feitelijk en tendentieus.

• De basis van die bundel is de linux kernel: die is hetzelfde voor iedereen. Daarbovenop komt het GNU/Linux platform. Kennis van GNU/Linux ontbreekt blijkbaar bij de auteurs: de kernel is niet bij alle distributies hetzelfde. Ze zijn wel gebaseerd op dezelfde broncode, maar vaak aangepast door de maker van de distributie om zo goed mogelijk aan te sluiten bij de doelgroep van de distributie. De opmerking dat het GNU/Linux platform erbovenop komt is natuurlijk onzin. Het heet GNU/Linux omdat een Linux kernel wordt gecombineerd met de GNU applicaties om een operating system te maken. Richard Stallman zal het niet waarderen dat de GNU applicaties GNU/Linux worden genoemd.

• Als je een Windows-gebaseerde server draait, dan moet je die clientlicenties betalen ongeacht het gebruikte desktopsysteem. Wat een raar argument. Als het een homogene Windows-omgeving is, moet er ook voor zowel de client als de server licenties betaald worden. Bij Linux ben je in ieder geval nog het bedrag voor het desktop operating system kwijt.

• Zo blijkt het erg moeilijk om computers van A-merken te kopen zonder Windows erop. Dat is alleen Microsoft aan te rekenen. Dus feitelijk weer juist, maar het lijkt mij eerder een argument om zo snel mogelijk te stoppen met het gebruik van Microsoft producten, want daardoor wordt blijkbaar de prijs van apparatuur onnodig opgejaagd.

Afgezien van de hierboven beschreven argumenten, staat het artikel bovendien vol met taal- en/of typefouten. Ik ben benieuwd naar het vervolg op dit artikel op 12 april, maar gezien de argumentaties in dit artikel vrees ik het ergste.

Cannot modify header information - headers already sent by

Then you probably injected some whitespace somewhere in your output. The easiest way to avoid that is by not using the PHP closing tag ‘?>‘ at the end of PHP source files. Some people are against that but if I look into the sources for Yii and read the Zend Framework Programmer’s Reference Guide then it is obviously a well established method of avoiding the mentioned error.

<?php
 
class SiteController extends Controller
{
    /**
     * @return array action filters
     */
    public function filters()
    {
        return array(
            'accessControl', // perform access control for CRUD operations
        );
    }
 
    /**
     * Specifies the access control rules.
     * This method is used by the 'accessControl' filter.
     * @return array access control rules
     */
    public function accessRules()
    {
        return array(
            array('allow',  // allow all users to perform 'login'
                'actions'=>array('login'),
                'users'=>array('*'),
            ),
            array('allow', // allow authenticated user to perform any action
                'users'=>array('@'),
            ),
            array('deny',  // deny all users
                'users'=>array('*'),
            ),
        );
    }
 
    // The rest of the SiteController implementation
 
}
 
?>

I am not sure if this is the best possible solution, but since it is simple and elegant I am inclined to think it is.

But while I was enjoying a presentation on Identi.ca at FOSDEM I all of a sudden had the idea that now would be a good time to start again. So I joined Identi.ca and added this entry to this site. Expect more in the very near future. Being on-line feels like fun again.

Should I be proud or crawl back in the basement?

Let’s see with the second test offered at that site:

Ok, back into the basement, I have to dust of some comic books…

Fortunately someone wrote a page where, as far as I know, all color schemes are shown and downloadable. Even my two favorite ones: here and here. The only minor annoyance is the fact that the color schemes are not all alphabetically ordered.

I know, I know, old news, but I still like to use this web site as my own long term memory…