Incremental compilation is nice, but expressing dependencies between objects, sources and headers is a pain in the ass. gcc -M is utter garbage not unlike GCC itself and generates thirty to fifty useless prerequisites per file in case one of the system headers changes. Gotta make sure, the user might be retarded after all.
How do I write good make files and still have time for actual programming?
I don't care. Just write a shell script. If you need -j then use & at the end of commands.
Name:
Anonymous2015-02-21 0:14
Don't use include guards, this forces you to only #include the things you need and do it explicitly. This makes it easy to track dependencies, and you can write a simple script to grab the local includes from every C file.
Or use gcc -MM
Name:
Anonymous2015-02-21 3:12
>>1 Why do you care if generated output you never read contains a bunch if system headers? If you do happen to update your system libraries, not updating the targets that include them could produce incorrect results. Stop pretending you know better and just let the tool do its job.
>>2,3 No make replacement addresses all of make's shortcomings without also introducing new ones. For many projects there is no net benefit in switching to something else.
>>4 Sure; who needs incremental builds or error handling? Build systems that take five minutes to rebuild after you change a single file and don't halt on errors are just great!
>>5 gcc -MM is better, thanks. Still kind of awkward, but at least it's not shit. Dropping include guards sounds insane on the surface, how viable is it actually when a program becomes bigger?
>>6 I'd use autoconf if unreadable machine-generated garbage was acceptable. Performing a make clean after a system update is not hard, and even if it were, the error class it prevents is rather minor: Changes of system headers will most likely trigger compilation failures or be inconsequential. Something minor like that isn't worth such a sacrifice in readability.
>>7 Long dependency lists are not nearly as painful as the whole of autoconf. Thanks for at least admitting that omitting the system headers can cause strange build failures.
If you're really so annoyed by this, perhaps you should consider using a libc whose headers aren't a tangled heap of shit.
>>8 I've never written a shell script to build anything. I've been forced to use some written by others however, and they were all shit. It's the nature of the language.
Dropping include guards sounds insane on the surface, how viable is it actually when a program becomes bigger?
I've recently come around on this. Not using include guards has the very useful property of making circular dependencies between headers immediately evident to the programmer. In order to compile without include guards, each compilation unit must must include all headers it uses in topologically sorted order. If a dependency cycle exists, no such ordering will be possible and the programmer will need to break the cycle before they can continue.
Any C project of sufficient size will develop awful dependency cycles if include guards are used. Such cycles typically manifest as simple code changes introducing bizarre compile or link errors which must then be resolved with great violence. Maintaining the header ordering in a well designed project that does not use include guards is not nearly as painful as dealing with a neglected dependency cycle in a poorly designed project that does.
Name:
Anonymous2015-02-25 7:05
Wouldn't it be better to use a guard that complains and halts compilation then?
That would work, but you shouldn't need to if you don't allow headers to include other headers.
Name:
Anonymous2015-02-25 7:26
checking frozenvoids headers what kind of shit he uses every single header contains pragma once
Name:
Anonymous2015-02-25 7:41
Plan 9 C is conventionally written with no include guards, and no recursive inclusion.
If many source files in a project are including the same list of headers, they can be factored out into a single #include "stdinc.h", which doesn't meaningfully violate the convention.
I thought it was horribly barbaric when I was first introduced to it, but now I really appreciate it. On Unix there are always semi-folkloric conventions about the order in which headers should be included, but you'll have a double-inclusion no matter what when one header depends on another.
Unless your program is ENTERPRISE QUALITY the difference between an incremental build and a full recompile should be negligible. Shell scripts and batch files for life.
Name:
Anonymous2015-02-25 16:03
Don't bother tracking individual headers. This is all you need.
OBJS = prog.o snake.o HDRS = hax.h anus.h
$(OBJS): $(HDRS)
.c.o: $(CC) -c $<
progsnake: $$(OBJS) $(CC) -o $@ $(OBJS)
Name:
Anonymous2015-02-25 16:39
The way the svope of headers are treated in C is the stupidest shit ever devised. It's more of the same old shit usual of standards assholes. Crap that is not useful to anyone at all, but is going to end up crushing you under the weight of years of stupid decisions. #pragma once should be default behavior.
That would work, but you shouldn't need to if you don't allow headers to include other headers.
That's what it fucking does!
You want policy without enforcement? Why bother writing C? Just use BCPL. Less pesky types for the compiler to complain about.
>>16 Double-inclusion is fine if you eliminate the redundant includes and don't use state in headers. State and cycles are the only real problems. But y'all want state. You praise Plan 9 while you use GNU feature macros in header files.
>>20 Header guards and pragmas are all you get, but it's still good. Want to fix the problem outright? Modules. Need feature macros? Parameterize or recompile the module.
>>21 Enforcement is good. It's just not very reliable enforcement if you have to remember to add a check to every header. It's equally easy to remember that headers should never include other headers.
Sadly I don't think there is much hope for modules. It is a testament to the uselessness of the C++ community that they have been willing to add endless new syntax for trivialities while leaving such a fundamental problem unaddressed.
Splitting up files in C or C++ is the root of all evil and unneeded complexity. Your whole program ought to be one single source file. Anything under 100k sloc = one file. If this is too difficult for you, I suggest using a better editor than Sublime. It saves a massive amount of headache to only have to deal with linking external libraries in your makefile rather than linking your own code together.
The same applies for Javashit code btw since it shares the same compilation model.
>>27 Linking together your own code is extremely trivial.
Name:
Anonymous2016-06-16 20:47
>>28 It's trivial to do but more complicated in the long run. Soon you'll be #include'ing shit you already #include'd especially if other people are coding with you.
Name:
Anonymous2016-06-16 21:28
>>27 So you suggest not having separate header and implementation files for C++ classes?
Name:
Anonymous2016-06-16 22:10
>>30 Yes. Emacs bookmarks or Vim folds can help simulate the convenience of multiple source files (there's no other reason besides convenience).