Hi Matthias, Thanks for taking the time to reply and even selectively apply my patches!
On Sun, Apr 27, 2014 at 10:28:58PM +0200, Matthias Klose wrote: > Am 25.04.2014 21:17, schrieb Helmut Grohne: > > * Some places use "usr" and others use "$(PF)". Thus changing the PF > > variable does no longer work. The patch restores $(PF) to working > > order. If that variable is no longer useful, then maybe using its > > only working value "usr" in all places is a better solution. I believe that you missed the hunk conditional to GFDL_INVARIANT_FREE, but applied all the others. Is that intentional? > > * If $(TARGET) is non-empty, it contains what should be called > > DEB_TARGET_GNU_TYPE. I therefore introduce this new variable for both > > native and cross builds. All places that really want to know the > > target gnu type now use DEB_TARGET_GNU_TYPE. There are two kinds of > > variables being converted: > > + TARGET when it is not used to branch on being non-empty > > + DEB_HOST_GNU_TYPE when it DEB_TARGET_GNU_TYPE was meant > > the use of target for the native build doesn't make sense. just try to > configure > the native build with --target=. so this should not be used outside the rules > to > build the cross package. Clearly binutils (like gcc) does have target-specific elements. Therefore, I cannot follow your argument as to why referring to a target architecture would not make sense. Simply put, when doing a native build DEB_BUILD_GNU_TYPE, DEB_HOST_GNU_TYPE and DEB_TARGET_GNU_TYPE all have the very same value, so no breakage can be caused there by the proposed changes. The benefit of using different variables is to make the intention explicit. Without this differentiation further modifications become unnecessarily hard and/or lead to overly complex branching. I completely fail to see a scenario in which I either would want to configure a build with --target=. or where my patch would be introducing such a scenario. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
