User Space Releases

[Christoph Hellwig]

On Fri, Dec 11, 2009 at 09:12:55AM +1100, Nathan Scott wrote:
> Here's the conversion to new-fangled build style for xfsdump.  Review?
> Its largely same as xfsprogs, the one slight wrinkle was the symlinked
> files in "common"... but thats sorted out with this patch too.

Thanks.  Looks good from looking over it and trying a make dist and
debian package build.  A couple of think I noticed while going over the
diffs between xfsprogs and xfsdump for the build system:

 - in xfsdump we have po/*.mo in the gitignore file, while we list the
   two translations explicitly in xfsprogs.  I'll fix this up and push
   the fix
 - installation of documentation is doc/Makefile is handled slightly
   differently.  In both cases we might be better off installing more
   documtnation (and probably get rid of the $(README) variable in
   xfsdump.  I'll look into more sensible defaults for either.
 - the source-link target in xfsdump now echos the mkdir command
   but xfsprogs doesn't.  I don't care either way but it might be a good
   idea to make it the same in both versions
 - include/builddefs.in in xfsdump now expands prefix/exec_prefix/
   datarootdir/top_builddir twice.  Just kill the second one
 - the doc/PORTING file still exist in xfsdump and should probably be
   deleted.  It doesn't get packaged either, btw.
 - the build directory in xfsdump isn't deleted yet as it is in
   xfsprogs.
 - the Makepkgs script isn't deleted yet as in xfsprogs
   build/rpm/rpm-2.rc.template
 - unlike xfsprogs the m5/lt*.m4 files don't get into the generated
   tarball.  I don't quite understand why we need them, but we should
   at least be consistant.

 - might it be a good idea to add the LHFILES/LCFILEs handling to
   xfsprogs and the install-qa handling to xfsdump include/build*
   despite beeing unused to keep them in sync?
 - probably worth updating the copyrights in either version to list
   the same years now they are the same