From: Mike Frysinger <vapier@chromium.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Gwendal Grignou <gwendal@chromium.org>, fstests@vger.kernel.org
Subject: Re: xfstest and chromeos
Date: Fri, 27 Jan 2017 08:02:30 -1000 [thread overview]
Message-ID: <CAAbOScmd_j-HgZj929fbWzs3JjLkB817dJ_A-ghLyD7kHjh7GA@mail.gmail.com> (raw)
In-Reply-To: <20170127163748.vhqizartavwa7vxt@thunk.org>
On Fri, Jan 27, 2017 at 6:37 AM, Theodore Ts'o wrote:
> On Thu, Jan 26, 2017 at 10:40:39PM -1000, Mike Frysinger wrote:
> > On Thu, Jan 26, 2017 at 5:45 PM, Theodore Ts'o wrote:
> > > On Mon, Jan 23, 2017 at 09:57:15AM -0800, Gwendal Grignou wrote:
> > >> https://chromium-review.googlesource.com/#/c/424191
> > >> - Chromeos needs libtool to (cross-)compile packages and put them at
> > >> the right place. I needed to move archived aclocal.m4 to acinclude.m4.
> > >> Does it make sense to require aclocal to run to compile xfstests?
> > >
> > > I'm kind of curious why you need libtool to be able to cross-compile
> > > packages.
> > >
> > > I've been cross-compiling xfstests to armhf, ppcle, and arm64 without
> > > any issues.
> > >
> > > See: https://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/build-all
> > >
> > > Are you trying to build with shared libraries, or some such?
> >
> > it isn't about "needing" libtool, nor what we're attempting to do. we
> > don't care if xfstools uses libtool or plain automake rules or
> > something else. however, xfstests itself already utilizes `libtool`
> > to compile+link things, and indeed to also create libs like libtest.la
> > and libdmtest.la.
>
> Right, but I'm able to create libtool without any problems and messing
> with aclocal.m4 and acinclude.m4, et. al. I probably am relying on
> libtoolize from the local Debian or Guubuntu build host, though. Is
> that the issue you're having with ChromeOS? That you're using a
> different version of the libtool/autoconf macros?
if we wanted, we could do all this manually too, but i don't think it
makes sense to force every developer to learn autotools and how to set
up a local copy. Gwendal's patch makes things "just work" w/out
having to learn anything new. the overhead is, arguably, negligible.
-mike
next prev parent reply other threads:[~2017-01-27 18:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-23 17:57 xfstest and chromeos Gwendal Grignou
2017-01-26 5:14 ` Eryu Guan
2017-01-26 7:17 ` Mike Frysinger
2017-01-27 3:45 ` Theodore Ts'o
2017-01-27 8:40 ` Mike Frysinger
2017-01-27 16:37 ` Theodore Ts'o
2017-01-27 18:02 ` Mike Frysinger [this message]
2017-01-27 19:31 ` Gwendal Grignou
2017-01-27 21:10 ` Theodore Ts'o
2017-03-06 22:14 ` [PATCH] Make SELinux protection conditional Gwendal Grignou
2017-03-07 0:56 ` xfstest and chromeos Mike Frysinger
2017-03-20 21:20 ` [PATCH] Code to allow cros-compilation on chromeOS Gwendal Grignou
2017-03-24 4:23 ` Eryu Guan
2017-03-24 23:53 ` Gwendal Grignou
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=CAAbOScmd_j-HgZj929fbWzs3JjLkB817dJ_A-ghLyD7kHjh7GA@mail.gmail.com \
--to=vapier@chromium.org \
--cc=fstests@vger.kernel.org \
--cc=gwendal@chromium.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.