Skip to content

Fallback to $c.find_system_header() for HAVE_*_H checks #67

@boris-kolpackov

Description

@boris-kolpackov

While generally probing (e.g., trying to compile/link a test program) is a bad idea, this feels reasonable since there are not many other reasons why this function would fail (no permissions to scan the directory is probably the most likely).

A couple of issues:

  1. We would need to have the c module loaded in order to be able to call this function. Probably expecting the user to do so (and issuing helpful diagnostics if we were unable to fall back to this mechanism) would be natural.

  2. How do we know whether HAVE_SYS_HWPROBE_H is sys/hwprobe.h or sys_hwprobe.h or sys-hwprobe.h?

A couple of representative examples for the last point:

HAVE_SYS_HWPROBE_H sys/hwprobe.h
HAVE_PTHREAD_NP_H pthread_np.h
HAVE_MACHINE_IOCTL_METEOR_H machine/ioctl_meteor.h
HAVE_DEV_VIDEO_METEOR_IOCTL_H dev/video/meteor/ioctl_meteor.h

Note that theoretically the same prefix may have different interpretations depending on the target platform. So feels like the following approach is the most sensible:

  1. By default assume the name is a file name that uses _.

  2. Maintain a map of prefixes to either directories or to --separated names.

And now the probing brittleness raises its ugly head: the lack of appropriate mapping will be indistinguishable from the lack of header. Perhaps we should only handle without an explicit map entry names that don't contain _ (most system headers don't)?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions