Date: Mon, 04 Feb 2019 16:09:33 +0000 From: bugzilla-noreply@freebsd.org To: haskell@FreeBSD.org Subject: [Bug 235240] devel/libinotify: move sys/inotify.h into a subdirectory Message-ID: <bug-235240-16154-f2wosxSGf4@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235240-16154@https.bugs.freebsd.org/bugzilla/> References: <bug-235240-16154@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235240 --- Comment #6 from Jan Beich <jbeich@FreeBSD.org> --- (In reply to Sunpoet Po-Chuan Hsieh from comment #5) > Could you please give a case that "consumers may opportunistically > pick it up over kqueue backend or if not required"? Look for ports with CONFIGURE_ENV=3Dac_cv_header_sys_inotify_h=3Dno. > After this change, do we have to teach every new ports how to find the ne= w home of inotify.h? No. Only those not using pkg-config. -linotify doesn't exist on Linux, so it always comes with a .pc file (unless older than 20170711). autotools and me= son support pkg-config just fine, cmake uses modules to reinvent pkg-config but= the support is good if required module exists, gmake and bmake[1] can cache pkg-config output via $(shell ...) and ${SH:!...!}. [1] bmake caching have to be in submake *after* pkg-config is installed as ${SH:!...!} is evaluated at parsing time. gmake isn't affected because it's only used to parse vendor's Makefile while port's Makefile is parsed by bma= ke. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235240-16154-f2wosxSGf4>