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 <b...@bsd.de> > Message-ID: <20241101150818.ga25...@irregular-apocalypse.k.bsd.de> > > | 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
