414 lts freebsd

[mro]

fixes #1459

[voodoos]

I don't have knowledge about that part of the code yet or inotify usage and behavior.

Do you think you could take some time to explain what is happening here in more details and what is the later impact of not having HAVE_INOTIFY_INIT defined ?

I don't mind merging these changes on your behalf if you tested them thoroughly, but I would like to understand a bit better what is at stake. Also, is there a reason why this patch is specific to the 4.14 branch ?

[mro]

Hi @voodoos,

take some time to explain what is happening here in more details and what is the later impact of not having HAVE_INOTIFY_INIT defined ?

the front and foremost consequences are

1. the change is defensive and integrates with the current feature configuration (no code, setting an existing #define flag),
2. only FreeBSD is affected (due to #define nesting),
3. front and foremost an otherwise non-compiling project compiles,
4. the change is related to inotify which sounds as affecting hot reloading
5. again not having hot-reloading is an improvement over not having the lsp-server at all.

The strange thing is, that inotify is present in general but not the init function in the missing (linux) header.

I however am not familiar with the inner workings of inotify nor header file layout an FreeBSD nor Linux and the differences.

To sum up

1. the change uses the config define for that purpose,
2. the change affects FreeBSD exclusively,
3. the change fixes a compile failure,
4. the result is a working and useful lsp server I use every week.

Does that clarify?

[mro]

I just learned

$ fgrep _init /usr/local/include/sys/inotify.h
/* Flags for the parameter of inotify_init1. */
int inotify_init (void) __THROW;
int inotify_init1 (int flags) __THROW;
 * IN_DIRECT to inotify_init1().

so it may well be the /usr/local/ header include path not being declared to the compiler. That's typical FreeBSD filesystem layout putting 3rd party, non-core OS stuff into /usr/local and https://www.freshports.org/devel/libinotify/ being such.

But I am not familiar with the build system to make this an easy fix. @jonahbeckford may know better: https://lists.schmorp.de/pipermail/libev/2025q1/002943.html.

[jonahbeckford]

I'm not sure of the connection. But yes, it really does seem that /usr/local/include needs to be in the include path.

[mro]

awesome @jonahbeckford - @voodoos does that help?

[mro]

Hi @voodoos,
how's it going, are contributions welcome?

[voodoos]

Yes, contribution are welcome !

I am reticent to merge this PR because I feel like it is not the best way to fix that issue, while not being able to justify it due to my lack of knowledge on that subject.

I am also surprised that no other freebsd user has complained so far...

However, I it works for you and you have been using it without issues during the last few weeks, then I'm willing to merge it on your behalf and see how it goes. Could you add a changelog entry ?