On Sat, Sep 21, 2019 at 06:37:05PM +0300, Amir Goldstein wrote:
> There is one issue with update builds that has been bothering me forever
> and has to do with xfstests and xfsprogs build, so while we are on fstests
> list I will mention that and maybe you can advise.
>
> Unlike do-all, do-update does 'make' without 'configure', but when
> configure.ac changes, and that happens every xfsprogs release,
> xfsprogs as well as xfstests Makefile runs an unsolicited ./configure
> without all the config parameters that were used for the first
> xfstests-bld build and then build fails.
I rarely use do-update these days, now that have ccache configured for
my build chroots. The primary case where I use it is when making
minor changes to xfstests (e.g., changing some source file in
xfstests/src which requires a recompile). I used to use it when
updating or creating a new test, but now we have "{kvm,gce}-xfstests
--update-xfstests-tar" which is even faster.
If anything happens which requires configure to be run, I just use
"./do-all" and be done with it. After all, i'm not doing all that
often.
The reason why the Makefiles in xfstests and xfsprogs are running an
unsolicity ./configure without all the config parameter can be fixed.
An example of how to do this can be found in e2fsprogs, where in the
MCONFIG.in file we have these lines:
$(top_srcdir)/configure: $(top_srcdir)/configure.ac
cd $(top_srcdir) && autoheader && autoconf
$(top_builddir)/config.status: $(top_srcdir)/configure
cd $(top_builddir); ./config.status --recheck
$(top_builddir)/MCONFIG: $(top_srcdir)/MCONFIG.in $(top_builddir)/config.status
cd $(top_builddir); CONFIG_FILES=MCONFIG ./config.status
and we have similar lines for all files generated by configure, for
example:
Makefile: $(srcdir)/Makefile.in $(top_builddir)/MCONFIG \
$(DEP_MAKEFILE) $(top_builddir)/config.status
cd $(top_builddir); CONFIG_FILES=$(my_dir)/Makefile ./config.status
The basic idea is that when configure.ac changes, we build configure,
and then we have config.status in the build tree depend on configure
--- and we use config.status --recheck to rerun the configure script
with all of the existing configure script options. We then similarly
use dependencies on config.status to rebuild all of the generated
files.
Whether or not it's worth it to set up a similar system for xfsprogs
and xfstests, and whether their respective maintainers would accept a
change is a different question.
I suppose you could try to teach the build-all script in xfstests-bld
when xfsprogs and xfstests might do an automatic run of ./configure in
build-all --update mode, and in that case (and only that case, since
the goal is to make --update be fast), have it run "./config.status
--recheck ; ./config.status".
It's not clear to me it's worth it, since I don't pull updates of
xfstests from upstream more than every week or two, and a full build
only takes around 12 minutes. And for the much more common case where
I'm tweaking a test or creating a new test, "--update-xfstests-tar" is
sufficient, and even faster than rebuilding a new KVM image using
./do-update.
Cheers,
- Ted
