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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.