From: Dave Chinner <david@fromorbit.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] Use the original install-sh file from SGI
Date: Sat, 5 May 2018 11:36:12 +1000 [thread overview]
Message-ID: <20180505013612.GG23861@dastard> (raw)
In-Reply-To: <20180503050728.25779-1-tytso@mit.edu>
On Thu, May 03, 2018 at 01:07:28AM -0400, Theodore Ts'o wrote:
> The install-sh file is much more efficient than the libtool version
> (50% faster wall clock time; much more than that when running in a
> qemu emulation build environment). There doesn't seem to be any real
> need for the libtool version, so bring back the original install-sh
> script.
>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> ---
>
> A very large amount of time when running "make install" in a build
> chroot using qemu emulation, such as constructed by running "sudo
> setup-buildchroot --arch-armhf" using the script found here[1] is in
> running the install-sh provided by libtool, which is amazing bloated
> and forks a crazy number of processes to do something very simple.
>
> As near as I can tell there is zero benefit in using the install-sh
> provided by libtool, so restore the version that SGI originally used.
>
> [1] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot
Does this break cross-compilation for chromeeOS?
I ask, because that is why the hard coded install-sh was originally
replaced by the libtool provided one last year:
commit 5d20084fefaf09e86be26d7c71bd1c7ac2a2b35c
Author: Gwendal Grignou <gwendal@chromium.org>
Date: Wed Apr 19 16:33:48 2017 -0700
build: allow cros-compilation on chromeOS
- Request LIBTOOL to be used
- Set topbuildir based on a Makefile variable to call libtool
- Use /usr/local instead of /var for xfstest final location
- Move macros from aclocal.m4 to acinclude.m4, aclocal.m4 is autogenerated.
- Use autoconf variables @prefix@, @exec_prefix@.
The regular way of compiling xfstests - make - remains.
But it now runs autoreconf and libtoolize -i to produce a valid
configure.
Verified with 'make install --dry-run' that files are installed at the
same place.
Verified compiling in chromeOS chroot works as well.
[eguan: resolve merge conflicts and update .gitignore and remove
generated files by realclean]
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
prev parent reply other threads:[~2018-05-05 1:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-03 5:07 [PATCH] Use the original install-sh file from SGI Theodore Ts'o
2018-05-04 15:12 ` Eryu Guan
2018-05-04 21:15 ` Theodore Y. Ts'o
2018-05-05 1:36 ` Dave Chinner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180505013612.GG23861@dastard \
--to=david@fromorbit.com \
--cc=fstests@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox