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

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

 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

 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

 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

    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:


			     ... also ...



Reply to: