Copy the C header file in /usr/local/include

[dunglas]

Currently, it's a bit difficult for end users to install the C bindings. Couldn't we update the Cmake definition to automatically (or through an option) compile the C bindings, and copy the file to include in the system include path?

Also, this will help to add a formula for this lib in Homebrew.

[e-dant]

Yes, absolutely

[e-dant]

Added in 0.13.1, check out this: https://github.com/e-dant/watcher/actions/runs/11491524051/job/31984241215#step:11:1 for a dump of the artifacts from a typical cmake build on macOS, re. homebrew.

[e-dant]

Also -- The headers and the shared library are available for a variety of platforms/triples in the release artifacts, in case that's easier than cmake (or meson).

[dunglas]

Thank you very much.

I'm looking for simple instructions for end users to install the library without building useless artifacts.

I used the typical cmake invocation:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build/
sudo cmake --install build

This works, but a lot of files useless for production are compiled and installed, including sanitizers and snitch builds.

Setting -DWTR_WATCHER_BUILD_TEST=OFF -DWTR_WATCHER_BUILD_ASAN=OFF -DWTR_WATCHER_BUILD_MSAN=OFF -DWTR_WATCHER_BUILD_TSAN=OFF -DWTR_WATCHER_BUILD_UBSAN=OFF does not seem to help, the testing files are still installed.

The "standard" -DBUILD_TESTING=OFF is not defined.

Is there a way to build and install only production files? Could we add support for DBUILD_TESTING=OFF?

Thanks!

[e-dant]

Yes of course!

[e-dant]

How do these options look?

(Example snippet w/ no sanitizers, no tests)

$ cmake -S . -B out/tmp -DBUILD_TEST=OFF -DBUILD_SAN=OFF
...
-- wtr.hdr_watcher: Added (BUILD_HDR=ON)
-- watcher-c-hdr: Added (BUILD_HDR=ON)
-- watcher-c-shared: Added (BUILD_LIB=ON)
-- watcher-c-static: Added (BUILD_LIB=ON)
-- wtr.watcher: Skipped (BUILD_TEST=OFF)
-- wtr.watcher.asan: Skipped (BUILD_SAN=OFF)
-- wtr.watcher.msan: Skipped (BUILD_SAN=OFF)
-- wtr.watcher.tsan: Skipped (BUILD_SAN=OFF)
-- wtr.watcher.ubsan: Skipped (BUILD_SAN=OFF)
-- tw: Skipped (BUILD_TEST=OFF)
-- tw.asan: Skipped (BUILD_SAN=OFF)
-- tw.msan: Skipped (BUILD_SAN=OFF)
-- tw.tsan: Skipped (BUILD_SAN=OFF)
-- tw.ubsan: Skipped (BUILD_SAN=OFF)
-- wtr.test_watcher: Skipped (BUILD_TEST=OFF)
-- wtr.test_watcher.asan: Skipped (BUILD_SAN=OFF)
-- wtr.test_watcher.msan: Skipped (BUILD_SAN=OFF)
-- wtr.test_watcher.tsan: Skipped (BUILD_SAN=OFF)
-- wtr.test_watcher.ubsan: Skipped (BUILD_SAN=OFF)
-- portable-destructive-rename: Skipped (BUILD_TEST=OFF)
...

[e-dant]

Where the full set of options is:

option(BUILD_LIB   "Create a target for the watcher-c libraries"          ON)
option(BUILD_BIN   "Create a target for the CLI binaries"                 ON)
option(BUILD_HDR   "Create a target for the watcher headers"              ON)
option(BUILD_TEST  "Create a target for the test programs"                ON)
option(BUILD_SAN   "Mega-option to allow sanitizers"                      ON)
option(BUILD_ASAN  "Create a target for the address sanitizer"            ON)
option(BUILD_MSAN  "Create a target for the memory sanitizer"             ON)
option(BUILD_TSAN  "Create a target for the thread sanitizer"             ON)
option(BUILD_UBSAN "Create a target for the undefined behavior sanitizer" ON)

[dunglas]

This looks good to me. What do you think about adding a BUILD_TESTING mega option that will set BUILD_TEST and BUILD_SAN to off? This option looks pretty standard and is added by default by Homebrew.

Thank you very much for your work on this!!

[e-dant]

Fixed in 55e6b15, I'll cut a release if #59 is resolvable

[e-dant]

Well... Let me fixup some build errors first...

[dunglas]

I confirm that the next branch works as expected, thank you!

Another related thing: is it desirable/needable to install the wtr.watcher and tw binary in the system path? At least, maybe the tw binary should be renamed for something more explictiy like tiny_watcher?

[e-dant]

Another related thing: is it desirable/needable to install the wtr.watcher and tw binary in the system path? At least, maybe the tw binary should be renamed for something more explictiy like tiny_watcher?

Yeah, great question, and one which I've asked myself a lot.

The wtr.watcher binary started as an example of the library, but quickly turned into something that I used a lot. Brewing up quick scripts that

• reload files
• notify me of suspicious changes
• undo changes on files that I don't want to be modified

Are examples of things I have running on my system.

I use wtr.watcher for that, and so it's useful for me personally to have it as an installation candidate.

tw is has a somewhat similar story; started as an example, but grew into something that I actually use. In this case, I find the output more human readable, so I tend to use it for interactive sessions.

---

You might notice a lot of "personally" or "for me" phrases up there -- that's really what I wonder about -- are these programs actually useful for other people? What do people use this project for; libraries or programs?

I don't know.

---

I started thinking about this one much more when I created examples in some of the other languages we support (Rust/Node.js/Python/C) which all do similar things.

What makes one of those programs less important than the original C++ programs? Which should we prefer, if any?

---

Your thoughts are definitely appreciated here.

[e-dant]

For the naming, I've been hesitant to change things in case there are people relying on them as-is. (But I think we can/should do it.)

However, if we change the binary names, I'd also like to change wtr.watcher (nearly nothing else in the universe has a . in a program name, and it was a mistake)