[nsd-users] NSD 4.7.0rc1 pre-release

[Florian Obser]

Hi Jeroen,

On 2023-06-01 15:34 +02, Jeroen Koekkoek via nsd-users <nsd-users at lists.nlnetlabs.nl> wrote:
> Hi Florian,
>
> Can you make an exception for the cpuset.h header here? I think that'd
> be easiest short-term. We prefer not to drop the dependency from the
> Makefile and currently lack the time to handle dependencies
> automatically at build time.
>

yes, no worries. Take your time. We can easily carry a diff for
Makefile.in.

Also no worries about breaking the build on OpenBSD, it's not your fault,
this is not something you could have anticipated, we are just being
weird.

> The alternative is that we move it out of the compat directory, but
> then we have to reorder things just for the sake of it not being in the
> compat directory, which seems weird because that's exactly why the
> compat directory is there(?)

Yes, that seems much worse.

>
> Best,
> Jeroen
>
> P.S.
> You may have some experience with handling dependencies automatically
> in OpenBSD. If so, can you point to how OpenBSD handles that? I have
> something for the new zone parser, but I'm not sure it's the
> recommended way of doing things.

No, this is all magic to me. I can give you some pointers but how this
actually works, I have no idea.
The source tree is in /usr/src, nsd lives in /usr/src/usr.sbin/nsd. It
is build in /usr/src/usr.sbin/nsd/obj which is a symlink to
/usr/obj/usr.sbin/nsd

"Native" OpenBSD-base software generates .d files in their obj directory
during build. For example slaacd(8) has a file slaacd.c, during build
obj/slaacd.d is generated and this has the dependencies for slaacd.c.

So the upshot is that the dependencies are not under version control, if
I understand you correctly that's something you'd like to move to as
well.

The magic for all this is probably somewhere in bsd.dep.mk and / or
bsd.prog.mk: https://github.com/openbsd/src/tree/master/share/mk

Hope this helps maybe a little.

Cheers,
Florian

>
>
>
> On Thu, 2023-06-01 at 13:58 +0200, Jeroen Koekkoek via nsd-users wrote:
>> Hi Florian,
>> 
>> The make depend fix was intentional, but we did not intentionally
>> break
>> OpenBSD. Eventually we should probably switch to dynamically
>> determining dependencies(?) We'll have a look before doing the actual
>> release.
>> 
>> Thanks for letting us know.
>> 
>> Best,
>> Jeroen
>> 
>> 
>> On Thu, 2023-06-01 at 10:07 +0200, Florian Obser via nsd-users wrote:
>> > Hi,
>> > 
>> > this might be a case of "I broke it, I get to keep both pieces."
>> > 
>> > Commit 36ae6811f8633c7df32fff40a15e4b05b328c8a9 [1] adds a built
>> > dependency on compat/cpuset.h to every .o file, even if that is not
>> > needed on the OS one tries to build.
>> > 
>> > In OpenBSD we do not carry the compat/ folder at all because we
>> > don't
>> > want to accidentally pick up alternative implementations over our
>> > own
>> > libc. Having a dependency on compat/cpuset.h breaks the build
>> > thusly:
>> > 
>> > make: don't know how to make /usr/src/usr.sbin/nsd/compat/cpuset.h
>> > (prerequisite of: answer.o)
>> > 
>> > HAVE_CPUSET_T guards the cpu affinity feature in nsd.c, server.c
>> > and
>> > util.c just fine. So if the OS does not support cpu affinity
>> > compat/cpuset.h is not needed at all.
>> > 
>> > Was that "make depend" change intentional or was that picked up
>> > because
>> > make depend was run on a system with cpu affinity and then
>> > committed?
>> > 
>> > I'm fine with an answer along the lines of "this is OpenBSD's
>> > problem". I just want to make sure.
>> > 
>> > Thanks,
>> > Florian
>> > 
>> > [1]
>> > https://github.com/NLnetLabs/nsd/commit/36ae6811f8633c7df32fff40a15e4b05b328c8a9
>> > 
>> 
>> _______________________________________________
>> nsd-users mailing list
>> nsd-users at lists.nlnetlabs.nl
>> https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users
>
> _______________________________________________
> nsd-users mailing list
> nsd-users at lists.nlnetlabs.nl
> https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users

-- 
In my defence, I have been left unsupervised.