Refactored release scripts to conform to using git archive
When generating a release, there is a risk of some files being
stale, such as configure and the m4/autotools temp files. This
is fixed with a clean at the beginning of release generation.
In addition, there is no uniformity in the current method of
source tar generation between xfs utilities. Using git archive
solves this issue across all utilities.
Signed-off-by: Andrew Dahl <adahl@sgi.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Ben Myers <bpm@sgi.com>
This patch resolves the following compiler/configure warnings:
configure: WARNING: unrecognized options: --enable-lib64
warning: 'xxxx' may be used uninitialized in this function [-Wuninitialized]
warning: variable 'xxx' set but not used [-Wunused-but-set-variable]
warning: call to function 'foo' without a real prototype [-Wunprototyped-calls]
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
configure.in has been renamed to configure.ac. Update the Makefile.
Signed-off-by: Ben Myers <bpm@sgi.com>
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
The "dmapi" subtree was developed separate from and sort of wedged
into the rest of the "xfstests" code. As a result, it has a lot of
build infrastructure that's just different from the unified way used
for everything else.
This patch changes all that, making the "dmapi" subtree be a more
normal component of "xfstests" with respect to its build process.
This involves removing all the cruft needed and used by the dmapi
"configure" script, and replacing each "Makefile.am" file with a
proper "Makefile" that includes a simple set of rules that are
compatible with the broader "xfstests" build.
The result is a much cleaner, consistent build. It also deletes
a considerable amount of code.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Make it so "make depend" is a generic target, like "make clean".
Each Makefile has a "depend" target that indicates whether making
dependencies means creating ".dep" or creating ".ltdep" (or, I
suppose, both, though none do that right now). Both files get
created even if there are no CFILES to scan (to ensure the target
up-to-date). The "default" target now depends on "depend" (there is
no "ltdepend" any more).
Remove the "depend" and "ltdepend" definitions from the "buildrules"
file; only the actual generated files (".dep" and ".ltdep") remain
as generic targets. The "depend' target is still defined as phony.
Do a shell trick when expanding the value of CFILES, to avoid a
problem that occurs if it is created by "make" by concatentating two
empty strings. The problem was that in that case CFILES will
contain a space, and that wasn't getting treated as empty as
desired.
Make the rule for tool/lib dependencies more generic, to reflect the
general desire that "lib" subdirectories need to be built before
things in the "tool" subdirectories.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Change the top-level Makefile, to make it clearer just what makes
what, and what depends on what:
- Separate the rules for "configure" and "include/builddefs" into
two parts, each of which generate one of the files
- Get rid of the rule for include/config.h, and group it with the
one for include/builddefs (the same command creates both files)
Having done this, we find that having both "include/builddefs" and
"include/config.h" as dependencies for the default target results in
a parallel invocation of "make" spawning two concurrent attempts to
do the configure step--and that doesn't work.
Creating one of those two will result in the other getting created,
so just list one of them as a dependency for the default rule.
A couple of other small fixes:
- Get rid of the "new", "remake" and "check" dependencies for the
default rule, which serv no purpose
- Use the $(Q) convention in a few missed spots
- Stop a DMAPI-only comment from getting echoed on default build
- Delete the "
This updated version pulls in the content of a patch previously
posted separately to fix the problem with parallel builds.
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Eric Sandeen <sandeen@sandeen.net>
There's no need to re-make the dependency files all the time. Make
it so the "depend" target rebuilds the ".dep" file only if necessary.
Also change the name of the dependency file created for "ltdepend"
to be ".ltdep".
Signed-off-by: Alex Elder <aelder@sgi.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
We don't need to see every compiler command line for every file that
is compiled. This makes it hard to see warnings and errors during
compile. For progress notification, we really only need to see the
directory/file being operated on.
Turn down the verbosity of output by suppressing various make output
and provide better overall visibility of which directory is being
operated on, what the operation is and what is being done to the
files by the build/clean process.
This patch only addresses the top level makefile and build rules; it
does not clean up the subdirectories - these will be addressed by a
followup patch. It also does not touch the dmapi section of the
xfstests build system.
The old style verbose builds can still be run via "make V=1 ..."
Signed-off-by: Dave Chinner <david@fromorbit.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Makefile so that it would get caught on make install, but
doing this unconditionally means that we tried to build that
subdir even if libaio headers weren't found.
Fix this up to do a properly chained make install through
the subdirs...
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Christoph Hellwig <hch@lst.de>
My big parallel build patch lost the "make configure" target.
This broke Makepkgs...
Now, IMHO, running configure from make is a little bass-ackwards;
I'd probably prefer to have Makepkgs explicitly run:
autoconf; configure --myoptions; make
but for now, this adds back in a workable "make configure" target.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Christoph Hellwig <hch@lst.de>