5 ms·

Implicit makefile rules can be quite helpful in quickly building a few binaries or small projects. Take a look at this C++ example: for a file mybin this creat

Implicit makefile rules can be quite helpful in quickly building a few binaries or small projects. Take a look at this C++ example: for a file mybin this creates mybin.o and then links it, spitting out a mybin executable: env CXXFLAGS="-std=c++14 -Wall -Wextra -pedantic" LDLIBS="-lstdc++" make mybin To see what's going on, and what kind of file types are supported: make --print-data-base | egrep 'COMPILE.cc|LINK.cc' This not only shows you what is going on, but also what kind of environment variables are involved and can therefore be customized. For small projects I would create a config.mk (e.g. with CXXFLAGS, CXX, ...) and provide a small Makefile, something along the lines of: include config.mk all: mybin mybin: mybin.o watch: while ! inotifywait -e modify *.cc; do make; done clean: $(RM) *.o mybin .PHONY: all watch clean This allows you to easily 1/ add dependencies for binaries and 2/ speed up the development proccess, using the make watch target (note: this does not include header dependencies). Disclaimer: Makefiles seem to be wonderful build-systems (not dependency managers!) for small projects; but as soon as you find yourself searching for hacks to build into your little Makefile, ditch it and switch to something serious. That's at least my experience.

sdevlin 12y ago
> something serious What do you recommend? Autotools, bespoke shell scripts, or something else entirely?
- danieljh 12y ago
  For C++, unfortunately CMake is the best option there is it seems. For LaTeX there is latexmk. Clojure has Leiningen. You see, it heavily depends on your preferred environment.
  - e12e 12y ago
    FWIW when I tried out qmake for a toy c++ project, it's the first make tool for c++ that actually just worked[1] for a simple command-line app. CMake works too, but not without fighting the horrible syntax of CMake first. And make... well it works, but at what price to your soul? ;-) [1] The documentation is actually a little dense, as qmake is a tool capable of building "real projects", but I found that a simple qmake -project && qmake && make (I think, at least you need a project file, and the let qmake make a makefile, and then use that...). http://doc.qt.io/qt-5/qmake-running.html http://doc.qt.io/qt-5/qmake-running.html See also: https://web.njit.edu/all_topics/Prog_Lang_Docs/html/qt/qmake-manual-3.html https://web.njit.edu/all_topics/Prog_Lang_Docs/html/qt/qmake...
    - pubby 12y ago
      premake is another tool that just works for C++, but it's not as flexible as some of the other build systems and so I don't use it.
    - arunc 12y ago
      At last, I find someone who uses qmake on HN. I've been using qmake for 4 years now. At first I started experimenting with it for a small project. The learning curve was quick and eventually fell in the comfort zone it created. Now I use it for large scale C++ projects and I've never looked back for other build tools, not even CMake. Surprisingly, I never understood why KDE project that uses the complete Qt ecosystem doesn't use qmake but rather settled to CMake.
      - realharo 12y ago
        Does qmake deal with finding the dependencies and automatically adding the include paths, libraries, etc. for them? As far as I know, you need to stick the compiler and linker flags manually into qmake, which basically means that it works on your machine, but may break on anyone else's system. This is what a lot of the complexity inside cmake is addressing - differences in build environments.
        e12e 11y ago
        I think the answer is: "It depends.". From some searching, it looks like cmake has better cross-platform support, and is (unsurprisingly) more powerful when you need to do something a little gnarly. That said, it appears (never had need to test) that qmake works fine with pkg-config: http://doc.qt.io/qt-5/qmake-project-files.html http://doc.qt.io/qt-5/qmake-project-files.html In my experience (mostly from compiling from upstream source, when something isn't available in Debian and/or backporting for personal use) there are different kind of libraries, some behave better than others (eg: easy to install under $HOME/opt with xstow -- as I prefer to /usr/local, as the latter needs root and/or rw-privileges on /usr/local). I've yet to find any pattern for when things just work, and when things don't (the real reason typically being some hard-coded paths or other nastiness -- I just mean some obscure projects work fine, some big ones fail miserably). So I guess YMMV -- but for now, qmake is the tool for building simple c++ I've found that is simple, for simple projects. I also use CMake (preferably with ninja) -- but I don't really like the CMake "language". Maybe what we need is a CMake-generator? Then we can generate CMake-files that generate ninja files that build our code! ;-)
- mackwic 12y ago
  It will depends on you platform and technology. I can only recommend you to _not_ be fancy and stick with the conventions or else you could have a lot of trouble to interact with dependencies. By dependency I mean anything your program would need to run: from system libraries, headers, local libraries linked either statically or dynamically, or even syscall. A lot of things can go wrong, our whole software cathedrals are build upon years of conventions and patches. Anything can break. Don't even try too look what `ld(1)` is doing. Autotools has never be a great tool, only a necessary evil for when you need to package cross-Unixes software. I heard that CPack (http://www.cmake.org/Wiki/CMake:Packaging_With_CPack http://www.cmake.org/Wiki/CMake:Packaging_With_CPack) do the job while being exactly as good as CMake (which can be a compliment... or not. YMMV). So, if you use Rust, use Cargo, with Java use Maven, with C# use MSBuild, with ruby use Rake, etc. And C/C++ ? Well, for once if you can chose you're lucky. You can try CMake or premake. The only thing you must do is get away of most of the Google's build projects: Gyp, Lunch, Ninja, etc. I have horrible experiences with those. Even worse than Rubygem's native compilation, which is quite a performance.
  - bla2 12y ago
    What's wrong with ninja? It's CMake's best output format as far as I know. A lot more enjoyable to use than, say, msbuild.
- ayuvar 12y ago
  For C++, I'm a long-held adherent of SCons. You can make some horrendous messes but it's nice to have Python around instead of having to learn another intermediate language as in CMake's case.
  - chx 12y ago
    I'll make my reply short: > adherent of SCons. o_O > You can make some horrendous messes :nod:
    - coherentpony 12y ago
      In fairness, you can do that in every build system. All build systems are awful. Pick the one you know best.
- antimagic 12y ago
  This is a good question. After too many years experience of fighting with build systems, I have come up with one overarching requirement - the build system needs to be debuggable. I need to be able to easily identify why a particular file was built. I need to be able to easily recover the command line that builds a generated file, as in if I know that I have a source file called foo.c, I need to be able to easily obtain the command line that compiles foo.c to foo.o, so that I can see the options that were used. I need to be able to easily see how variables are constructed. Something like being able to put a watch on them, so I can find the lines of build files that modify them. You need these things because you know what? One day someone else is going to want to modify your build system, to cross-compile for another target device, or to build a library instead of an executable, or to add a configuration option, or whatever. Or they are going to find that they need to optimise the build because it's too slow. And without these tools, those tasks are ridiculously complicated. And lastly, it, would be wonderful if I could take an autotools or pure-makefile based project, and convert it to this system with a simple import statement - the resulting project build file wouldn't need to be particularly beautiful, because, with all those other tools that I listed above, I could clean things up by hand after the import. The bad news is that as far as I am aware, no such tool exists. I assume it must be a hard problem to solve, because the pain that build systems cause is a real and ongoing concern for millions of developers around the world. If you're the sort of person that writes these types of system, I would be your customer. Make the basic build system - where you can create and build projects - free, and make the debugging tools something that you have to pay for. I for one would be your customer. All of which leads me to the bad news: I've never yet encountered a system that does these things, which is why I needed to include a plea to someone to make one.
oso2k 12y ago
I like your watch target. I implemented something similar [0] with watch (bash builtin or GNU watch) & time. start_ci: watch time -p make clean all & echo $$! > tmp.ci.pid stop_ci: kill -9 `cat tmp.ci.pid` Then you can start continuous integration by doing make start_ci Then you can stop continuous integration by doing make stop_ci Obviously, this is inspired by rc.d scripts. [0] https://github.com/lpsantil/rt0/blob/master/Makefile#L117 https://github.com/lpsantil/rt0/blob/master/Makefile#L117
- harry8 12y ago
  aside: Please no `backticks` $(cat tmp.ci.pid) is standard and never worse than backticks. Indifferent in your example but frequently it's vastly safer. backticks need to be deprecated.
  - shabble 12y ago
    whilst this is good advice for shell scripting, are you sure it applies as worded to the snippet you're replying to, given how Make uses $() itself for variable referencing?[1] $$() might work, but untested. [1] https://www.gnu.org/software/make/manual/html_node/Reference.html#Reference https://www.gnu.org/software/make/manual/html_node/Reference...
    - harry8 12y ago
      yes, absolutely $$() works in a makefile. Backticks just need to die.
    - untothebreach 12y ago
      yea, at least with GNU Make it is probably best to use $(shell cat tmp.ci.pid)
  - oso2k 12y ago
    Haha. Good catch, I actually use $(shell cat tmp.ci.pid) to capture the PID in a var $(TMPCI) if you look at the actual Makefile I linked.
andrewchambers 12y ago
+1 for teaching me about the inotifywait command.
david-given 12y ago
I've had good luck with self-writing makefiles, where I write macros to generate the rules. Here's an example: http://sourceforge.net/p/wordgrinder/code/ci/default/tree/Makefile http://sourceforge.net/p/wordgrinder/code/ci/default/tree/Ma... While it looks crazy, it has the advantage that it avoids pattern rules completely, which means that everything's explicit and we get to avoid some of make's more annoying misfeatures. It makes the makefiles vastly easier to reason about, as well as allowing things like building the same binary multiple times with different flags, which is really hard with traditional makefiles. The downside is that it looks crazy (and GNU make macros are not what you'd call well-designed, either). As for switching to a different build system... like what? Every other build system I've seen is horrible in other ways, and make is at least ubiquitous. Every time I need to install some software which uses a non-make build system I get this horrible sinking feeling as I have to go and install the thing I need to install the thing. ... Incidentally, the craziest thing I ever did in make was this: http://cowlark.com/2013-10-19-insane-make/index.html http://cowlark.com/2013-10-19-insane-make/index.html I wrote a compiler for a statically-typed language which targeted GNU make macros as a backend. Surprisingly, it actually worked, although I never got round to finishing the arbitrary-precision maths library needed by the runtime system...

sdevlin 12y ago

> something serious What do you recommend? Autotools, bespoke shell scripts, or something else entirely?

danieljh 12y ago
For C++, unfortunately CMake is the best option there is it seems. For LaTeX there is latexmk. Clojure has Leiningen. You see, it heavily depends on your preferred environment.
- e12e 12y ago
  FWIW when I tried out qmake for a toy c++ project, it's the first make tool for c++ that actually just worked[1] for a simple command-line app. CMake works too, but not without fighting the horrible syntax of CMake first. And make... well it works, but at what price to your soul? ;-) [1] The documentation is actually a little dense, as qmake is a tool capable of building "real projects", but I found that a simple qmake -project && qmake && make (I think, at least you need a project file, and the let qmake make a makefile, and then use that...). http://doc.qt.io/qt-5/qmake-running.html http://doc.qt.io/qt-5/qmake-running.html See also: https://web.njit.edu/all_topics/Prog_Lang_Docs/html/qt/qmake-manual-3.html https://web.njit.edu/all_topics/Prog_Lang_Docs/html/qt/qmake...
  - pubby 12y ago
    premake is another tool that just works for C++, but it's not as flexible as some of the other build systems and so I don't use it.
  - arunc 12y ago
    At last, I find someone who uses qmake on HN. I've been using qmake for 4 years now. At first I started experimenting with it for a small project. The learning curve was quick and eventually fell in the comfort zone it created. Now I use it for large scale C++ projects and I've never looked back for other build tools, not even CMake. Surprisingly, I never understood why KDE project that uses the complete Qt ecosystem doesn't use qmake but rather settled to CMake.
    - realharo 12y ago
      Does qmake deal with finding the dependencies and automatically adding the include paths, libraries, etc. for them? As far as I know, you need to stick the compiler and linker flags manually into qmake, which basically means that it works on your machine, but may break on anyone else's system. This is what a lot of the complexity inside cmake is addressing - differences in build environments.
      - e12e 11y ago
        I think the answer is: "It depends.". From some searching, it looks like cmake has better cross-platform support, and is (unsurprisingly) more powerful when you need to do something a little gnarly. That said, it appears (never had need to test) that qmake works fine with pkg-config: http://doc.qt.io/qt-5/qmake-project-files.html http://doc.qt.io/qt-5/qmake-project-files.html In my experience (mostly from compiling from upstream source, when something isn't available in Debian and/or backporting for personal use) there are different kind of libraries, some behave better than others (eg: easy to install under $HOME/opt with xstow -- as I prefer to /usr/local, as the latter needs root and/or rw-privileges on /usr/local). I've yet to find any pattern for when things just work, and when things don't (the real reason typically being some hard-coded paths or other nastiness -- I just mean some obscure projects work fine, some big ones fail miserably). So I guess YMMV -- but for now, qmake is the tool for building simple c++ I've found that is simple, for simple projects. I also use CMake (preferably with ninja) -- but I don't really like the CMake "language". Maybe what we need is a CMake-generator? Then we can generate CMake-files that generate ninja files that build our code! ;-)
mackwic 12y ago
It will depends on you platform and technology. I can only recommend you to _not_ be fancy and stick with the conventions or else you could have a lot of trouble to interact with dependencies. By dependency I mean anything your program would need to run: from system libraries, headers, local libraries linked either statically or dynamically, or even syscall. A lot of things can go wrong, our whole software cathedrals are build upon years of conventions and patches. Anything can break. Don't even try too look what `ld(1)` is doing. Autotools has never be a great tool, only a necessary evil for when you need to package cross-Unixes software. I heard that CPack (http://www.cmake.org/Wiki/CMake:Packaging_With_CPack http://www.cmake.org/Wiki/CMake:Packaging_With_CPack) do the job while being exactly as good as CMake (which can be a compliment... or not. YMMV). So, if you use Rust, use Cargo, with Java use Maven, with C# use MSBuild, with ruby use Rake, etc. And C/C++ ? Well, for once if you can chose you're lucky. You can try CMake or premake. The only thing you must do is get away of most of the Google's build projects: Gyp, Lunch, Ninja, etc. I have horrible experiences with those. Even worse than Rubygem's native compilation, which is quite a performance.
- bla2 12y ago
  What's wrong with ninja? It's CMake's best output format as far as I know. A lot more enjoyable to use than, say, msbuild.
ayuvar 12y ago
For C++, I'm a long-held adherent of SCons. You can make some horrendous messes but it's nice to have Python around instead of having to learn another intermediate language as in CMake's case.
- chx 12y ago
  I'll make my reply short: > adherent of SCons. o_O > You can make some horrendous messes :nod:
  - coherentpony 12y ago
    In fairness, you can do that in every build system. All build systems are awful. Pick the one you know best.
antimagic 12y ago
This is a good question. After too many years experience of fighting with build systems, I have come up with one overarching requirement - the build system needs to be debuggable. I need to be able to easily identify why a particular file was built. I need to be able to easily recover the command line that builds a generated file, as in if I know that I have a source file called foo.c, I need to be able to easily obtain the command line that compiles foo.c to foo.o, so that I can see the options that were used. I need to be able to easily see how variables are constructed. Something like being able to put a watch on them, so I can find the lines of build files that modify them. You need these things because you know what? One day someone else is going to want to modify your build system, to cross-compile for another target device, or to build a library instead of an executable, or to add a configuration option, or whatever. Or they are going to find that they need to optimise the build because it's too slow. And without these tools, those tasks are ridiculously complicated. And lastly, it, would be wonderful if I could take an autotools or pure-makefile based project, and convert it to this system with a simple import statement - the resulting project build file wouldn't need to be particularly beautiful, because, with all those other tools that I listed above, I could clean things up by hand after the import. The bad news is that as far as I am aware, no such tool exists. I assume it must be a hard problem to solve, because the pain that build systems cause is a real and ongoing concern for millions of developers around the world. If you're the sort of person that writes these types of system, I would be your customer. Make the basic build system - where you can create and build projects - free, and make the debugging tools something that you have to pay for. I for one would be your customer. All of which leads me to the bad news: I've never yet encountered a system that does these things, which is why I needed to include a plea to someone to make one.

oso2k 12y ago

I like your watch target. I implemented something similar [0] with watch (bash builtin or GNU watch) & time. start_ci: watch time -p make clean all & echo $$! > tmp.ci.pid stop_ci: kill -9 `cat tmp.ci.pid` Then you can start continuous integration by doing make start_ci Then you can stop continuous integration by doing make stop_ci Obviously, this is inspired by rc.d scripts. [0] https://github.com/lpsantil/rt0/blob/master/Makefile#L117 https://github.com/lpsantil/rt0/blob/master/Makefile#L117

harry8 12y ago
aside: Please no `backticks` $(cat tmp.ci.pid) is standard and never worse than backticks. Indifferent in your example but frequently it's vastly safer. backticks need to be deprecated.
- shabble 12y ago
  whilst this is good advice for shell scripting, are you sure it applies as worded to the snippet you're replying to, given how Make uses $() itself for variable referencing?[1] $$() might work, but untested. [1] https://www.gnu.org/software/make/manual/html_node/Reference.html#Reference https://www.gnu.org/software/make/manual/html_node/Reference...
  - harry8 12y ago
    yes, absolutely $$() works in a makefile. Backticks just need to die.
  - untothebreach 12y ago
    yea, at least with GNU Make it is probably best to use $(shell cat tmp.ci.pid)
- oso2k 12y ago
  Haha. Good catch, I actually use $(shell cat tmp.ci.pid) to capture the PID in a var $(TMPCI) if you look at the actual Makefile I linked.

andrewchambers 12y ago

+1 for teaching me about the inotifywait command.

david-given 12y ago

I've had good luck with self-writing makefiles, where I write macros to generate the rules. Here's an example: http://sourceforge.net/p/wordgrinder/code/ci/default/tree/Makefile http://sourceforge.net/p/wordgrinder/code/ci/default/tree/Ma... While it looks crazy, it has the advantage that it avoids pattern rules completely, which means that everything's explicit and we get to avoid some of make's more annoying misfeatures. It makes the makefiles vastly easier to reason about, as well as allowing things like building the same binary multiple times with different flags, which is really hard with traditional makefiles. The downside is that it looks crazy (and GNU make macros are not what you'd call well-designed, either). As for switching to a different build system... like what? Every other build system I've seen is horrible in other ways, and make is at least ubiquitous. Every time I need to install some software which uses a non-make build system I get this horrible sinking feeling as I have to go and install the thing I need to install the thing. ... Incidentally, the craziest thing I ever did in make was this: http://cowlark.com/2013-10-19-insane-make/index.html http://cowlark.com/2013-10-19-insane-make/index.html I wrote a compiler for a statically-typed language which targeted GNU make macros as a backend. Surprisingly, it actually worked, although I never got round to finishing the arbitrary-precision maths library needed by the runtime system...