From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9022 invoked by alias); 15 Nov 2016 16:46:29 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 9007 invoked by uid 89); 15 Nov 2016 16:46:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=aimed, sk:mipsli, sk:mips-li, 3049 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Nov 2016 16:46:27 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 86AB9C05678C; Tue, 15 Nov 2016 16:46:26 +0000 (UTC) Received: from [127.0.0.1] (ovpn03.gateway.prod.ext.phx2.redhat.com [10.5.9.3]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAFGkPMM010350; Tue, 15 Nov 2016 11:46:25 -0500 Subject: Re: [PATCH 3/4] Makefile: Flatten and sort file lists To: Simon Marchi , gdb-patches@sourceware.org References: <20161113034625.8237-1-simon.marchi@polymtl.ca> <20161113034625.8237-4-simon.marchi@polymtl.ca> From: Pedro Alves Message-ID: Date: Tue, 15 Nov 2016 16:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161113034625.8237-4-simon.marchi@polymtl.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00375.txt.bz2 On 11/13/2016 03:46 AM, Simon Marchi wrote: > I find the big file lists in the Makefile a bit ugly and not very > practical. Since there are multiple filenames on each line (as much as > fits in 80 columns), it's not easy to add, remove or change a name in > the middle. As a result, we have a mix of long and short lines in no > particular order (ALL_TARGET_OBS is a good example). > > I therefore suggest flattening the list (one name per line) and keeping > it in alphabetical order. The diffs will be much clearer and merge > conflicts will be easier to resolve. I agree. I've asked for similar things in other cases for the same reason. > > For the ordering, I aimed at respecting this order: > > * foo.c > * foo-bar.c > * foobar.c > > Which, in non-formal words, could be expressed like so: > > * The extension is not taken into account when comparing two filenames > (except if the filenames are otherwise equal). > * A filename that is a prefix of another one comes before this other > one. > * Underscores and dashes are treated equally (I think we use them both > for the same purpose). > * Underscores and dashes come before alphanumeric characters. > > Short of any other rule, this could be used as a guideline to determine > where to add a new filename in the list. Could/should this be converted into a comment? At least a "keep these lists sorted" comment, I think. That'll be easier to find than this email or commit log. Wouldn't it make sense to sort by files and dirs separately? I.e., files first, then dirs, e.g.? You have this, for example: > + mdebugread.h \ > + memattr.h \ > + memory-map.h \ > + memrange.h \ > + mi/mi-cmds.h \ > + mi/mi-common.h \ > + mi/mi-console.h \ > + mi/mi-getopt.h \ > + mi/mi-main.h \ > + mi/mi-out.h \ > + mi/mi-parse.h \ > + microblaze-tdep.h \ > + mips-linux-tdep.h \ > + mips-tdep.h \ > + mipsnbsd-tdep.h \ I.e., MI files mixed with the other files. I'd expected: > + mdebugread.h \ > + memattr.h \ > + memory-map.h \ > + memrange.h \ > + microblaze-tdep.h \ > + mips-linux-tdep.h \ > + mips-tdep.h \ > + mipsnbsd-tdep.h \ ... > + mi/mi-cmds.h \ > + mi/mi-common.h \ > + mi/mi-console.h \ > + mi/mi-getopt.h \ > + mi/mi-main.h \ > + mi/mi-out.h \ > + mi/mi-parse.h \ Maybe it's be clearer to move subdir headers to variables, like we have SUBDIR_PYTHON_SRCS/SUBDIR_PYTHON_OBS, etc. for sources. But still, for the cases where we don't have variables. > SUBDIR_TUI_OBS = \ > + tui.o \ > tui-command.o \ > tui-data.o \ > tui-disasm.o \ > @@ -269,9 +304,9 @@ SUBDIR_TUI_OBS = \ > tui-windata.o \ > tui-wingeneral.o \ > tui-winsource.o \ > - tui.o Mind the trailing \ left in the last element. Here and other places. Thanks, Pedro Alves