[Gc]: Dependency tracking for configuration macros

Boehm, Hans hans.boehm at hp.com
Fri Sep 25 11:45:06 PDT 2009

> From:  Ivan Maidanski
> Sent: Friday, September 25, 2009 10:52 AM
> > 
> > > Hans -
> > > I guess these ones should be regenerated soon. But what's 
> the policy 
> > > for presence of the auto-generated files in:
> > > 1. CVS?
> > > 2. in a tar-ball?
> > > And, if Makefile should be present (in CVS/tarball), for which 
> > > target it should be generated?
> > 
> > The files generated by autoreconf (thus libtool, autoconf, 
> automake) 
> > are target independent.  Target dependencies are detected 
> by ./configure.
> > 
> > (My vote FWIW: Option 2.  Pro: Easier for developers.  Con: 
> End users 
> > who build from the repo need the dev tools.)
> > 
> > About the Makefile in the toplevel directory:  Looking at the diff, 
> > this seems to be an outdated version of Makefile.direct.  
> In that case 
> > I suggest removal.  In any case it is overwritten by ./configure.
> Let this be info for Hans...
I think the usual policy is to check in enough files that both:

1) Developers can regenerate everything that's not manually written, provided they install the appropriate autottools packages.

2) Users can type configure; make and have the collector build.  In the case cp Makefile.direct Makefile; make should also work.

I think we want the latter to work from a direct cvs check-out as well, since we want users to be able to build the CVS version without installing autotools.

I was under the mistaken impression that Makefile was already gone.  I'm fine with removing it.  It used to be a copy of Makefile.direct, so a simple "make" would also work on many platforms.  That could probably still work too, but then it should be a real copy of Makefile.direct, not an obsolete one.  It has the down side that it's somewhat at odds with GNU conventions.  (The fact that it's overwritten by configure seems OK, since it's easy to get back.)


More information about the Gc mailing list