Re: [rules] "config:" -> "build:" -> "stage:" -> "binary:"
>>>>> "Marcus" == Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> writes:
>>>>> On Mon, Jul 19, 1999 at 06:31:08AM -0700, Karl M. Hegbloom wrote:
karlheg> I like to have a "debian/rules config" target distinct
karlheg> from the "build" target.
Marcus> Definitely. I am always annoyed by rules files that start
Marcus> to clean the source when I want to continue on an
Marcus> interrupted target (while trying to make it work on the
Marcus> Hurd). Ideally, we would just continue were we broke, or,
Marcus> at least, start from a point that is not too time
Marcus> consuming.
Yes. I've got XEmacs set up so that it ought to config and build
fine on Hurd with no changes. (x-fingers, 10 iterations... then a few
more it'll work this times...) Hurd has `uname -s' and `tr', right?
(of course it does; don't answer that.)
On my box, it'll config as `i386-debian-linux', and if I ran Hurd, it
would be ... (guessing) `i386-debian-hurd'.
It's working now... I can type any one of (only a subset is shown
here):
debian/rules support-bin-config
debian/rules support-bin-build
debian/rules vanilla-build
debian/rules config
debian/rules build
debian/rules html-build
debian/rules clean-build-dirs
debian/rules clean-stamps
...etc.
The config targets are .PHONY, they depend on the config.status
files. The build targets use a stamp, and depend on the config
target having been run first, so a build runs the associated config.
It runs ONLY the required set of configures as well; not the whole
list.
There's a separate (and minimal) configuration for the `support-bin'
package, which is always built first, but only once; it doesn't get
remade for every editor binary you've configured. 8-) I'm proud of
myself for understanding it well enough to make this. I have learned
a lot over the last weeks.
I'd like to show it off... If you've an account on master, look in
~karlheg/src. I `cvs update' every time I sync to the repository.
Marcus> Problem is, that most what we do is install files into a
Marcus> directory hierarchy, and that's something that make was
Marcus> not ideally designed for.
I think that's the problem that `dh_movefiles' is meant to solve.
karlheg> We're probably spoiled... It sounds like "other"
karlheg> versions of `make' are rather lame by comparison to the
karlheg> athletic and brawny GNU rendition.
Marcus> Yeah :) Also take a look at the VPATH option to build in a
Marcus> subdirectory. It's very neat to keep multiple builds with
Marcus> different options (even for different platforms, cross
Marcus> compiled) organized.
Yes. This is how I've got it set up now. The XEmacs `configure'
script has a `--srcdir' switch, and I config in a build directory per
editor-binary I'll ship, with `${srcdir}/configure --with-gnu-make'.
karlheg> (I have NOT read all of the `autoconf' or `automake'
karlheg> manuals yet. I plan to; I promise. What else should I
karlheg> read that may not be obvious?)
Marcus> libtool of course.
I read that once or twice now. I've got to take the time for the
others soon. I've read the `m4' and `cccp' manuals through
twice... and the `make' manual a few times now also. Those others
follow logicly as needed. (Yes, I need to read them yesterday also.)
Marcus> I am interested in nifty make file magic, but I am not
Marcus> sure how much you can generalize without adding too much
Marcus> overhead. It is definitely worth to be investigated, and
Marcus> if you take a look at my rules files (which are based on
Marcus> Manojs), you will see some minor generalization popping up
Marcus> here and there.
I will do that.
Marcus> Ultimatively, this would lead to some set of files that do
Marcus> some jobs usually helper tools would do, but are shipped
Marcus> with the package and written using the standard GNU
Marcus> building tools. I like this.
They should be PART of the packaging and build tools suite, like
`debhelper'.
Marcus> It's quite complex if you have no clue what auto* does and
Marcus> how make works.
Hmmm. If you've no clue how `make' works, how the hell are you going
to create a package anyway?
karlheg> See also: `Recursive Make Considered Harmful'
Marcus> where can I find this?
It's linked to from the XEmacs Beta web page... Here's the URL:
<URL:http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html>
... also ...
<URL:http://www.amath.washington.edu/~lf/tutorials/autoconf/>
<URL:http://www.cygnus.com/~ian/configure/>
Reply to: