Re: presumable last policy change before releasing Squeeze?
On Mon, 5 Oct 2009, Bernhard R. Link wrote:
Note that you might do without a patch. make is build for cases like
that in mind, so replacing variables in a makefile you do not like just
needs those variables as command line arguments.
so just changing debian/rules to
$(MAKE) CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" LIBS="$(LIBS)"
might do the same without needing to edit the Makefile.
Those compiler options must be in the upstream Makefile(s). There isn't
anything in the upstream release that would pass those compiler options to
the Makefile from the outside. The upstream release is meant to be
self-sufficient for any SUSv2 platform. So any port has to move those
flags if they aren't in the right place for that port as shipped in
Looking at the definition of those variables in your debian/rules also
looks very complicated. Unless there is a reason to rerun this script
all the time?
There is none, but lbzip2 consists of only 5 .c files, so it's not very
wasteful when building.
Otherwise e.g. some
LDFLAGS := $(shell ./lfs.sh LDFLAGS)
might be a bit more efficient and easier to look at...
:= would be certainly easier on the eyes, but it's not supported by SUSv2
make , so := is avoided in the upstream version. I could use := in
debian/rules, but the examples in the Policy  and other stuff I looked
at originally IIRC don't use it, so I'm not convinced it wouldn't have
side-effects. ("Try it out and see if it works" is not good enough :))