Re: [Raypp-general] Makefile

[Martin R. <ma...@MP...>]

Hi Tim!

> A brief and rather unscientific investigation into the relative times 
> convinced me that a one-off full compile is indeed much quicker when done as 
> a single translation unit. However, it seems to me that the average user of 
> raypp is going to compile quite a few times, as people aren't going to be 
> using it out of the box as-is.
> 
> Furthermore, it seems to me that we want to avoid wasting time during the 
> development cycle (when you usually have nothing better to do than sit and 
> wait for a build) even at the expense of it taking longer for people to do a 
> one-off build.
> 
> I think a reasonable compromise would be to build multiple translation units 
> in the CVS, but possibly release tarballs with the fast compile switched on. 
> Any thoughts?

If we can get the dependencies right without spending too much CPU time
on them, compilation of individual files is certainly the best solution.
We won't need the big transltion unit any more then.

> > But in this case all the dependency rules must be regenerated, 
> > which also takes some time.
> 
> 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. 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.
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. 

> > > Does anyone object to me submitting this?
> >
> > Could you please upload it as a sourceforge patch first?
> 
> I didn't know this was possible. I'll have to tidy up the makefile a bit and 
> investigate how to achieve building a sourceforge patch.

I'm not sure how it works, but Andreas has done it already for his flexible
sampling class. But sending the modified files to the mailing list is
also fine, of course.

Cheers,
  Martin