From: Jeff Mahoney <jeffm@suse.com>
To: dsterba@suse.cz, Qu Wenruo <quwenruo.btrfs@gmx.com>,
Hallo32 <Hallo32@gmx.net>,
linux-btrfs@vger.kernel.org
Subject: Re: btrfs-progs-v4.12: cross compiling
Date: Tue, 15 Aug 2017 15:27:25 -0400 [thread overview]
Message-ID: <24619940-8384-59f9-6fd8-f390cc4bee23@suse.com> (raw)
In-Reply-To: <20170814151052.GV2866@twin.jikos.cz>
[-- Attachment #1.1: Type: text/plain, Size: 1896 bytes --]
On 8/14/17 11:10 AM, David Sterba wrote:
> On Mon, Aug 14, 2017 at 10:14:42PM +0800, Qu Wenruo wrote:
>> On 2017年08月14日 22:03, David Sterba wrote:
>>> On Mon, Aug 14, 2017 at 09:17:08PM +0800, Qu Wenruo wrote:
>>>> On 2017年08月14日 21:06, David Sterba wrote:
>>>>> On Mon, Aug 14, 2017 at 02:17:26PM +0200, Hallo32 wrote:
>>>>>> Since versions 4.12 btrfs-progs is complicated to cross compile for
>>>>>> other systems.
>>>>>> The problem is, that this version includes mktables, which needs to be
>>>>>> compiled for the host system and executed there for the creation of
>>>>>> tables.c.
>>>>>>
>>>>>> Are there any changes planed for the next version of btrfs-progs to make
>>>>>> the cross compiling as simple as in the past? A included tables.c for
>>>>>> example?
>>>>>
>>>>> Yes, keeping the generated tables.c around is fine. There's no reason it
>>>>> needs to be generated each time during build. I'll fix that in 4.12.1.
>>>>
>>>> But the number of lines and impossibility to review it makes it not
>>>> suitable to be managed by git.
>>>
>>> I don't understand your concern. The file is generated from a set of
>>> formulas, not intended to be updated directly.
>>
>> Yes, it should never be updated directly, so it's generated by a less
>> than 400 lines program, instead of a whole 10K+ lines file managed by git.
>
> mktables.c is synced from kernel sources, taking updates from there is
> easier than porting any changes to the proposed scripted implementation.
>
> The workflow is simple:
> - copy kernel mktables.c changes to btrfs-progs mktables.c
> - compile mktables
> - run 'make kernel-lib/tables.c'
Can't this happen as part of a make dist (that we don't do right now)?
> - commit the changes to git
... and anyone using the git repo directly can sort out how to build it?
-Jeff
--
Jeff Mahoney
SUSE Labs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2017-08-15 19:27 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-14 12:17 btrfs-progs-v4.12: cross compiling Hallo32
2017-08-14 13:06 ` David Sterba
2017-08-14 13:17 ` Qu Wenruo
2017-08-14 14:03 ` David Sterba
2017-08-14 14:14 ` Qu Wenruo
2017-08-14 15:10 ` David Sterba
2017-08-14 18:57 ` Goffredo Baroncelli
2017-08-14 23:39 ` Qu Wenruo
2017-08-15 12:44 ` Hallo32
2017-08-15 12:48 ` David Sterba
2017-08-15 17:28 ` Eric Sandeen
2017-08-15 18:14 ` Eric Sandeen
2017-08-16 0:13 ` Qu Wenruo
2017-08-15 19:27 ` Jeff Mahoney [this message]
2017-08-14 13:10 ` Qu Wenruo
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=24619940-8384-59f9-6fd8-f390cc4bee23@suse.com \
--to=jeffm@suse.com \
--cc=Hallo32@gmx.net \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/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.