Opened 8 months ago

Last modified 5 months ago

#9283 new bug

bad autoconf variable names

Reported by: rwbarton Owned by: ekmett
Priority: low Milestone:
Component: Core Libraries Version: 7.9
Keywords: Cc: hvr, ekmett
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

if test "$ac_cv_header_sys_epoll_h" = yes -a "$ac_cv_func_epoll_ctl" = yes; then
  AC_DEFINE([HAVE_EPOLL], [1], [Define if you have epoll support.])
fi

if test "$ac_cv_header_sys_event_h" = yes -a "$ac_cv_func_kqueue" = yes; then
  AC_DEFINE([HAVE_KQUEUE], [1], [Define if you have kqueue support.])

  AC_CHECK_SIZEOF([kev.filter], [], [#include <sys/event.h>
struct kevent kev;])

  AC_CHECK_SIZEOF([kev.flags], [], [#include <sys/event.h>
struct kevent kev;])
fi

if test "$ac_cv_header_poll_h" = yes -a "$ac_cv_func_poll" = yes; then
  AC_DEFINE([HAVE_POLL], [1], [Define if you have poll support.])
fi

The AC_DEFINE lines for HAVE_KQUEUE and HAVE_POLL don't do anything, because earlier we have

AC_CHECK_FUNCS([epoll_ctl eventfd kevent kevent64 kqueue poll])

and that already defines HAVE_KQUEUE (and sets ac_cv_func_kqueue) when the kqueue function is found.

Not entirely sure what the right thing to do is here, do we rely on having a prototype for kqueue in sys/event.h specifically? Technically that wouldn't be what we check for even if we used a renamed HAVE_KQUEUE variable.

AFAIK this doesn't cause any real problems except that it really confused me when I tried to simulate not having poll by moving /usr/include/poll.h away temporarily.

Change History (1)

comment:1 Changed 5 months ago by thoughtpolice

  • Component changed from libraries/base to Core Libraries
  • Owner set to ekmett

Moving over to new owning component 'Core Libraries'.

Note: See TracTickets for help on using tickets.