In the future, can you migrate gcc to clang and then replace the static Makefile with cmake.

[daiaji]

The static Makefile made me have to switch the compiler version using symbolic links.

[kakra]

I don't see how it is static... Everything is passed in as variables. You could probably just use make CXX=clang to use clang as compiler (I'm not using clang so I don't now if that command is correct, in theory, tho, you can pass in LD, CC, CXX etc).

[daiaji]

@kakra Sorry, I always thought that the makefile is static.

But bees can't seem to compile with clang.

make CXX=clang
make PREFIX=/usr LIBEXEC_PREFIX=/usr/lib/bees ETC_PREFIX=/etc TAG="3ecf69a" -C lib
make[1]: Entering directory '/home/daiaji/bees/lib'
clang -Wall -Wextra -Werror -O3 -I../include -D_FILE_OFFSET_BITS=64 -std=c++11 -Wold-style-cast  -o chatter.o -c chatter.cc
In file included from chatter.cc:1:
../include/crucible/chatter.h:96:7: error: private field 'm_line' is not used [-Werror,-Wunused-private-field]
                int m_line;
                    ^
1 error generated.
make[1]: *** [Makefile:48: chatter.o] Error 1
make[1]: Leaving directory '/home/daiaji/bees/lib'
make: *** [Makefile:34: lib] Error 2

[Zygo]

I have little or no objection to porting the makefiles or compiler to some favorite tool or other in order to make downstream integration easier; however, this has been proposed before (e.g. #111) and I've seen zero PRs so far.

Changing the Makefiles doesn't help with bees performance or functionality--though it can hurt, e.g. dropping the -O3 flag, see c69a954d8f100a31a98bf627ef3235d7c9500be8. This puts Makefile changes all the way off the bottom of my own list of priorities.

clang could be interesting for the things it can catch that GCC can't...or it could be a massive time sink for weeding out inadvertent use of GCC extensions or STL implementation quirks.

[kakra]

@Zygo, I'm probably going to work on a meson/ninja build system for bees, soon. But I'd prefer to do this after a v0.7 tag. I was also thinking about integrating the clang linter then.

That way (after a v0.7 tag) we can have a recent build of bees without forcing people to arrange with a new build system when running from git.

[Zygo]

FWIW it now builds on clang version 7.0.1-8+deb10u2 (tags/RELEASE_701/final).

[kakra]

I'd rather migrate this to meson/ninja, it looks easier and more modern than cmake. @Zygo If you're fine with that, I'd be working on a PR.

[Zygo]

I'm fine with meson/ninja, mostly because I know nothing bad about them.

I've used cmake (and autoconf) on other projects...apparently, given the choice, I preferred to write plain Makefiles for bees instead.

[kakra]

Yeah, I think cmake is quite a complex beast - but at least with nice output, parallel building and progress reports. Meson and ninja can do the same with less complexity / cryptic syntax.

[Zygo]

Well, we have parallel building now...

I'm hoping for build-time feature tests so we'd be able to do things like figure out whether the version of btrfs.h has members in structs. Currently it's very kludgey and fragile to do it all with just the C preprocessor.

[kakra]

Yeah but parallel building is a feature I hacked into the makefiles by building dependency files. Meson has this by default. Build-type feature tests should be possible with meson.