From: "Björn Bidar" <bjorn.bidar@thaodan.de>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: master 888ff3755d4 1/3: New function internal--c-header-file-path
Date: Tue, 07 Jan 2025 11:57:52 +0200 [thread overview]
Message-ID: <87sepv6j4v.fsf@thaodan.de> (raw)
In-Reply-To: <CADwFkmm7n564ti5oBiC+QL11wJ52G4DvDmyp3AnaVkKvEkC1sg@mail.gmail.com> (Stefan Kangas's message of "Mon, 6 Jan 2025 15:44:34 -0600")
Stefan Kangas <stefankangas@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> 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 <stefankangas@gmail.com>
> 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 <eliz@gnu.org>.
> * 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")))
next prev parent reply other threads:[~2025-01-07 9:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-06 20:28 master 888ff3755d4 1/3: New function internal--c-header-file-path Eli Zaretskii
2025-01-06 20:40 ` Andreas Schwab
2025-01-06 21:45 ` Stefan Kangas
2025-01-06 21:44 ` Stefan Kangas
2025-01-07 9:57 ` Björn Bidar [this message]
2025-01-07 12:09 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sepv6j4v.fsf@thaodan.de \
--to=bjorn.bidar@thaodan.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.