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

Re: Package which uses jam (instead make)

On Tue, Oct 21, 2003 at 05:03:53PM -0500, Manoj Srivastava wrote:

 > 	We just disallow some usage that has been explicitley stated to
 > work.  A gratuitous change, with no compelling use cases, or even a
 > rationale beyond "why not?", hopefully shall not be accepted.

 You keep on referencing to particular features of a specific
 implementation of make.  Since I know you have a gazillion Unix years
 under your belt, that comes as a surprise to me.  For example, you keep
 talking about including makefiles, but that happens to be a GNU make
 feature.  The way VPATH works is also GNU make specific.  The way -n
 works is specific to GNU make, too.  If you want to tie debian/rules to
 GNU make, then modify policy to say so: a GNU Makefile.  Arguments
 regarding the nature of Debian's /usr/bin/make are not strong enough,
 not as a definition for an interface.

 Policy says:

     This file must be an executable makefile, and contains the
     package-specific recipes for compiling the package and building binary
     package(s) from the source.

 "excutable makefile", ok, this is the point of contempt.

     It must start with the line `#!/usr/bin/make -f', so that it can be
     invoked by saying its name rather than invoking `make' explicitly.

 That's just a corollary of the first part.

     Since an interactive `debian/rules' script makes it impossible to
     auto-compile that package and also makes it hard for other people to
     reproduce the same binary package, all _required targets_ MUST be
     non-interactive.  At a minimum, required targets are the ones called
     by `dpkg-buildpackage', namely, _clean_, _binary_, _binary-arch_,
     _binary-indep_, and _build_.  It also follows that any target that
     these targets depend on must also be non-interactive.

 *that* is an interface definition.

     [Policy goes on and defines what these targets do]

     Additional targets may exist in `debian/rules', either as published or
     undocumented interfaces or for the package's internal use.

 Not an interface.

     The architectures we build on and build for are determined by `make'
     variables using the utility `dpkg-architecture'.  You can determine
     the Debian architecture and the GNU style architecture specification
     string for the build machine (the machine type we are building on) as
     well as for the host machine (the machine type we are building for).
     Here is a list of supported `make' variables:
        * `DEB_*_ARCH' (the Debian architecture)
        * `DEB_*_GNU_TYPE' (the GNU style architecture specification
        * `DEB_*_GNU_CPU' (the CPU part of `DEB_*_GNU_TYPE')
        * `DEB_*_GNU_SYSTEM' (the System part of `DEB_*_GNU_TYPE')
     where `*' is either `BUILD' for specification of the build machine or
     `HOST' for specification of the host machine.

 And *that* is also an interface definition.  Calling these make
 variables is just bad wording, these are passed via the environment.
 The fact that GNU make turns these into make variables is not


Reply to: