Re: Possible framework for `debmake replacement'

[Martin Alonso Soto Jacome <masoto@uniandes.edu.co>]

> All I mean is that in order to know what the Makefile installs, you
> have to actually run the Makefile.

I completely agree with you in this.  Maybe my previous explanation
wasn't clear enough, so I'll try to improve it this time.

IMO, trying to read the Makefile for automatically figuring out what
it installs is not the best idea (it would require artificial
intelligence, or something of the kind).  So it seems to me that the
only way to go is to allow for people to arrange debian/rules in such
a way that the code testing for installed files is executed after
running the Makefile itself.  This is more or less what debmake does
today, but with the difference that debmake packages depend on debstd
compile correctly, while packages generated by the new tool would be
completely self-contained.

This could be done with m4 macros that expand into certain pieces of
testing code.  For example, there could be a macro for finding and
compressing manual pages, another one for finding and striping
executables, another one to check and correct symbolic links, and so
on.  Now, what the package maintainer would have to do is create a
file, say debian/rules.in which would basically have the structure of
a normal debian/rules, but would include some macro invocations in
particular places.  For example:

binary-arch: checkroot build
	# Runs the installation.
        $(checkdir)
        -rm -rf debian/tmp
        install -d debian/tmp/usr/{bin,sbin}
	make install prefix=`pwd`/debian/tmp

	# Installs documentation.
	AD_INSTALL_DOC( readme.txt, release-notes.txt )

	# Installs standard docs.
	AD_INSTALL_STD_DOC

	# Strip binaries
	AD_STRIP

	# Fix symlinks
	AD_CHECK_SYMLINKS

	# Make the package 
        dpkg-gencontrol
        chown -R root.root debian/tmp
        chmod -R go=rX debian/tmp
        dpkg --build debian/tmp ..
	
The code for doing the checks would be put by m4 in place of the macro
invocations, so it would be run after the Makefile.  However, it can
be written beforehand without trouble.

What do you think?

M. S.


------------
Martin A. Soto J.                           Profesor
Departamento de Ingenieria de Sistemas y Computacion
Universidad de los Andes      masoto@uniandes.edu.co