Follow-up Comment #23, bug #66143 (group groff): Hi Branden!
Thanks again for your very long and elaborate answer!
>> But, I ask myself, why this is not necessary in the homebrew env.
>>
>> I found the following:
>>
>>
>> env | grep include
>>
HOMEBREW_INCLUDE_PATHS=/opt/homebrew/opt/readline/include:/opt/homebrew/opt/sqlite/include
>>
HOMEBREW_ISYSTEM_PATHS=/opt/homebrew/include:/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers
>>
>> It seems, they set a variable called HOMEBREW_ISYSTEM_PATHS. But how
configure
>> gets to pick that up is still a riddle to me.
>
> I'm assuming that Autoconf doesn't pick it up, hence the failure on
> macOS to find the uchardet library's header file.
I did not express myself clear enough: I was talking about the homebrew build
environment. I can enter it via `brew reinstall -i groff`. And it was in that
env, that I saw these env variables. And there-in I saw that
/opt/homebrew/include was "put onto the include paths list", meaning, a
-I/opt/homebrew/include was appended to the clang invocation.
I just followed up on the question how this homebrew specific variable is
creating any effect:
…/tmp/groff-20240905-40241-pj7zgj/groff-1.23.0
$ grep -i 'HOMEBREW_ISYSTEM_PATHS' -R .
$
Nothing. Ok, I'd half expected that. Why would Autoconf consider such a
homebrew specific variable? But the question remained...
$ which clang++
/opt/homebrew/Library/Homebrew/shims/mac/super/clang++
Aha! A shim! A mac super shim. :)
grep -i 'ISYSTEM_PATHS' /opt/homebrew/Library/Homebrew/shims/mac/super/clang++
-C5
end
end
def refurbished_args
@lset = Set.new(library_paths + system_library_paths)
@iset = Set.new(isystem_paths + include_paths)
args = []
enum = @args.each
loop do
--
args
end
def cppflags
args = []
args += path_flags("-isystem", isystem_paths) + path_flags("-I",
include_paths)
# Add -nostdinc when building against glibc@2.13 to avoid mixing system
and brewed glibc headers.
args << "-nostdinc" if @deps.include?("glibc@2.13")
# Ideally this would be -ffile-prefix-map, but that requires a minimum of
GCC 8, LLVM Clang 10 or Apple Clang 12
# and detecting the version dynamically based on what `HOMEBREW_CC` may
have been rewritten to point to is awkward
args << "-fdebug-prefix-map=#{formula_buildpath}=." if formula_buildpath
--
else
args
end
end
def isystem_paths
path_split("HOMEBREW_ISYSTEM_PATHS")
end
def include_paths
path_split("HOMEBREW_INCLUDE_PATHS")
end
So, homebrew sets HOMEBREW_ISYSTEM_PATHS in its build env and the shim puts it
onto the include path list. (Btw. googling for HOMEBREW_ISYSTEM_PATHS yields
exactly two hits for me, none of which are documentation, and none of which
were helpful to me.)
>> But doesn't this mean, my point still stands: the whole pkg-config
>> business is superfluous,
>
> No, because what if a distribution puts the "uchardet" directory in a
> weird place that isn't "/usr/include"?
Yes, like, exactly what homebrew does. :) I was speaking only in the context
of groff/preconv and it's dependency on uchardet (the "whole business" wording
was unfortunate). (I would not question the motivation and legitimacy of
pkg-config in general.)
I am slowly getting the impression, that /usr/include could be considered as a
distribution managed include path. (And homebrew is trying to emulate that
with /opt/homebrew/include.) I read up in the FHS [1] on /usr/include:
> This is where all of the system's general-use include files for the C
programming language should be placed.
Mhm, by whom? How is general-use defined?
>> I always understood the c/c++ inclusion mechanism to be simply a
>> matter of trying all include dirs,
>
> Where "all" is probably only "/usr/include", yes. I don't know off the
> top of my head how strictly ISO C prescribes this.
I was including (haha) in my head also stuff given via -I on the command-line
here.
> One thing I do know about that standard is that libc header files,
> meaning those specified by the standard and locatable via "#include
> <whatever.h>", do not actually have to exist as files.
> The compiler is free to interpret such standard header inclusions in a
> way that they supply some equivalent to the text of such files. This
> matters for embedded systems, and is in part a consequence of the fact
> that ISO C does not take on the responsibility of specifying what a file
> system is.
Ugh. This, eh, ..., I am having a hard time imagining, what this could mean in
this context. Probably, this concerns stuff like <stdio.h>, <string.h> or
such, right? But for <uchardet.h> it would probably be safe to assume it is a
file?
>> In summary, I don't know. I now know how to fix my build problem, but
>> I have a hunch, that removing the directory prefix would be a
>> portability win.
>
> I reach the opposite conclusion. It's pretty obvious that the
> uchardet library API is wholly unspecified, including the location of
> its header file. (I do not say undefined--once you do locate
> "uchardet.h", it has valid C language declarations.)
My problem would not have arisen at least, but that is surely a very limited
perspective. But also on other distributions, it would have worked, as
pkg-config would have found uchardet and put the correct path on the include
path list. That was my thinking.
I have to admit, I often have to read your answers multiple times to extract
all your meaning from it. :) I will do that. And I will try to think about a
proposal on what to do. (I mean, after all, it could boil down to a
INSTALL.REPO sentence: "Beware, when on macos and using homebrew, do not
forget to set HOMEBREW_ISYSTEM_PATHS during configure.")
[1]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s05.html
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66143>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
