101–110 of 120 posts
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.
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,…
Whenever "configure" is looking for a fortran compiler in a clearly non-fortran program, one has to wonder why no one fixes the configure scripts. From all I learned it is, because the underlying scripts are close to unmaintainable. So from that perspective, a better build tooling should be a high priority.
Please don't brew your own build system. It likely won't handle at least one of the following situations: * installing into a DESTDIR * setting custom CFLAGS/LDFLAGS * changing prefix, libdir, sysconfdir * cross-compilation * parallel builds * conditional features * missing requirements and will make packaging your software in Linux distros much harder than it needs to be.
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.)
After packaging hundreds of programs for a GNU/Linux distro and dealing with handwritten Makefiles and other so-called autotools replacements: Yes, it is.
If you want someone to be able to build and install your software, just use the Autotools. Yup, they are ugly, but they're still the only set of tools that works acceptably.
Earlier quoted context omitted.
Whenever "configure" is looking for a fortran compiler in a clearly non-fortran program, one has to wonder why no one fixes the configure scripts. From all I learned it is, because the underlying scripts are close to unmaintainable. So from that perspective, a better build tooling should be a high priority.
No one fixes the configure scripts because they're thousands of lines of code in about three different archaic languages that nobody knows or cares about.
Earlier quoted context omitted.
Would be nice if you could give an example, not just "use that".
Especially since scons and cmake are in no way easy to learn, imho.
Program("main", ["main.cpp"])
`cmake` is much better. The language itself is ugly and takes some getting used to, so it's a little more complicated to get started with then `scons`. `cmake` generating `Makefile`s instead of actually building the project itself also adds a layer of complexity. But once you understand the basics it's much easier to get a fully functioning build going, including configure stages, build directories, portability and all that, as cmake has all of that integrated and working right out of the box.
`cmake` feels like a complete build system, while `scons` feels like a good start for a build system that was abandoned at the halfway point.
I still use plain `make` for some Python projects (mostly .PHONY targets to run `pylint`, `autopep` and friends), but for everything that needs to get compiled `cmake` is much easier to use than plain `make`, as you don't need to reinvent a build system yourself, it already comes with almost everything you need.
I do like simple makefiles. I adopted a C++-project without having much C++-knowledge, and simplifying the build setup was a big step in making it mine. Thinking that it might be nice, I tried this one instead of my own approach at a simple makefile ( https://github.com/onli/simdock/blob/master/Makefile ) and I get this error: > Makefile:16: * missing separator. Stop. Which raises kind of an important point: Simple m…
Ummmm use cmake like a proper adult
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 only works in the Unix world, on Mac only for command line tools (but only after installing autoconf and make), and not at all on Windows unless you install a complete Unix environment (cygwin or mingw).
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.)
>And no, “just use autotools” is not a viable answer. After packaging hundreds of programs for a GNU/Linux distro and dealing with handwritten Makefiles and other so-called autotools replacements: Yes, it is. If you want someone to be able to build and install your software, just use the Autotools. Yup, they are ugly, but they're still the only set of tools that works acceptably.
It's a pleasure when autotools is used because in generally I know it's going to be nothing much more than
> --with-stuff/--without-stuff
and
> --prefix=$HOME/.local
and when it's not, at least I know I can just grep the shell script and figure it out pretty quickly without having to learn a whole new programming language.
Earlier quoted context omitted.
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.
Exactly. When evaluating a language / build system / whatever, it is definitely not sufficient to look at Hello World. You have to evaluate the worst case and average case if you want to get an idea of what you're in for. Looking at the "best case" (simple one-file project) tells you almost nothing except how hard it is to get started.
This is a good criteria for languages as well.