[Xapian-devel] Re: [Xapian-commits] 7891: trunk/xapian-core/

Olly Betts olly at survex.com
Thu Mar 8 19:49:09 GMT 2007


On Tue, Mar 06, 2007 at 05:18:27PM +0000, Richard Boulton wrote:
> Olly Betts wrote:
> >On Tue, Mar 06, 2007 at 09:07:04AM +0000, richard wrote:
> >>* HACKING: Note on running preautoreconf and autoreconf to keep SVN
> >>  builds working.
> >
> >What's the scenario in which you have to run them by hand?  I'd rather
> >fix this to just work automatically than document deficiencies in the
> >build system.
> 
> It was a problem with generate-exceptions.in not being run to generate 
> "error.h".  On reflection, it's possible the build this occurred in 
> hadn't been configured with "--enable-maintainer-mode", which would 
> explain why the build system didn't get updated automatically.

I had a quick look.  I wonder if the issue is that the dependency is on
generate-exceptions.in not generate-exceptions.

I did this consciously to avoid rebuilding error.h needlessly and thus
forcing a rebuild of most of the library.  But actually configure
shouldn't update the timestamp on generate-exceptions if the contents
hasn't changed, so I think that's bogus reasoning.

Even if that was an issue, it would be better to just write the new
error.h to a temporary file and then check if it's different before
replacing an existing error.h.  I've changed the dependency (and another
similar one) now, and we can see if the "error.h hasn't really changed"
check would be useful.

> >I fixed a problem a few weeks ago with removed files which were listed
> >in dependencies preventing "make" from working, so if you were having
> >such problems with 0.9.10, this is probably already fixed in trunk.  I
> >didn't backport this change, since it's only relevant when building from
> >SVN.
> 
> Sure.  However, I think it's fair to say that there have often been 
> problems with getting this to work automatically after relatively major 
> changes to the build system have been made (eg, when new scripts have 
> been introduced to generate files), and while we should continue to try 
> and fix such problems, I thought it might be helpful to document a way 
> out of the situation when it does occur.

It's true that this can be tricky to get things right for such
transitions, particularly since the person committing the change
generally doesn't experience the problems themselves.  There also used
to be problems with automake itself, but I believe they were fixed some
time ago.

The non-recursive build system should address some such issues by
allowing proper dependencies between everything.

I also spent a while fixing preautoreconf to generate dependencies
for the doxygen documentation which handle removed files gracefully.

And we've now fixed the doxygen dependencies to generate the
documentation in a parallel make safe way, and only once!

So I think we're in the best shape we've been in for a while, possibly
for ever!  But we need to keep on top of problems, so we want people to
report them rather than just muttering and sweeping them under the
carpet.

I agree it's helpful to document a workaround - it's a frustrating place
to be stuck, and the way out isn't especially obvious.  But we also want
to encourage a detailed report of what went wrong too.

We wouldn't say "if Omega crashes, try just deleting the output files
and running it again" would we?

Cheers,
    Olly



More information about the Xapian-devel mailing list