[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [rules] "config:" -> "build:" -> "stage:" -> "binary:"

On Mon, Jul 19, 1999 at 06:31:08AM -0700, Karl M. Hegbloom wrote:
>  I like to have a "debian/rules config" target distinct from the
>  "build" target.

Definitely. I am always annoyed by rules files that start to clean the
source when I want to continue on an interrupted target (while trying to
make it work on the Hurd). Ideally, we would just continue were we broke,
or, at least, start from a point that is not too time consuming.

Problem is, that most what we do is install files into a directory
hierarchy, and that's something that make was not ideally designed for. Many
targets would look like this:

debian/tmp/usr/bin/foobar: src/foobar
	$(install_file) src/foobar debian/tmp/usr/bin/foobar

Of course, this can be generalized quite easily.
Maybe we can even do:

debian/tmp/usr/bin/foobar: debian/tmp/install-tree/$(gnu-prefix)/bin/tree
	$(install_file) debian/tmp/install-tree/$(gnu-prefix)/bin/tree debian/tmp/usr/bin/foobar

debian/tmp/install-tree/$(gnu-prefix)/bin/tree: stamp-install

Which can also be generalized. You can also collect multiple files in groups.
A lot of ways to go from here, really.

>  We're probably spoiled...  It sounds like
>  "other" versions of `make' are rather lame by comparison to the
>  athletic and brawny GNU rendition.

Yeah :) Also take a look at the VPATH option to build in a subdirectory.
It's very neat to keep multiple builds with different options (even for
different platforms, cross compiled) organized.

>  (I have NOT read all of the `autoconf' or `automake' manuals yet.  I
>  plan to; I promise.  What else should I read that may not be
>  obvious?)

libtool of course.
>  How could this scheme be improved, generalized or extended, as you
>  see it?  Should I develop it further for Debian?  Will anyone else
>  utilize this if I spend the time it will take on it?  (I likely won't 
>  get paid for that time...)

I am interested in nifty make file magic, but I am not sure how much you can
generalize without adding too much overhead. It is definitely worth to be
investigated, and if you take a look at my rules files (which are based on
Manojs), you will see some minor generalization popping up here and there.

Ultimatively, this would lead to some set of files that do some jobs usually
helper tools would do, but are shipped with the package and written using
the standard GNU building tools. I like this.

This means, I would go even further and not only standardize thw target
names, but also exploit make magic inside each target, or even have a very
fine graduation of the target level (down to individual files --- that's how
it should be at least).

>  Is there anything wrong with it?  What?  Detail... and how could that
>  be remedied?

It's quite complex if you have no clue what auto* does and how make works.

>  The $(${pkg}-stage-commands) could easily become sets of debhelper
>  commands or whatever, rather than relying on the upstream makefile's
>  "install" target.  I guess that's obvious.

Yeah, however, maybe we can do even better :)

>  See also: `Recursive Make Considered Harmful'

where can I find this?


`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann              GNU    http://www.gnu.org     master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

Reply to: