cmake build issue

[anoopradhika]

cmake make build failure
CMake Error at libfswatch/CMakeLists.txt:115 (add_library):
Cannot find source file:

../libfswatch_config.h

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

CMake Error at fswatch/src/CMakeLists.txt:9 (add_executable):
Cannot find source file:

../../libfswatch_config.h

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

CMake Error at test/src/CMakeLists.txt:7 (add_executable):
Cannot find source file:

../../libfswatch_config.h

Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx

CMake Error: Cannot determine link language for target "libfswatch".
CMake Error: CMake can not determine linker language for target: libfswatch
CMake Error: CMake can not determine linker language for target: fswatch
CMake Error: Cannot determine link language for target "fswatch".
CMake Error: CMake can not determine linker language for target: fswatch_test
CMake Error: Cannot determine link language for target "fswatch_test".

[emcrisostomo]

Hi. That file is being created by the autotools (by configure), so there's indeed a problem. The only solution I can think of is building a replacement configuration header with CMake. However, CMake builds are not supported and I wouldn't hold my breath.

[Qix-]

This is disappointing. Automake is dying, CMake is the industry standard. Adding this to my larger project was a one-liner, but unforunately the CMake builds don't work :| Why have them if they aren't supported?

[emcrisostomo]

Hi @Qix-. I empathise with your disappointment, but in the world I'm living Autotools is very well alive, while nobody's using CMake. This is not a judgement of value, it's just a description of my reality.

Now: why have them? Well, here's the story: I switched to CLion, which:

• has CMake support
• does not have Autotools support
• has limited Makefile support

So, for a while, I used to boostrap the Autotools project as usual, and at the same time I could have sanity inside CLion. I started experimenting with it, but not only it gives me no real advantage, but it's an additional complexity which is a cost to me. As a consequence, I stopped working on it.

Please, feel free to submit a PR if you feel so inclined. :)

[Qix-]

The build system of a project should not at all be influenced by the IDEs of a single developer of that project.

I would open a PR but would it be accepted? It wouldn't use your autotools setup at all. Its goal would be to replace it entirely.

[emcrisostomo]

@Qix-, I told you the story to tell you why that CMakefile is there, in the first place. Without it, it wouldn't be there and I'm wondering whether this discussion would exist at all.

Now, the build system of fswatch has been Autotools since the beginning of that project and I reiterate that in the world I'm living, a great deal of the software we use (and build), still uses it, and I don't see any hint of its changing.

Even a cursory search I've made out of curiosity on the MacPorts repository, where I'm the fswatch maintainer and occasionaly maintainer of other packages, tells me that 579 ports out of a total of 23153 ports are built using CMake. From these, we should subtract multiple versions of the same asset. On the other hand, totalling a 2.5% of the port base. From the total we should eliminate all the other port groups to have a correct number, given that Autotools are the default, but no the only port group, but I suspect we wouldn't have any big surprises there.

I don't want to open a can of worms because, frankly, Autotools have worked excellently out of the box on all the systems I'm using, including Solaris, FreeBSD, etc.

If you decide to contribute a PR I can see the following scenarios:

• You decide to maintain both: that's a burden with no perceivable value.
• You decide to remove the Autotools: in which case we would have to test the build on a good numbers of systems.

In either case, I still don't see where the value is, since Autotools are meant to not require them in the host where you're building the source tar ball. On the other hand, CMake is required. And is there any place in the world when you're building a C/C++ program and you do not have make installed?

[Qix-]

🤷‍♂ sounds like you've made up your mind, then :)

I'll look for another filesystem watcher. Thanks!

[emcrisostomo]

I haven't made up my mind, I just haven't got any proposal, really, nor understood where the problem is. If that was the case, I'd certainly like to help.

Have you got any problem building the software from a release tarball with ./configure && make?

[abbaswasim]

I can see both sides of the coin. I can imagine someone already using cmake build system would find it very easy to integrate a cmake build system third party software and would naturally prefer a cmake build system for all dependencies but not always possible.
On the other hand maintenance of two different build system is a pain in the back side as well. It does have the value that it can easily be integrated with cmake based projects.
Having said that I think if I can call ./configure && make? From cmake somehow and be able to create a shared or static lib and link to it I don’t care what the third party build system is.
So perhaps providing some cmake snippets on how to do that would be enough? Assuming that’s possible of course.

[emcrisostomo]

Thanks @abbaswasim. I don't see why not: according to the docs you should be able to run any process during a CMake build (https://cmake.org/cmake/help/latest/command/execute_process.html). You can:

• Download the source tarball using the GitHub API.
• ./configure the build
• make it

That's exactly what port systems such as MacPorts or HomeBrew do.

[1whatleytay]

Hey :D

I've been working with cmake and clion for a while and I was disappointed to see that the cmake build system was broken. There are a couple reasons why I would prefer cmake (most of them have to do with libfswatch but ehh).

• It's super easy to add packages via git submodules. Something like add_submodule(fswatch) is enough to include fswatch into your project (wo/ building or requiring the user to install packages globally).
• Raw MSVC doesn't have make and installing msys or cygwin is a lot of unnecessary trouble.
• It can target any build system you like, and you can therefor use it with almost any platform. Take Xcode, MSVC, CLion and even tools like ninja.
• You could build libfstools separately then include it in your project, but you'd be missing out on some nice bonuses from building straight from source:
  • You don't need to worry about building 3+ times for each platform you wish to support.
  • Git repository file size suffers from prebuilt binaries.
  • Debugging symbols are more manageable (if something goes wrong in libfswatch, like parent program passes nullptr, its debuggable if the parent program is built for debug, and if the parent program is built for release, so is libfswatch)

I'm unsure if you've excluded MSVC by design (backends don't work properly with it) or if it's just a byproduct of using autoconf.

To be entirely honest, I'm blissfully incompetent with automake, and I haven't been able to build yet to take a look at the config file that's causing the trouble. By excluding it, I've managed to make cmake build on macOS, although its a really 'workaroundy' solution.

I'm willing to spend time to get the cmake build system up to date, test on multiple platforms and create a PR- as long as it will get merged 😓. Stuff like including unistd.h stops the branch from working perfectly cross-platform right now.

[SamuelMarks]

FYI: I fixed this and added MSVC support in #282

[emcrisostomo]

Thanks @SamuelMarks for your contribution. I've added comments to #282, since I don't think this is actually fixed yet.