Re: presumable last policy change before releasing Squeeze?
* ERSEK Laszlo <lacos@caesar.elte.hu> [091006 04:48]:
> 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
> upstream.
Perhaps I am misunderstanding something here.
Let's see if I got anything wrong:
1) we are speaking about lbzip2, aren't we?
2) that one has exactly one Makefile in the upstream tarball not
calling any submakes in any strange way.
3) you patch that Makefile to no longer set CC CFLAGS LDFLAGS and LIBS
What I am saying is that this patch is unnecessary. you can do that
totally in debian/rules by placing those variables in the make
invocation within your build-stamp target.
>> 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 [0], so := is avoided in the upstream version. I could use := in
> debian/rules, but the examples in the Policy [1] 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 :))
= and := are exactly the same, except that := is evaluated once and then
stored, whereas = is evaluated later. If I were you I would be more
worried that all the parsing and reparsing (which causes the need for
the extra $) has some side effects.
Hochachtungsvoll,
Bernhard R. Link
--
"Never contain programs so few bugs, as when no debugging tools are available!"
Niklaus Wirth
Reply to: