respect MAKE, properly test for mincore, fdatasync is in <unistd.h>

[madroach]

• directly calling make will break on systems where GNU make is called gmake and make actually is BSD make.

• fdatasync is defined in <unistd.h> on OpenBSD. According to https://linux.die.net/man/2/fdatasync the same is true for linux.

• I found out about d791b9b only after I adjusted discover.ml to check for availability of mincore. I'd suggest to rather test for the actual feature than to test for OS. Only tested on OpenBSD, where mincore is not available. So testing on Linux and maybe some other BSD, maybe Cygwin should still be done.

[aantron]

The first two commits look good. Does the third solve a problem you are having? The new check is failing on another BSD(-ish system), namely macOS.

To make the #ifdefs easier to understand, I'd suggest specifically testing for mincore only, and then testing the argument types. So, I suggest inserting a new test, rather than complicating the existing test for argument types.

[madroach]

Well, it does solve the same problem as d791b9b, but since d791b9b is OS-specific I'm offering my take on it as an alternative. You may cherry-pick whatever you like of this pull request :).

[aantron]

Ok :) I cherry-picked the first two commits.

On the third, there is an argument to be made for discovery, but I think this case is not yet clear, and I prefer not to risk accidentally breaking Lwt on some obscure system for this. If we have a problem with additional OSes not supporting mincore, we can revisit the commit. As you saw, you have to do a product of all the various argument types that mincore can have, and it's not clear that this is better than checking some ifdefs, at least not to me right now. In other words, both solutions are a little bit dubious.

Actually, you can probably discover the array argument type by just trying to call mincore, as that will abstract away whether you have void or const void in the other argument. But still, I think we can get by for now.

Thanks for your work!