Complete build options for Pthread API about watchman

[wez]

watchman has a relatively limited set of supported platforms due to the requirement of having to interface with a kernel filesystem notification scheme.

My personal disposition in this matter is the same as that expressed in
facebookarchive/libphenom#53

[elfring]

I would appreciate if the software portability can be easily improved for this implementation detail.

[wez]

If AX_PTHREAD were part of autoconf and commonly available out of the box, I would have no issue with using it. As it stands right now, it just increases the amount of "stuff" to maintain in the repo and has no practical benefit; if a new system emerges then the amount of work to adapt watchman to use its pthread implementation would be trivial compared to the work to make it work with whatever filesystem notification APIs are available.

[elfring]

Do you see any software design challenges from the reuse of the Autoconf archive?

[wez]

The issue is that it increases the amount of "stuff" we'd need to maintain and do in the repo. It has no benefit to the project as it stands today and consumes time and resources in terms of what we'd need to maintain and synchronize with the upstream source of the autoconf library.

A simple one liner in the autoconf script today is perfectly sufficient for our needs and is easily understandable.

It just doesn't seem worth the effort.

[elfring]

How do you think about to reduce risks for choosing wrong software build parameters for this application programming interface?

[wez]

We support a handful of systems with well known pthread build parameters; this is not an issue for us at this time.

[elfring]

Will "Solaris style systems" eventually need other build parameters than the run time environments that you would also like to support?