Live data from Hacker News

A Simple Makefile for Medium-Sized C/C++ Projects

spin.atomicobject.com

71–80 of 120 posts

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#71

"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!

Projects that make blind use of VPATH are a pain. You can't have the same filename in two different directories! It's a hack at best, and using explicit paths (as this Makefile does) is a lot more reliable.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#72

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.

I use CMake for everything-that-isn't-$work-now because that's the only thing CLion supports. Even at work I've taken to creating my own CMakeLists.txt so I can get CLion support. I like the IDE that much.

It's not perfect, as others have touched on. But it overall satisfies my requirements and I can usually get things done with it.

Being a Google employee, I'm somewhat partial to Bazel (https://bazel.io/) which is based on what we use internally. I've started to ponder what it would take to write a CMakeLists.txt generator for it.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#73
post #69

Earlier quoted context omitted.

> installing into a DESTDIR > setting custom CFLAGS/LDFLAGS > changing prefix, libdir, sysconfdir > cross-compilation Pretty much all of this can be done trivially in a makefile, using a very innovative construct called "variables". > parallel builds make -j. Works especially well if you have working dependencies. This makefile does. > conditional features make has ifdef... Granted this makefile uses find to discover…

Can be done. The question is will the half-assed Makefile that a developer wrote for themselves do any of those things? And I can tell you from bitter experience that is very very unlikely. Plus I will still have to spend the time to understand the Makefile, which I won't need to do if they'd used an established build system in the first place.

We can agree that half assed makefiles are bad. I don't believe in throwing out the tool on that basis. If that were the bar, we might as well not write any software in any language with any tool.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#75
post #10

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.

[deleted]

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#76

I'm going to take this opportunity to rant about sad state of C++ open source. I would really really like to write some C++ but I'm not a C++ guru; so I tried installing facebook/folly and facebook/fatal on my Mac OS. That just doesn't work. It wasn't written cross platform and it probably never will. So I spun up a ubuntu VM and tried there. fatal compiles, folly still doesn't... And so ends my brief foray into C++.…

Have a look at Conan [https://www.conan.io/] then. It has solved the problem you described and its usability is great

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#77
post #36
post #29

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.)

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.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#78
BSD make (bmake) and its .mk includes are really simple, it's basically make with batteries included. Many makefiles may be reduced to two lines while no new syntax is introduced:

  PROG=${.CURDIR:T}
  .include 
It indirectly extends original BSD make. There are some syntactic differences from GNU make, but no big depart.

See http://www.crufty.net/help/sjg/bmake.htm

Here is a custom BSDmakefile for my website, a more extensive example where the mk libraries can't apply:

  # makefile -- Build the website.
  #
  # $Id: makefile,v 1.10 2016/08/15 12:55:49 igk Exp $
  #
  #
  
  M4=m4
  AWK=awk
  SED=sed
  TIDY=tidy5
  TARGS=-i -utf8
  
  include config.mk
  
  # Common templates for each output file.
  MACROES=html.m4 config.m4
  TMPL=${MACROES} meta.m4 header.html.m4 HERE footer.html.m4
  HTML+=${LISTS:S/$/.html/}
  ATOM=${LISTS:S/$/.atom.xml/}
  OUT=${HTML} ${HTML:S/html$/&.m4/} ${HTML:S/html$/&.dirty/} ${ATOM}
  
  .MAIN: ${HTML} ${ATOM}
  
  # Generate lists.
  .for L in ${LISTS}
  $L.txt: $L.list
  	${AWK} -f list.awk ${.ALLSRC} > ${.TARGET}
  
  $L.atom.xml: $L.list
  	${AWK} -f atom.awk ${.ALLSRC} \
  		| ${M4} ${MACROES} - \
  		| ${SED} '1,2d' > ${.TARGET}
  .endfor
  
  .ifndef NOTIDY
  
  .for P in ${HTML}
  $P : ${P}.dirty
  	${TIDY} ${TARGS} ${.ALLSRC} 2>/dev/null > ${.TARGET} || true
  .endfor
  
  .for P in ${HTML}
  $P.dirty : ${TMPL:S/HERE/$P.m4/}
  	$(M4) ${.ALLSRC} > ${.TARGET}
  .endfor
  
  .else
  
  .for P in ${HTML}
  $P : ${TMPL:S/HERE/$P.m4/}
  	$(M4) ${.ALLSRC} > ${.TARGET}
  .endfor
  
  .endif # NOTIDY
  
  .for P in ${HTML}
  ${P}.m4 : ${P:S/html$/txt/}
  	$(AWK) -f page.awk ${.ALLSRC} > ${.TARGET}
  .endfor
  
  clean:
  	rm -f ${OUT}
  
  .PHONY: uuid pub ssh anal
  uuid:
  	sh ./make-uuid.sh
  pub:
  	sh ./publish.sh
  ssh:
  	sh ./s.sh
  anal:
  	sh ./analytics.sh

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#79
post #69

Earlier quoted context omitted.

> installing into a DESTDIR > setting custom CFLAGS/LDFLAGS > changing prefix, libdir, sysconfdir > cross-compilation Pretty much all of this can be done trivially in a makefile, using a very innovative construct called "variables". > parallel builds make -j. Works especially well if you have working dependencies. This makefile does. > conditional features make has ifdef... Granted this makefile uses find to discover…

Can be done. The question is will the half-assed Makefile that a developer wrote for themselves do any of those things? And I can tell you from bitter experience that is very very unlikely. Plus I will still have to spend the time to understand the Makefile, which I won't need to do if they'd used an established build system in the first place.

I imagine most projects will never leave the hard drive they're first written to. Writing a basic "half-assed" makefile that works for the initial author is fine. If a project turns out useful, rewrite the makefile as people need the compatibility. There's little point in wasting the time when you're just starting out.

Re: A Simple Makefile for Medium-Sized C/C++ Projects

#80
post #41

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.

That's the ideal situation, yes, but god help you when something goes wrong.

It's not that hard. I recently had to debug a memcached configure.in script. But, I consider myself a C programmer, so that fact might be source of bias.
Post reply on HN