Playing with it! Two small things: somehow it seems to generate two events for a single safe, so it runs twice and make/0 performs its checks twice, resulting in a double issue report. A small tip might be to give the thread an alias automake such that warnings come out as generated by the automake system.
Good plan. First, let us buildup some experience and get a Windows version. Second is that there is also the inotify pack (by me, sorry). This is a (if I remember correctly) a complete interface to inotify. But, non-portable. Should the idea be to move to a portable alternative to inotify and add that to standard distribution packages? Possibly a somewhat limited version?
Ah yes, I was thinking I should probably “debounce” the notifications anyway, so something like a git checkout doesn’t trigger a whole bunch of make’s
will do
Good idea re: wine, I’ll give that a try.
I used that as a reference I didn’t use it directly since, as you say, it’s non-portable. My idea was to have one foreign library that I can just ifdef as needed to work everywhere. Spinning that out as a separate module, for a portable file changes library, might be worth doing too.
Good point. Didn’t switch branches this time, but I quite often do so Probably just wait for no more events in something like 0.1 sec will do.
Would be great. I once understood there is a library that generalizes over the various OS APIs for filesystem notifications. Don’t remember what it was called. I learned so not long after I completed the inotify interface
I like small Worse, fswatch is GPL (not LGPL), which I’d like to avoid whenever possible. Currently there is only the readline binding that is GPL, but for that we have the libedit binding as alternative. It is a standard package in Ubuntu though.
Haven’t checked the features of dmon. I think I’m happy with a library of rather limited functionality for the core system as long as we can watch for changed files and I guess also files added to/deleted from directories. The latter allows stuff as dumping config files into a directory and having the config automatically updated or automatically process data as it is dumped in a directory.
Okay! I’ve pushed up version 0.1.2, which both debounces the file system changes and – I think – works on Windows. I’ve just tested it under Wine and it seems like it’s working, but if someone with access to an actual Windows machine could give it a go, I would be very grateful!
During the install it gave an error about MinGW not in the path or something. Didn’t really read it as I have seen similar errors so many times I know to install one of them and pass the basic test they give.
So doing that now.
This may take some time as me and MinGW were never friendly. That is why I always uninstalled after using for what I need.
Did not have time since last post to do anything more.
Decided to look at the code and see if all of the parts are present.
In the Prolog code (automake.pl) is :- use_foreign_library(foreign(watchdir4pl)).
In the C directory is watchdir4pl.c
As Jan W. notes would have expected watchdir4pl.dll or something like that.
I don’t have a C toolchain installed and have not compiled something for C in years but if that would help I can work through this with lots of help but it will take lots of time.
Before I do that, Jan W. might know of an easier way to do create the DLL. As I note I am always amazed at how fast and correct he is.
I have a cross-compiler toolchain set up for testing. I don’t love the idea of committing the .dll into the repo, but first I’m going to look in to setting up a build process to generate the dll in the build artifact (also hopefully allowing a normal pack install to work, without the extra options).
Or this Docker GitHub - SWI-Prolog/docker-swipl-build-mingw: Docker to cross-compile SWI-Prolog for Windows
will do
I didn’t use it directly since, as you say, it’s non-portable. My idea was to have one foreign library that I can just 