From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Bj=C3=B6rn?= Bidar Newsgroups: gmane.emacs.devel Subject: Re: master 888ff3755d4 1/3: New function internal--c-header-file-path Date: Tue, 07 Jan 2025 11:57:52 +0200 Message-ID: <87sepv6j4v.fsf@thaodan.de> References: <864j2b660v.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18410"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 07 10:58:53 2025 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tV6MP-0004bI-2K for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Jan 2025 10:58:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tV6La-0001iT-PT; Tue, 07 Jan 2025 04:58:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tV6LZ-0001iK-AO for emacs-devel@gnu.org; Tue, 07 Jan 2025 04:58:01 -0500 Original-Received: from thaodan.de ([2a03:4000:4f:f15::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tV6LV-0000AI-6R; Tue, 07 Jan 2025 04:58:00 -0500 Original-Received: from NordStern (unknown [185.252.118.71]) by thaodan.de (Postfix) with ESMTPSA id DD67ED0004B; Tue, 7 Jan 2025 11:57:52 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1736243873; bh=/zBXuU04fx6nc29qloG+uih4+19S20CbipMUY7wNu1M=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Yy0q/xUaQQvDEeKGjmn9x2gdYENdAgKPFSqazDqaxbO6yRQiaF4E2IGY3xCpho+RI zANEIGRaoMg6SChomUtMV4FwUjr5gqHbkqh8lsPUc8Y6bLI6YWxmRnfIBeIayOH7M0 /+s6Z20H4p7VR5HhamWWZHRk0BEfoqZ+VogEKk/F7HuZuJDBd8RS7awEAF4KPTcmtW IEersCZEonRycF8CiomvIZKJs4iOmkMy1PKfcl/yhWm/E96x+as3luAI52QCY1O7+/ QYiChDmzCtLXSM3pZe8pCoFf+G+CTwnqzIygAK1b04SThMa6or6po01rTEaqrBRCCv f6c62NSJnNyBjChmNnuK4MZ2Bbg7PqzrLiTE4CSYoCshD8i893UX0U1b2I9Aom3AvW bbZ1qf8kAq2RatPJs1yHs4l+Xev+okggnuAtN/Jk+qyU8mCYLhkfowjqkxqIECKK+J yG/Nb/nG450kVa9IIaKTGE93psKyi+kKuV8UsYDhPEfnqP5KTaCNVgfadsEi1p/TTt EE9K/cxR/9a6/vAuA60smzQmdbSmwTbDyDphzhqx/1qmREUEuT7i/fo309HJrf9wMa qV7OuPCnKwYmeTHY9INnGUWCzjYhq3Lu1i0JCJoVaySp3dRwoslO/TJViqvJ4ySLOT l/NTY/wl+R10XbWH9L20BrIw= In-Reply-To: (Stefan Kangas's message of "Mon, 6 Jan 2025 15:44:34 -0600") Autocrypt: addr=bjorn.bidar@thaodan.de; prefer-encrypt=nopreference; keydata= mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlH Received-SPF: pass client-ip=2a03:4000:4f:f15::1; envelope-from=bjorn.bidar@thaodan.de; helo=thaodan.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327757 Archived-At: Stefan Kangas writes: > Eli Zaretskii writes: > >> Stefan, >> >> Thanks for adding this function. However, the method it uses to find >> the include directories is incorrect and unportable. On most systems >> it will produce the default "/usr/include", which is most probably >> wrong. >> >> The way to ask GCC to show the list of directories where it looks for >> header files is like this: >> >> (call-process "gcc" nil BUFFER nil "-v" "-E" "-") >> >> and then look in BUFFER for text that begins with "#include <...> >> search starts here:" and ends with "End of search list." What's >> in-between is the list of include directories, one directory per line, >> which GCC searches for header file, in the order it searches them. > > Thanks for helping improve this. How about the attached patch? > > From c8aac6531fbf228d004b15498fd0758e080c784e Mon Sep 17 00:00:00 2001 > From: Stefan Kangas > Date: Mon, 6 Jan 2025 22:37:51 +0100 > Subject: [PATCH] Make internal--c-header-file-path more portable > > * lisp/subr.el (internal--c-header-file-path): Make more portable. > Problem reported by Eli Zaretskii . > * test/lisp/subr-tests.el > (subr-tests-internal--c-header-file-path) > (subr-tests-internal--c-header-file-path/gcc-mocked) > (subr-tests-internal--c-header-file-path/clang-mocked): Adjust tests. > --- > lisp/subr.el | 57 +++++++++++++++------------------------ > test/lisp/subr-tests.el | 60 ++++++++++++++++++++++++++--------------- > 2 files changed, 59 insertions(+), 58 deletions(-) > > diff --git a/lisp/subr.el b/lisp/subr.el > index 5be8d8f52d4..e0f5542a011 100644 > --- a/lisp/subr.el > +++ b/lisp/subr.el > @@ -7574,41 +7574,26 @@ internal--c-header-file-path > ;; See also (Bug#10702): > ;; cc-search-directories, semantic-c-dependency-system-include-path, > ;; semantic-gcc-setup > - (delete-dups > - (let ((base '("/usr/include" "/usr/local/include"))) > - (cond ((or (internal--gcc-is-clang-p) > - (and (executable-find "clang") > - (not (executable-find "gcc")))) > - ;; This is either macOS, or a system with clang only. > - (with-temp-buffer > - (ignore-errors > - (call-process (if (internal--gcc-is-clang-p) "gcc" "clang") > - nil t nil > - "-v" "-E" "-")) > - (goto-char (point-min)) > - (narrow-to-region > - (save-excursion > - (re-search-forward > - "^#include <\\.\\.\\.> search starts here:\n" nil t) > - (point)) > - (save-excursion > - (re-search-forward "^End of search list.$" nil t) > - (pos-bol))) > - (while (search-forward "(framework directory)" nil t) > - (delete-line)) > - (append base > - (reverse > - (split-string (buffer-substring-no-properties > - (point-min) (point-max))))))) > - ;; Prefer GCC. > - ((let ((arch (with-temp-buffer > - (when (eq 0 (ignore-errors > - (call-process "gcc" nil '(t nil) nil > - "-print-multiarch"))) > - (goto-char (point-min)) > - (buffer-substring (point) (line-end-position)))))) > - (if (zerop (length arch)) > - base > - (append base (list (expand-file-name arch "/usr/include")))))))))) > + (if (or (executable-find "gcc") > + (executable-find "clang")) why not use if-let here and fallback to cc? > + (with-temp-buffer > + (ignore-errors > + (call-process (if (executable-find "gcc") "gcc" "clang") > + nil t nil > + "-v" "-E" "-")) > + (goto-char (point-min)) > + (narrow-to-region > + (save-excursion > + (re-search-forward > + "^#include <\\.\\.\\.> [[:word:] ]+:\n" nil t) > + (point)) > + (save-excursion > + (re-search-forward "^[[:word:] ]+\\.$" nil t) > + (pos-bol))) > + (while (search-forward "(framework directory)" nil t) > + (delete-line)) > + (split-string (buffer-substring-no-properties > + (point-min) (point-max)))) > + '("/usr/include" "/usr/include/local")))