From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net ([212.227.15.19]:62388 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751428AbdHNOOu (ORCPT ); Mon, 14 Aug 2017 10:14:50 -0400 Subject: Re: btrfs-progs-v4.12: cross compiling To: dsterba@suse.cz, Hallo32 , linux-btrfs@vger.kernel.org References: <20170814130608.GS2866@twin.jikos.cz> <46edbc7c-8bd9-0507-950e-be5182356772@gmx.com> <20170814140341.GU2866@suse.cz> From: Qu Wenruo Message-ID: <159b3db0-6eae-7cff-d166-3c4b0c2513ac@gmx.com> Date: Mon, 14 Aug 2017 22:14:42 +0800 MIME-Version: 1.0 In-Reply-To: <20170814140341.GU2866@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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. >> >> What about using script to generate it? > > We do have the mktables utility to generate it and I'll regenerate it > should there be a change to kernel-lib/mktables.c I mean to replace mktables.c with a script. So no cross compiler problems at all, and even easier Makefile. No dependence on "mktables" program. Thanks, Qu >