with the cvs history? trying to help INDEX builds.

[Matthew Seaman]

On 20/01/2012 13:14, Chris Rees wrote:
> On 20 Jan 2012 13:06, "Matthew Seaman" <m.seaman at infracaninophile.co.uk>
> wrote:
>>
>> On 20/01/2012 12:53, Chris Rees wrote:
>>> On 20 Jan 2012 10:20, "Matthew Seaman" <m.seaman at infracaninophile.co.uk>
>>> wrote:
>>>>
>>>> On 20/01/2012 09:18, Chris Rees wrote:
>>>>> On 19 Jan 2012 08:58, "Matthew Seaman" <
> m.seaman at infracaninophile.co.uk>
>>>>> wrote:
>>>>
>>>>>> On 19/01/2012 01:31, Michael Scheidell wrote:
>>>>
>>>>>>> anyway, worth the cycles?
>>>>>>> take out -.include <bsd.port.pre.mk>; -.if ${ARCH} == "sparc64"
>>>>>>> -BROKEN=        Does not install on sparc64
>>>>>>> -.endif
>>>>>>> and replace it with NOT_FOR_ARCHS=    sparc64 ?
>>>>
>>>>>> I'd say worth it to standardize on NOT_FOR_ARCHS / ONLY_FOR_ARCHS to
>>>>>> handle this sort of thing.  By my calculations there are 28 ports
> that
>>>>>> set 'BROKEN' because of architecture incompatibility on my amd64
>>>>>> system[*], whereas there are 904 ports that set either ONLY_FOR_ARCHS
>>> or
>>>>>> NOT_FOR_ARCHS.
>>>>
>>>>> No, it's not worth it :)
>>>>>
>>>>> This means we won't be able to differentiate between BROKEN and
> IGNORE.
>>>>
>>>> Not even if people make use of the {NOT,ONLY}_FOR_ARCHS_REASON or
>>>> {NOT,ONLY}_FOR_ARCHS_REASON_${ARCH} variables?
>>>>
>>>> Actually I take your point, that it should be possible to distinguish
>>>> between ports that permanently won't work on some architectures by
>>>> design, and ports that temporarily don't work because of mistakes or
>>>> broken dependencies or so forth, and that are expected to be fixed
>>>> sooner rather than later.  Unfortunately those two cases are already
>>>> pretty confused.  For instance (arbitrarily picking out a few grep
> hits):
>>>>
>>>> ./audio/amarok-kde4/Makefile:NOT_FOR_ARCHS_REASON_sparc64=
>>>  "GCC-related
>>>> build error"
>>>> ./audio/openal/Makefile:NOT_FOR_ARCHS_REASON_ia64=      does not
> compile
>>>> ./biology/migrate/Makefile:ONLY_FOR_ARCHS_REASON=       Does not
> compile
>>>>
>>>> Where 'does not compile' or 'fails to install' are similarly the most
>>>> popular reasons given for arch-related brokenness using the BROKEN
>>>> variable.  Given the banal and uninformative nature of such reasons,
>>>> there's no easy way to tell if this is a temporary condition or not.
>>>>
>>>> Hmm... Perhaps if there was a BROKEN_FOR_ARCH{,_REASON{,${ARCH}}} set
> of
>>>> variables documented alongside the other ..FOR_ARCH variables?
>>>
>>> Occasionally someone runs an exp- for sparc64 (lol) etc.
>>>
>>> They use TRYBROKEN to test packages marked BROKEN, but ONLY_FOR_ARCHS
> sets
>>> IGNORE.
>>>
>>> Ports marked this way (incorrectly) will never be tested, and thus never
>>> marked fixed.
>>>
>>
>> Yes, I understand thae distinction between BROKEN and IGNORE, thank you
>> very much.  So the BROKEN_FOR_ARCH variable family should ultimately set
>> BROKEN rather than IGNORE.  Obviously.
>>
> 
> Sorry, missed that bit.
> 
> Thing is... adding this change to bsd.port.mk will actually mean that
> instead of each BROKEN Makefile testing for it, *every* port's Makefile
> then tests for it.

But that argument applies equally to the {NOT,ONLY}_FOR_ARCHS variables,
which I'd guess are two amongst dozens of other variables that get
manipulated in some form or other every time you invoke 'make' in any
port directory.  Is that really going to cause a significant extra load?

Actually, going back to the original question -- if this means not
having to .include <bsd.port.pre.mk> in a reasonable number of cases,
then it might even be a win overall when generating an index.  (At a
guess.  Have to do some experiments to confirm that.)

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
JID: matthew at infracaninophile.co.uk               Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120120/9fea9471/signature.pgp