Jonathon McKitrick wrote:
I will answer here, but be aware that you're getting all of my
prejudices too, so take things with a grain of salt.
First item deals with the .path statements, and more specifically, your
use of relative addressing. It's my own experience that, if you use
relative addressing, you make troubleshooting a broken build much more
1) relative addressing means you have to be forever translating paths in
listings, and very often the number of include paths gets to be rather long.
2) all the stuff like "../.." in listings is quite difficult to read
3) with the $(.CURDIR) variable, it's extremely easy to use absolute
addressing. You can also make use of $(.OBJDIR), and it's not so hard
to make makefiles that work off of read-only sources like cdroms.
The Make(1) man page doesn't show "include", the advertised command is
".include". If you use .include, then you can modify your make, if you
want, with the -m argument, and so get specific directories to be added
to the search path for make include files. I'm not sure, but I think
that raw "include) is more a gmake item, and it's absolute addressing.
Don't forget the "-" argument, so that you allow includes to fail if
they need to, like for generating dependencies.
Well, did you look at the files in /usr/share/mk, and specifically
bsd.dep.mk? You can even use the FreeBSD sources to figure out (to use
as examples) how things should work.
Don't forget the use of -m, because you can use it to add to the include
directory list, and so be able to add your own include files without
corrupting the system files.
I honestly keep on switching back and forth, between thinking that the
best make is bmake, or gmake. They both have key items that make them