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

Re: Package which uses jam (instead make)


 > debian/rules should be portable enough to work with any
 > implementation of make [1]. That's the interface.

 As an interface that's bad.  An interface with what?  I assumed
 everyone understood we are talking about an interface with the build
 system (dpkg-buildpackage and everything under that).  That Manoj
 wants to be able to type 'make -n -f debian/rules something FOO=bar' is
 just abusing his knowlegde of the specific implementation.

 > If I have an implmentation that I know supports include files, I
 > should be able to ask *my* implementation of make to include
 > *somebody else's* debian/rules and expect it to work.

 As long as the implementation is defined in that way, yes (i.e. change
 policy to read "GNU Makefile" instead of "Makefile"), otherwise, no.
 How should I, the author of the debian/rules file to be included, know
 that you intend to do that and that this should work if the
 specification only says that this file must be a "makefile"?

 > [1] Perhaps. The dh_make templates for debian/rules actually do
 >     contain gnuisms, so this is not true in practise.

 You mean like this:

ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
        CFLAGS += -O0
        CFLAGS += -O2

 that's not POSIX make.

        $(MAKE) install DESTDIR=$(CURDIR)/debian/$(pmodules)

 $(CURDIR) isn't either.

 If you want portable makefiles, use a portable make _program_.  And for
 that you need to specify which one is required.  IOW, modify policy.

 > >  "excutable makefile", ok, this is the point of contempt.
 > If we're actually regarding each other's views with contempt, then
 > there's not much point in continuing the discussion, I think.

 Ah, sorry, "contend", even if sometimes it looks like contempt :-(

 > >  And *that* is also an interface definition.  Calling these make
 > >  variables is just bad wording, these are passed via the
 > >  environment.
 > Actually, makefile variables can also be passed on the command line,
 > at least with the implementations of make that I'm familiar with.

 But that feature is not used, AFAICS.  dpkg-whatever passes these
 values on the environment, not on the command line.

 > >  The fact that GNU make turns these into make variables is not
 > >  important.
 > It *is* a part of the interface that I can compile my own patched
 > version of make that hardcodes one or more of these variables, and
 > expect things to work when I ask it to interpret debian/rules.

 No, that's not interface, that's implementation.  With makefiles it's
 just a nice and handy feature.  If you were to make your debian/rules
 file a perl script, you'd have to explicitely access %ENV to get those
 values, because *that's* the interface.  You could equally patch perl
 to fiddle with the environment.


Reply to: