Re: Package which uses jam (instead make)
On Tue, 28 Oct 2003 16:40:03 -0600, Marcelo E Magallon <mmagallo@debian.org> said:
> 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.
We are talking about Debian policy , are we not? Isn't the
only make in Debian one with these features?
> Arguments regarding the nature of Debian's /usr/bin/make are not
> strong enough, not as a definition for an interface.
Umm, they could be, in the context of Debian, just as dpkg
behaviour serves as an interface to the packaging system. However,
I'll be happy with the definition of Make as provided by POSIX as our
interface spec.
> 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.
As defined by POSIX, if you wish to be pedantic.
> 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.
No more than what POSIX specs say a Makefile is. The POSIX
specs are far more complete, as they define all the variables make
pays attention to, and special targets, and all.
> 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 string)
> * `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 important.
MAKEFLAGS is a defined interface into make, BTW.
manoj
--
The Ruffed Pandanga of Borneo and Rotherham spreads out his feathers
in his courtship dance and imitates Winston Churchill and Tommy Cooper
on one leg. The padanga is dying out because the female padanga
doesn't take it too seriously. Mike Harding, "The Armchair Anarchist's
Almanac"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: