[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: master 888ff3755d4 1/3: New function internal--c-header-file-path
From: |
Björn Bidar |
Subject: |
Re: master 888ff3755d4 1/3: New function internal--c-header-file-path |
Date: |
Tue, 07 Jan 2025 11:57:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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")))