introducing a requirement for pkg-config, sometimes

This message is basically about all systems that are POSIXish, meaning
everything but Windows native builds.  This message is not really
relevant to those using unison via packaging systems or the CI
artifacts.  It does affect those building unison from sources, even if
not attempting to modify the code, and is thus on users.

Currently a PR is pending to use libinotify to make fsmonitor work on
BSDs.  That requires finding the library and the right CPPFLAGS and
LDFLAGS.  The standard approach for that, often contained within systems
like autoconf, is pkg-config, which uses control files that are part of
each package to convey required flags to programs using that package.

I am leaning to saying that for any library needed by unison which ought
to be found via pkg-config, then the build system will simply use
pkg-config, implying that if for some reason pkg-config is not present,
the build will fail.

I believe that for all build environments (other than native Windows),
it is trivial to install pkg-config, as vast numbers of other builds
need it, and a system that can't have pkg-config is basically
unthinkable.  And therefore, that it is better to impose a hard
requirement on pkg-config than to have any complexity or alternative
approaches.

That said, it seems better for a build that would not even try to use
pkg-config to succeed whether or not it is present.  So far, due to the
mostly-ocaml nature of unison, the only example might be libinotify on
BSDs, if one is building fsmonitor (by explicit request or an implicit
"build everything" target).

If you build unison from source, pkg-config isn't already installed, and
installing it would be difficult, please explain the situation.
Otherwise I'll assume that "to build foo, you have to have pkg-config"
is not a problem once documented in INSTALLING.md.

Greg

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].