svn commit: r217071 - head/lib/bind

[Doug Barton]

On 01/08/2011 14:58, Warner Losh wrote:
> On 01/07/2011 22:13, Doug Barton wrote:
>> I've said before that I like to have the opportunity to pre-commit
>> review patches in this area because at minimum it helps me to be aware
>> of them for potential MFC purposes.
>
> Thanks for the reminder Doug. Hope there's no hard feelings...

Of course not. A waste of time and energy. :)

> I think that bsd.endian.mk is -current only, but there's no reason it
> can't be MFC'd. I'll merge it to 7 and 8 here in a few minutes and let
> you know.

That'd be awesome, thanks. I plan to update BIND in RELENG_7 after the 
release and it would be great to have the bmake stuff consistent between 
branches to the extent possible.

>>> @@ -64,11 +65,7 @@ CFLAGS+= -I${LIB_BIND_DIR}
>>> .endif
>>>
>>> # Use the right version of the atomic.h file from lib/isc
>>> -.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
>>> -ISC_ATOMIC_ARCH= x86_32
>>> -.else
>>> -ISC_ATOMIC_ARCH= ${MACHINE_CPUARCH}
>>> -.endif
>>> +ISC_ATOMIC_ARCH=${MACHINE_CPUARCH:S/i386/x86_32/:S/amd64/x86_32/}
>>
>> This change I am less enthusiastic about. It seems to me that it does
>> the exact same thing, but while admittedly quite a bit more clever
>> than I am capable of I find it less readable. Unless this is doing
>> something more or better than the previous code I will likely revert
>> this.
>
> Damn. I missed that in my pre-commit review, or I'd have mentioned it in
> the commit log. Feel free to revert it if you don't like it, or I'd be
> happy to revert it if you wanted me to clean up my own mess.

Np, I took care of it.

FWIW, I should have been more clear about why I'm more interested in 
keeping the file readable. BIND updates come in 2 main flavors, planned, 
and unplanned. :)  The latter are generally related to security updates, 
and therefore of a more urgent nature. So far we've had very good luck 
with my being available when updates of a more urgent nature are 
required, in addition to good luck in the sense that we haven't had a 
_truly_ urgent BIND update in some years now. Also, the bmake glue for 
BIND isn't all _that_ complex (thanks in large part to des) however ...

My nightmare scenario is that we _do_ end up with a truly urgent BIND 
update, I'm not available for whatever reason, and some poor bastard is 
stuck with the job of having to enter the labyrinth without the benefit 
of the bits of the map that exist only in my head. For this reason I've 
tried to keep the FREEBSD-Update files both up to date and more detailed 
than is usually the case, but I am the last person to believe that I 
have done it all correctly.

This particular bit of arcana (the x86_32 stuff) took me a non-trivial 
amount of time to decipher, so I am particularly interested in having 
the intention of the code to be very clear here.

In any case, thanks again for your help on the endian stuff, and your 
fast response.


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/