Bug#218893: Autodetecting existence of build-arch target

Hello,
I have recently asked Scott James Remnant[1] on IRC for comments on this
problem and the proposed solution (#229357), to add Build-Options:
build-arch' to debian/control if the package supported this target.

I gathered that he was not in favour of it and prompted for alternate
solutions he suggested

make -f debian/rules -pn | grep '^binary-arch:'

This is different to the solution dpkg-buildpackage tried and dropped
some time ago:

| dpkg (1.10.15) unstable; urgency=low
[...]
| * Back out debian/rules build-arch detection. It is *not* possible *at
| all* to detect available targets in a rules file. Period.
[...]
| dpkg (1.10.11) unstable; urgency=low
[...]
| * Patch dpkg-buildpackage to call debian/rules -qn build-arch, and if
| it's available, modify -B handling appropriately. If build-arch is not
| available, then when -B was called, do *not* pass -B on to
| dpkg-checkbuilddeps. Closes: #203097

Of course all the examples I tried work with both variants. debian-dpkg
does not yield any reference to example that failed during the short
interval build-arch detection was tried.
cu andreas
[1] cced to make sure I do not misrepresent him.
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"


--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST RemoveThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster RemoveThis @lists.debian.org

On Wed, May 05, 2004 at 11:46:20AM +0200, Andreas Metzler wrote:
> Hello,
> I have recently asked Scott James Remnant[1] on IRC for comments on this
> problem and the proposed solution (#229357), to add Build-Options:
> build-arch' to debian/control if the package supported this target.
>
> I gathered that he was not in favour of it and prompted for alternate
> solutions he suggested
>
> make -f debian/rules -pn | grep '^binary-arch:'

I hope you meant

make -f debian/rules -pn | grep '^build-arch:'

since binary-arch is mandated by policy already.

I am not sure make -n (--dry-run) is safe though.
We could imagine make --dry-run to take an large amount of time
or actively modify the environment by use of $(shell ) construct.

Thea apparent benefit of this technique is that it will not require
packages to be modified to take advantage of it.

But in practice this is not true:
Only packages that currently FTBFS would work unmodified. All others
will need to be modified to resplit Build-Depends-Indep from
Build-Depends before build-arch to be really useful.
And that will not fix buildd either: the implied assumption that
Build-Depends-Indep imply build-arch is not warranted by policy.

I would like to recall we have had a long discussion on debian-policy
about the whole issue. I proposed 4 solutions and we finally more or
less settled on the Build-Options: build-arch proposal. At least this
option was amenable to Adam Heath. Following his request I wrote a patch
to dpkg-buildpackage.

I am afraid that implementing 'make -f debian/rules -pn' instead will
lead to the same problems we tried carefully to avoid in this
discussion and will finally delay the issue even more.

1) That assume debian/rules is a Makefile and there is a long standing
flamewar on that topic. One of the dpkg maintainer disagree.

2) buildd need to know whether it should install Build-Depends-Indep.
Assuming Build-Depends-Indep split imply build-arch exist is not correct
with current policy. This mean it must know whether dpkg-buildpackage
will call build or build-arch. A control field is a clean way to do
that.

3) Build-Options scale to others feature we might want to introduce.

Cheers,
--
Bill. <ballombe.TakeThisOut@debian.org>

Imagine a large red swirl here.


--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org