Re: [Raypp-general] Makefile

[Tim M. <ti...@se...>]

On Monday 15 Nov 2004 23:24, Martin Reinecke wrote:
> > Isn't that the job of make to worry about? I mean, its algorithms are
> > impenetrable but once you get it set up there isn't a problem.
>
> make doesn't know automatically about the inter-file dependencies of the
> C++ files.

Obviously make can't determine the dependencies of the files from scratch, but 
once you have your makefile configured it ought to work. The dependencies 
shouldn't change that frequently relative to the rate of development work.

A simpler solution occurred to me though - just set the makefile to rebuild 
all targets every time and use ccache (http://ccache.samba.org/) to figure 
out whether the file actually needs to be recompiled. This leaves the 
makefiles completely transparent and eliminates all unnecessary compiling.

> You can generate dependency information for use with make by 
> using "g++ -M file.cxx" or similar, but this is not portable to other
> compilers, and it also takes some time. So if you develop Ray++ on Windows
> without g++, you won't have a way to keep your dependency information up to
> date.

But if you're developing on Windows without using the GNU toolchain then a GNU 
makefile is no use to you anyway. And since (as far as I'm aware) there are 
no UNIX tools that can read NT makefiles, the two systems will always be 
orthogonal. This in itself is no reason to cripple the GNU makefile.

An alternative would be to use a proper cross-platform build tool like Jam 
(www.perforce.com), which has other advantages as well, but has the downside 
of making it a lot more difficult for someone who has only a casual interest 
in Ray++.

> I'm against hardwiring of dependencies in the Makefile, because these 
> dependencies would have to be updated by hand and will get out of date
> almost immediately.

I agree with you up to a point. The way I see it, the job of the build tool is 
to make development as efficient as possible. The various solutions we've 
discussed here all make a trade off between efficiency of day-to-day 
development and the complexity of maintaining the build environment. Your 
solution is a bit too far on one extreme for my liking, but as I say I'm 
happy to stick with it (or at least use my own tools) if everybody else is.

Tim