Writing own Makefiles

Which one of three above should I use and why?

Attached: 43107265.gif (460x460, 90.12K)

Other urls found in this thread:

ninja-build.org/
doc.cat-v.org/plan_9/4th_edition/papers/mk
twitter.com/NSFWRedditVideo

Premake

None, because you're too retarded to ask in QTDDTOT.
>>>/g/

Write your own

for what you are doing a normal make will probably work

Are you a nigger that needs handholding to build your programs? I rewrite the command line from scratch every time. This ensures that I know what goes into my programs, and I can change the flags on the fly. I've also found that make has a tendency to either rebuild too often or not often enough. Sometimes it will rebuild the whole project because of a minor change to a header. Sometimes people forget to add dependencies on their targets (includes, libs, the makefile itself) for which the only solution is to rebuild the whole project.

Cmake etc make things even worse by requiring you not only to not build things yourself, but by making you use an intermediary before touching the makefile. This makes small changes like adding a new lib more work than they need to be.

...

(checked)
Sik b8 fam

Attached: glow in the danks.png (400x372, 94.11K)

Probably cmake. It'll automate making the makefiles for you. I've never used automake, so I can't vouch for it.

Some C turboautist will probably tell you "always write your own makefiles". Unless it's a really small program, don't. There's a reason why we automate it now.

Having fewer dependencies is always better, so go with hand-written first, and only transition if your project becomes unmanagable otherwise. Make sure you read the make manual, in particular about function and automatic variables, so many things can be written quite elegantly.

For my own stuff I write my own since it's easier. But that wouldn't work for a large project. I hate cmake due to it trying to be too clever for its own good, but both it and autoconf are used by several projects so use whatever you prefer. Just don't use some retarded make system that only one google retard uses or some shit like that.

Makefiles and supporting only POSIX.

...

ninja-build.org/

make - just werks. Clean and simple for simple cases, but starts getting ugly fast. If you started using '$(call ..)', you should have abandoned make long ago

automake - free software equivalent of any bespoke corporate build system. Supports every case you might need, but learning correct ritual takes more time and pain than doing it from scratch. If you do everything right - it works better than you could expect; if you do single mistake - you go into world of frustrated suffering.

cmake - fuck it. Uglier than make for simple cases, no less ugly on complex, as bloated as automake. No reason for it to exist.

Attached: 61169f3e5b6dcd9511e8204b2b1b1ca0b3e97502d05ecb798e664d493a94d5a6.png (293x343, 84.87K)

doc.cat-v.org/plan_9/4th_edition/papers/mk

gcc

If you're distributing software I'd recommend plain make or cmake, since it's easy for the end user and you won't get retards complaining about builds failing as often. If you're not distributing it then just use what you're the most comfortable with.

Make syntax is far uglier than cmake. Automake exists because Make syntax isn't so easy to grok beyond the basics. Cmake syntax and functions are much easier to trace.

You forgot the ultimate enlightenment tier: GNU make or bmake.

bash

(srs-- most of my development is embedded boards, where compile/link/build of the whole project is just a second or two.)

I like cmake because it has prettier build output

Please whatever you do please do not use cmake it's terrible for the users and its bloated as fuck.

How so? I'm curious because I've never actually used/installed cmake and probably never will have a use for it.

Write your own make files because it's simple and quickly done and anyone who lurks here is not going to write any complex software ever, anyway

Cmake is theoretically awesome but not quite so in practice. Last time I used it documentation was fairly shit and you can bet your ass that you'll end up writing a bunch of platform-specific shit for anything non-trivial. The syntax is pretty horrid and you'll have to learn it if you need to write any custom library finding module (which fairly likely).

scons is pretty epic

just use UNIX makefiles which can be run in any make.

touch Makefile

Makefile:
CFLAGS=-O69 -optimize-omg -other-shitCXXFLAGS=-std=c++11 -other-shitall: shit1 shit2shit1: dependenciesoffoo gcc foo $CFLAGSshit2: dependenciesofbaz g++ baz $CXXFLAGS

if you maintain your makefiles well it won't become ugly unlike the other fag says, unless it's a bloated piece of shit with 239487 dependencies and alternative switches and options

You shouldn't need make files if you are programming your own software. Make files are for people who are outside of the development environment but need the ability to compile specific options. That's all the purpose they serve.

I don't know what kind of non-trivial build requirements you have that aren't already covered in Cmake. Can you point to any public projects that cannot be solved with the existing Cmake system? Is your only objection about writing Cmake modules for searching libraries?

And every time you #include a header file you have to add it as a dependency in your makefile as well to keep in sync.

This, and easier cross-compiling are why I went with Cmake.


I searched through Arch PKGBUILDs to find projects that use it for ideas on how to write mine. The same can be used to figure out any build system from projects that use them.