On Tue, Aug 15, 2017 at 02:44:07PM +0200, Hallo32 wrote: > Am 15.08.2017 um 01:39 schrieb Qu Wenruo: > > On 2017年08月15日 02:57, Goffredo Baroncelli wrote: > >> On 08/14/2017 05:10 PM, David Sterba wrote: > >>> On Mon, Aug 14, 2017 at 10:14:42PM +0800, Qu Wenruo wrote: > >> [...] > >>> 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 > >> > >> How the kernel deals with this kind of problem ? > >> Looking at the source of btrfs Makefile, it is more simple to replace > >> > >> mktables: kernel-lib/mktables.c > >> @echo " [CC] $@" > >> $(Q)$(CC) $(CFLAGS) $< -o $@ > >> > >> with > >> > >> > >> mktables: kernel-lib/mktables.c > >> @echo " [HOSTCC] $@" > >> $(Q)$(HOSTCC) $(CFLAGS) $< -o $@ > >> > >> where HOSTCC is defined as > >> > >> HOSTCC=gcc > >> > >> > >> (may be the same applied also to CFLAGS <-> HOSTCFLAGS ?) > > > > If using HOSTCC then I'm fine with it. > > CFLAGS needs also be replaced by something like HOSTCFLAGS, because if > you use something like mips/architecture specific CFLAGS, they may be > not applicably on the host system.
Good point. Without a regular/automated cross-compilation build testing I think we could break it quite easily. I'm going to keep the pregenerated file in git. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
