Re: Compiling fails on MacOS

[Christoph Badura <bad%bsd.de@localhost>]

On Fri, Nov 01, 2024 at 10:49:42PM +0700, Robert Elz wrote:
>     Date:        Fri, 1 Nov 2024 16:08:18 +0100
>     From:        Christoph Badura <bad%bsd.de@localhost>
>     Message-ID:  <20241101150818.GA25135%irregular-apocalypse.k.bsd.de@localhost>
> 
>   | Actually, there are rational reasons to keep it as a tool and run it
>   | while building with build.sh.
> I didn't really see any in your message, perhaps a half of one.

Still better than yours, I guess.  At least I tried to find reasons
instead of make sweeping but baseless claims.  And then having the nerve
to call out others on it!  Do you really want to continue in this tone and
with that attitude?  Or would you like to have a productive discussion?

> Again yes, I like it too, and no-one is planning on altering that.

That wasn't clear at all.  You gave it as 3rd option, so presumably
viewing it as a viable one.  Because, why cite an option that you consider
unviable without flagging it as such?

> I am guessing that from all of this, what you're wanting is the
> ability to use the NetBSD tool ctags on other OS's which (presumably)
> don't offer a ctags equivalent of their own (and on which you can't
> just build the NetBSD ctags like any other random C program on that OS).

Not really.  And by your argument it would be only logical if we removed
building cross gdb as tool next.  After all, one could just build the
NetBSD gdb like any other random C program on that OS.

What I care about is a better developer experience.

That includes not having to scurry around and try to build random tools.
One of the main benefits of build.sh and tools is that we don't have to
deal with the toil and frustration of building a useable and useful
cross toolchain.

Of course, I'm not going to propose including random programs like editors
du-jour and stuff.  But we should build on the strengths of our tools.

Most people have switched away from running NetBSD on their laptops and
desktops.  A lot of our own developers switched to macbooks running OS X
when they became available.  And a lot switched to Linux before our DRM
situation improved.  And on Linux or macOS people don't compile random C
programs.  They pre-build install binary packages.

That's the ocean where you have to go fishing for new NetBSD users and
developers.  Betting the future of the project on a diminishing user and
developer base doesn't seem like a winning strategy to me.  Not even as
one that could maintain the status quo.

That may not be a concern to you and that's fine with me.

Personally, our ctags isn't that useful.  Having sypport for universal ctags
in our build would be more useful as I switched to using Emacs mostly and
that version is better integrated.  Even better would be integrated
support for a C language server (that means being able to generate a
useable compile_commands.json or at least providing the hooks to make that
easy.)

> 
> The question is: the canonical location for what?   I've always treated
> it as the location where the sources for the binaries that are currently
> found in /bin /usr/bin /sbin /libexec ... (etc including /usr/include
> /usr/share/* etc)

I dunno.  I only notice that a lot of our documentation still talks about
/usr/src and /usr/obj and that long time developers mentioning null-mount
trees to /usr/src.

Personally I've stopped doing that 25 years ago or so.

I've recently looked into running NetBSD in qemu and mounting src and obj
over 9P into the VM so that I don't have to bother setting up NFS on the
host system.  But that is not viable yet.  In particular I can't chroot
into a 9p mounted destdir.

> The problem with tags files, and particularly with distributing them,
> is that they either have to contain full pathnames for the source files
> they reference (in which case anything distributed has the full path names
> of the files indexed where they were on the build host, which is in general,
> useless to anyone else, and so not worth distributing) or they contain
> relative paths, and work only if the user using them is in the same
> (logical) place in the source tree as from which ctags was run (it doesn't
> matter where the tags file is stored, as long as it is possible to find,
> things like vi (at least default to) "./tags" - so a file called libc.tags
> in /var/db isn't particularly useful)

I've had to deal with the .gbinit file we genereate for programs in the
VM.  Fortunately it is easy to set up path translation in gdb and automate
that.  But yeah, we would have a way to go.

> Certainly, if we don't already, I'd support having a "tags" target in all
> makefiles (at least for multi-file objects) which will make "tags" in
> whatever directory you run it from, accessing the files relative to that
> directory.

bsd.*.mk already defines "tags" targets, I believe.

> But I wouldn't be making any of those as part of the build, (they'd need
> to be in the source sets - requiring read-write source trees to generate
> anyway), and given that, I really don't see any need for ctags as a tool.

They could live in the objdirs.

--chris