Re: Compiling fails on MacOS

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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.

  | build.sh is our official way for users to do local builds.  And that
  | includes local development.

Yes, of course.   I'm not planning on doing anything to alter that.
Definitely not cripple it.

  | Cross building with build.sh is a major selling point for NetBSD.

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

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).

Is that really all that important?

  | Now the situation with the libc tags file containing non-canonical
  | path names isn't ideal.  Perhaps we should fix that.

We should, but that's a separate question (except to the point that
if we're to keep distributing it, we need to keep ctags as a tool).

  | (We kinda prefer /usr/src as the canoncial location,

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)

If you're not on a NetBSD host and are cross building, then /usr/src
certainly isn't where I'd expect to find the (NetBSD) sources, for
example.   If you are on NetBSD then you'll have /usr/bin/ctags
and no need at all for the tool version.

  | Perhaps we should fix our tools to make it possible to use such files
  | more easily.

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)

It would be possible to add some TOP= setting in the tags file, and
have all the pathnames in it then be relative to that.  But that would
be a change to a file format that's existed (unchanged) for about 45
years now, and which would require who knows how many other applications
to be taught about something different - which I really can't see being
practical to attempt.

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.   That is, users build the tags files in the directories they
expect to be in when working upon a specific application (the subject of
the tags files - there can be several, in various subdirs, all indexing
the entire tree, but with different relative pathnames).

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.

kre

ps: for anyone following this Subject: thread, I'm still waiting for someone
to indicate whether ctags as it exists now builds (and allows the libc.tags
file, as useless as it is, to be built during the build), on those platforms
where the one from 2 days (or whatever ago) failed to build (the ones which
created this thread in the first place).