On Tue, 4 Nov 2003, Norman Gray wrote:
> Do you mean the issue of automake, the `missing' tool, and checked-in
> generated files?
>
> I think it might be best if we thrash this out in the next face-to-face
> meeting we have, but my brief description of the issue is this.
>
> The distributed source tarball would not depend on any build tools,
> because it must not. Those hardy souls working with a CVS checkout
> will probably need some mild extra setup. They'd probably have to have
> extra setup in any case, in order to bootstrap the system.
>
> It seems preferable to include some generated files (ie, configure and
> Makefile.in, but not Makefile) in the repository. This does feel
> nasty, but it seems to turn out that the alternatives involve even
> nastier version-skew problems.
>
> However, if a change in configure.ac (changing comments, say) results
> in an unchanged configure, then the unchanged configure is not updated
> in the repository, so that the file configure.ac ends up being _newer_
> than configure when the result is checked out; thus the makefiles think
> that configure has to be remade. If (i) you have up-to-date autotools
> then configure is regenerated (redundantly, in fact, remember), no
> problem; if (ii) you have _no_ autotools then a script `missing' is run
> which simply touches the `generated' file, keeping the makefiles happy;
> but if (iii) you have _old_ autotools (unfortunately the most common
> case, since you probably have rather old autotools installed by your
> Linux distribution), then the makefiles try to use them, possibly
> failing, if the configure.ac or Makefile.am uses newish features. I've
> addressed the problem in autoastrom by customising the `missing'
> script, and suggested fixes to the automake list. The end result is
> that the _first_ time you run make on a checked-out or updated
> autoastrom you have to set a variable. There is no need to do that in
> the case of distributed source sets.
>
> Peter's contention is, I think, that such a special case is
> unreasonable, even for folk working with the CVS source set; I believe
> it is reasonable for this group, and in any case there's no way of
> avoiding it.
>
> Do we want to talk about this now, or postpone it to the next meeting,
> when we could talk about the whole business of CVS, building and
> distribution. I don't suppose either Tim or Brad will be there, no?
> We could go all über-techie and do a videocon, of course....
Norman,
I thought we'd "agreed" to see what happens when you try to get KAPPA (and
I remember suggesting CCDPACK) working using autoconf, and presumably
automake. Once we have seen what happens to some real-world packages we'll
all be in a much better position to thrash out the details.
As long as the distributed system can be build relying on a decent set of
compilers and not much else, I'm not likely to argue too much.
Cheers,
Peter.
|