Re: problem with genmarshal rules in libbonobo

[Darin Adler <darin bentspoon com>]

On Tuesday, August 14, 2001, at 06:00  AM, Michael Meeks wrote:

> > Darin Adler <darin bentspoon com> writes:
> > > I noticed that the genmarshal rules in libbonobo use a cmp command
> > > to check if gnome-canvas-marshal.h is the same as last time, and
> > > leave it untouched if so.
>
> 	Having seen stamp files horribly misused in the past, can I ask
> precicely _why_ we need to do all this strangeness ?

My point was that the incorrectly-done "cmp" sophistication needs be 
removed from the libbonobo makefile, because the version in there leads to 
re-running the genmarshal tool every time. I did not mean to say that we 
need the more sophisticated solution with a stamp file. You'll note that 
for libgnomecanvas, where I recently had to add some marshal functions 
(which I chose to keep private), I used a very simple flavor (maybe I got 
something wrong).

Havoc kindly answered my implied question of "how can you do the more 
sophisticated way correctly", which is useful for me to know for future 
reference.

> 	It just seems like a horrendously convoluted mess for not much
> gain - or am I missing something ?

One thing you might be missing is the similar but distinct situation where 
the generated file is less likely to change even when the source file 
changes. In those situations, it's worthwhile to have a carefully written 
makefile that won't recompile everything if, for example, the IDL compiler 
changes, but what it writes out for your particular IDL files does not. It'
s possible that we don't have situations like that in GNOME source code 
right now.

Another case where it's very useful to do this carefully and correctly is 
if you have generated files that depend on a lot of other files -- for 
example if genmarshal decided what to generate by looking for identifiers 
in .c files instead of having an explicit marshal list file. In that case,
 you might often be re-generating the files only to get an identical 
result. It's useful in this case to not have to rebuild everything just 
because one file changed.

    -- Darin