google
Switch to CMake
There is some initial implementation by @alessandrogario in https://github.com/google/AFL/pull/11.
See https://github.com/google/AFL/pull/11#issuecomment-517869472 for motivation / goals.
+1 for CMake. I use it for all my fuzzer projects because it has seamless ninja-build integration (building feels like building with gn on Chrome) while still being available on almost every distro and letting you generate old-school Makefiles if you still need them.
It can also generate compile_commands.json which can be used with IDEs. I use VS Code which will notice the compile_commands.json and suddenly the cross references all work.
Is CMake support really as ubiquitous as support for simple makefiles? Maybe we shouldn't switch since it could make it harder for some people on (especially those on obscure platforms) to use AFL
Is CMake support really as ubiquitous as support for simple makefiles? Maybe we shouldn't switch since it could make it harder for some people on (especially those on obscure platforms) to use AFL
It seems like CMake is thoroughly tested on many operating systems, OS versions and architectures but I'm not sure what you mean with "obscure platforms" (can you make an example?). Some examples in that list include various Linux flavors, AIX, Solaris (even SPARC!), macOS, Windows, and even cygwin and msys environments.
It's extremely easy to bootstrap the latest CMake version from scratch with nothing but a compiler and the provided upstream script, even on ancient EOL systems. I once bootstrapped it on a Solaris 8 machine with little to no issues! In general, I would say that CMake always makes things easier.
As @nedwill mentioned, I also liked the first-party support in IDEs (like CLion or QtCreator for example) and the good packaging support it provides.
I do understand however that it's not for everyone and people may prefer the current build system (which works perfectly fine!).
@jonathanmetzman afl's makefile is not 100% portable either as it needs gnumake for several features.
in afl++ I doubt we will switch to cmake. I dont see the benefit. And buidling for Android would then need its own makefile (which is currently the case as well but we try that to merge we dont have 2 files to maintain)
Thanks for the replies @vanhauser-thc and @alessandrogario.
I guess portability isn't the right word, since the Makefile isn't as portable as I thought and CMake is more portable than I thought.
I guess the main downside of using cmake (besides the effort it would take to switch) is the marginal amount of extra friction it may cause when people try to use AFL (make will probably just work on more unix systems than cmake). I'm not totally opposed to use CMake, I just wanted to make sure we considered how switching might change the fact that AFL is super easy to build.
@jonathanmetzman yes, gnumake is nearly everywhere installed where a gcc is, cmake is not. this might change in the future though