OSNews

"I don't think it's caused by header files, I'd say it's actually caused by linking issues; and I wouldn't call this a hack."

That's correct. Makefile controls dependencies (questions if everything or just a part of a project needs recompile), proper linking (here, header files affect) and conditions at compile time (compiling for different architectures, with debug enabled, with optimization, with certain features turned off or on etc.).

"Some of the complexity of making a working makefile is finding header files; but it's not an issue of header files: It still exists in Java for example with $CLASSPATH."

The access to header files belonging to the system is usually done via the include/ directories with their default settings, making them available using the #include <...> macro, or calling them absolutely with #include "...", which should be avoided.

Makefile automates parameter calls for cc and ld, such as -I <include path>, -L <library path> or -l<library name>.

"In my opinion the trouble is a lack of separation of concern. The makefile is definitely well suited to building code: Most of us could probably make a makefile to build a medium complexity project for one system. The trouble comes into effect that there's no effective separation between makefile commands and the shell and so you end up dependent on the OS."

Usually, /bin/sh (default Bourne shell) is invoked for every command in Makefile. If you want to place them into more than one line (starting with tab), you need to end the line with a backslash, otherwise you're running into trouble. Access to shell variables is a bit complicated; while you can access make variables via $(NAME), you need $$NAME for a shell variable which is only active for the current line (representing a shell command call).

I use Makefiles for more than programming, such as for LaTeX or HTML builds of larger document projects. Surely make is not inteded for this kind of work, but it's quite nice for such kind of work, as long as you know what you're doing.

"One place you get stuck is installing, and another is the joy of filling in the -I and -L's."

This is a problem in fact. You mentioned some suggestions. Today, the Makefiles for the FreeBSD ports collections serve this purpose. They do not only compile programs, they also:

# make update
# make fetch
# make extract
# make patch
# make uninstall
# make reinstall
# make install
# make package
# make clean

You surely know what this does in reality. It works fine with the ports, but applications not included in the ports usually do not have this functionality.

"I don't think syntax actually needs to change much."

I'd like to get rid of the tab character, instead, having some kind of grouping mechanism as in C, just as an example:

foo.pdf: foo.tex bar.tex blah.eps {
... commands here...
}

"But I would prefer to separate make from the shell in typical sequences with some extra keyword to get shell integration (and a big warning about how you're going to break compatibility in books)."

So make must be able to realize the command content independent from the actual shell (default shell?), but calling a shell to run a command is the usual way of doing things here. On the other hand, explicitely calling a shell (or entering "shell mode") would be good to have access to shell environment and variables. It would allow to write commands according to the shell languace (such as csh or zsh commands).

"Edit: And of course osnews doesn't help me out and it's all flat, just pretend it's indented if you see "->"."

As I mentioned - or complained :-) - before, it would be great to have the <pre></pre> HTML tags enabled in order to post source code or shell fragments in an appealing way.

Edited 2007-04-17 22:24