51–60 of 120 posts
This approach is flawed because it uses "find" to discover the source files which means that if you delete a source file, it won't cause a rebuild since it won't see any changed files.
Also you have to wait for find to run before any building starts. Can be slow for a large project.
Just use cmake or scons. In 2016, you should not hand write a single makefile ! A simple cmake/sconcs build file will be as simple as the one shown (or even simpler !) and it will definitively will be easier to integrate external dependencies if you have to.
SCons has many issues that negatively affect packagers. Some are listed on the Gentoo wiki here: https://wiki.gentoo.org/wiki/SCons
As an OpenBSD packager, I hit many of those issues and a few more. For example, scons’s C preprocessor support is not great, and often brings in header dependencies that should be #ifdef'd out; when those unnecessary headers are removed during build (happens often on a machine bulk building packages), the build breaks.
I’ve replaced SConstructs with Makefiles before. Typically it makes the build faster, simpler, and more portable, and is popular with other OS packagers. Example: https://github.com/sinamas/gambatte/pull/6
Earlier quoted context omitted.
Somebody listed a number of common build system requirements below, but of course there are usually many many more like custom compilers, cross-compilation, any number of things that your "simple makefile" can't work with. By the time the Makefile has grown to support all these things it no longer has the properties that made it useful in the first place (parsimonious, understandable, small).
Supporting custom compilers and cross‐compilation is as simple as using ${CC} in the Makefile instead of gcc…
Earlier quoted context omitted.
Autotools does do all of those things. I'm not a particular fan of it either, but when I'm packaging software for a Linux distro then I'd rather see autotools or cmake being used instead of some crappy custom build system that will require patching to make it work. There is room for someone to come up with a good build system. It had better do everything autotools and cmake do, and be well documented and widely used,…
Auto tools is great. To compile all you do is ./configure make make install It couldn't be simpler. Even though I am part of the GitHub generation, I don't see why so many of my peers hate it. I actually like it.
It’s a crawling horror for the programmer that wants to use autotools as the build solution for their code however, which is the topic under discussion.
Earlier quoted context omitted.
Still hell of a lot simpler than hand-writing Makefiles though. For both small and large projects. I mean, a "hello world" CMakeLists.txt can be literally just this: add_executable(hello hello.c) And it's cross-platform, can generate Visual Studio/Xcode/... projects, etc.
I think we have to go deeper than that to really see an advantage of cmake. A corresponding makefile would be: all: hello That's not really complicated either.
Earlier quoted context omitted.
Auto tools is great. To compile all you do is ./configure make make install It couldn't be simpler. Even though I am part of the GitHub generation, I don't see why so many of my peers hate it. I actually like it.
This is kinda hilarious because, yes, "Autotools is great" [as a consumer]. But autotools and m4 is kinda awful to write IMO.
Earlier quoted context omitted.
There’s no point telling people not to do something if you don’t give them an alternative that does do all those things. (And no, “just use autotools” is not a viable answer.)
Ehm ehm... every second reply around here is shouting "cmake"...
"But because Make works backward from the object files to the source, we need to compute all the object files we want from our source files". No.... don't do this. Make is intended to work the other way around... it finds the source from your targets. Define your VPATH and let it find them. This is what loads of people do and is why there are so many Makefiles are packed full of macro-magic!
Also you can't really get around specifying the files or searching, unless you have one c file per executable.
That's why I chose CMake for my projects. If this is simple, I chose the right build tool.
This build file of a large project is easier to understand than the "Simple Makefile"
https://gitlab.kitware.com/vtk/vtk/blob/master/CMakeLists.tx...