From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0GNbEejM52MqSTAAWB0awg (envelope-from ) for ; Sat, 11 Feb 2023 12:14:16 -0500 Received: by simark.ca (Postfix, from userid 112) id 44D5A1E221; Sat, 11 Feb 2023 12:14:16 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=hhfZk/8r; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B991D1E0D3 for ; Sat, 11 Feb 2023 12:14:15 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2E8703857438 for ; Sat, 11 Feb 2023 17:14:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2E8703857438 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676135655; bh=8+NszMNMTXoX+IrAkBOkDSoqjTcbxDYjnUYOC+Y6I3A=; h=To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=hhfZk/8rWXpxtWYiF0yJ5ZWnVLf8ccA3IVvXgqv6lu9g0Td/a/fMo/YnqVZ1Xqibh muLLifJpPes80RRncKZIvG01s6YOdIJKMmnwof+Bt1HqdTGTjPn0aqSfqHQ/Stpcp6 nArUfZwRr7IDw3yDOPigW/Zxfd5gf1m5jpX5qfaE= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id DECD93858D32 for ; Sat, 11 Feb 2023 17:13:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DECD93858D32 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-175-aLolxHuwOL2XXU6uR-3VrQ-1; Sat, 11 Feb 2023 12:13:40 -0500 X-MC-Unique: aLolxHuwOL2XXU6uR-3VrQ-1 Received: by mail-qt1-f197.google.com with SMTP id a24-20020ac87218000000b003bb7c7a82f7so4902711qtp.9 for ; Sat, 11 Feb 2023 09:13:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8+NszMNMTXoX+IrAkBOkDSoqjTcbxDYjnUYOC+Y6I3A=; b=eTtxU5HFIUtc/6is2QNTP13GZdTFFf0xRZmrT5BgH2zqB+Zc85cywm7p0SvJKhBbA7 4ykvF7N+uxLCeFskN38mQ/3qhOwQjXtz2FD80kvosNqZ9djspOtMiU39Wbr6KsT4jD3j ZOfjCUTq55kwRsjZQ9xu4TQpF+cSTPWr3FlAPxMjDcmiafoPsjgiYT+BFBhn/tMfhBtR ewPzeiHN6WGcOKMkhnXKuGY8R9bGvH9ejt75br/Fi8pGI6rR8slcSiQd3MOoG8cqhbTz Q6TJTtGpQS2+5MM45Vb/CPmcY432TDFXumGfjDJpxwh7rNXCVsVdDctjHAs1MoReKkTJ 3sAQ== X-Gm-Message-State: AO0yUKVKllClwIXPq6YF2jvhD4/MWQqzLw3JNq02wIZjDRZRzpfCFz1l 9FTiPPFVTXA6uOmS/dY+xgIyc1kaRYRZIYRGprQgptvo4pPtNmgNDTXg+yNdT2Tin64IwRs/3Z7 pvLiCJpywA/0= X-Received: by 2002:ad4:4ea8:0:b0:56e:9af1:f2e9 with SMTP id ed8-20020ad44ea8000000b0056e9af1f2e9mr8079744qvb.32.1676135619552; Sat, 11 Feb 2023 09:13:39 -0800 (PST) X-Google-Smtp-Source: AK7set+uvnSv47t4B0xMqh4Kv4NimVpCQSKumADIv0EVjJf7TW0JLTVGSvEytQIknmhtCbKwJv2iGA== X-Received: by 2002:ad4:4ea8:0:b0:56e:9af1:f2e9 with SMTP id ed8-20020ad44ea8000000b0056e9af1f2e9mr8079714qvb.32.1676135619303; Sat, 11 Feb 2023 09:13:39 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id i65-20020a37b844000000b0071f40a59fe5sm5945896qkf.127.2023.02.11.09.13.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Feb 2023 09:13:38 -0800 (PST) To: Simon Marchi , Joel Brobecker , Simon Marchi via Gdb Cc: Mark Wielaard Subject: Re: Any concrete plans after the GDB BoF? In-Reply-To: References: <83485199-965e-7ff5-1dc8-d027b74b56f7@arm.com> <5924814b-2e53-da09-6125-48ac5a5296e7@simark.ca> Date: Sat, 11 Feb 2023 17:13:37 +0000 Message-ID: <87mt5kunum.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrew Burgess via Gdb Reply-To: Andrew Burgess Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Simon Marchi via Gdb writes: > On 10/31/22 09:37, Joel Brobecker via Gdb wrote: >>> I agree with all you said. There is always some resistance related to >>> how clang-format handles this or that case. In my opinion, that's minor >>> compared to the benefit of using it. My opinion would be: make the >>> clang-format config that is closest to our style today, make a big >>> re-format, and carry on. >> >> I agree with that. As long as the formatting is consistent, it might >> take a little getting used to, but I think we'll be happier if we don't >> have to spend time worrying about code formatting. >> >> The one small obstacle, perhaps, might be if different versions of >> the tool format things differently. In that case, we might have to >> clearly state which version we expect the code to be formatted with. >> I am thinking of the kind of issues we get with the configury which >> is generated by the auto tools, which is so dependent on the version >> that even the distro-provided versions introduce spurious differences >> sometimes, as a result of which I have built my own set of vanilla >> autotools. If clang-format is tricky to build, we may have issues >> in that respect... > > I would suggest mandating one version, and for that version to > continuously be the latest stable version of clang-format, like we do > for Black. When a new version comes out, we don't have to wonder if / > when we move the next version. Someone just pushes a patch re-formating > the code to the next version, if there are some differences. It keeps > the overhead to a minimum. I dislike our policy of using the latest version of black, and would argue that always using the latest version _increases_ the overhead, rather than reducing it. My thinking is this; not every one is using a distro that quickly packages the latest version. This means that if we are always chasing the latest version, at least some people will end up continually having to build clang-format on a regular basis just so they can push to GDB. If I had a choice then, personally, I'd vote against using clang-format at all, but it feels like there's a majority in favour, so if we do have to go down this route, I'd rather we adopted the same policy as for autotools and C++ versioning. That is, pick something that works for us, and commit to it over the medium term. That way at least, I can build a single version of clang-format and know that it's going to last me for a while. > > So far I have never seen problems related to distro-specific patches, as > we have seen with autoconf. > > For Debian/Ubuntu, it's easy to get the latest stable version through > apt.llvm.org. I don't really know about other distros. In any case, > it's easy to build and not long (not long like building the whole > llvm/clang): > > $ git clone --depth 1 https://github.com/llvm/llvm-project.git --branch release/15.x > $ mkdir -p llvm-project/build > $ cd llvm-project/build > $ cmake -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles" ../llvm -DCMAKE_INSTALL_PREFIX=/tmp/llvm > $ make -j 4 clang-format > $ make install-clang-format > $ /tmp/llvm/bin/clang-format --version > clang-format version 15.0.4 (https://github.com/llvm/llvm-project.git 08bd84e8a6358eb412fcef279f8875e2d69a3374) Could we build something like this into the GDB makefile maybe? That way folk don't need to go looking for this information. Thanks, Andrew > > Simon