Follow-up Comment #22, bug #66143 (group groff): At 2024-09-06T15:03:52-0400, Sven Schober wrote: > Follow-up Comment #21, bug #66143 (group groff): > > So, me again: I found the problem! I called make with CPPFLAGS=-v, > which displays the exact command line that is executed, in both my > environments (homebrew and outside). > > Inside the homebrew environment, there is a single additional include > path added: /opt/homebrew/include > > And lo and behold: > > > ls -ahl /opt/homebrew/include/ | grep uchar > lrwxr-xr-x 1 svenschober admin 41B Feb 13 2023 uchardet -> > ../Cellar/uchardet/0.0.8/include/uchardet
Aha! > _That_ is a symlink to the other place, where uchardet is installed, > and more importantly, _that_ is why an include of the form > `<uchardet/uchardet.h>` is working: > `/opt/homebrew/include/uchardet/uchardet.h` is existant. > > But not when that include path is missing. Right. > I can add that path via: > > ../configure --without-x --with-uchardet CPPFLAGS="-I/opt/homebrew/include" > > > 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. > 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"? > as long as the cpp source references > `<uchardet/uchardet.h>`? That just moves the problem. "uchardet.h" or "uchardet/uchardet.h", if the system doesn't supply it in /usr/include, odds are that _pkg-config_ will be necessary to locate it. And nobody, as far as I know is so prescriptivist about the Filesystem Hierarchy Standard (FHS) that they require that .h files have names resolvable _only_ from that directory. > 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. 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. > one by one and append the inclusion path. For just about anything that uses any library that isn't libc, the specification of `-I` is somewhere from strongly encouraged to mandatory. /usr/include itself has been getting more crowded with plain files for decades; as a result the name space collision problem re-asserts itself. > If there is no match, we get the error I am getting. But I could be > wrong. I think you're mostly on track. > I did some further digging and found another project using uchardet > via uchardets website: > > https://github.com/mpv-player/mpv/blob/0eb5e914d9699b6f7fb91ee383dedadc491b0d7d/misc/charset_conv.c#L67 > > They also include it without the directory. In this old branch of > another project the same: > > https://gitlab.gnome.org/World/gedit/libgedit-tepl/-/blob/tepl-3-0/tepl/tepl-file-loader.c > > But, I also found counter examples (using the qualified form): > > https://github.com/wang-bin/QtAV/blob/8bb780215bcd4a16d098a2a913d01f83b16193d7/config.tests/uchardet/main.cpp#L21 > > and > > https://github.com/eranif/codelite/blob/345332fca8ae6d29ca6615dccec81d92525bd6f1/LiteEditor/cl_editor.cpp#L102 Right. The _uchardet_ authors/maintainers didn't document their API, so people took guesses. I suspect that users of that API selected whatever happened to work on their system, if the first try didn't work, the second usually did, so "must have been right". > 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.) This unspecified status is common in the early stages of library development. The developers don't want to be wedded to mistaken decisions or held responsible for support of aspects of the interface that they had reason to reconsider. They want to be free to delete functions, change the arguments they take, rename data types, and even merge or split header files. Importantly, if the _uchardet_ developers had decided in early days to split "uchardet.h" into multiple files--maybe they'd want a "uchar.h" file too--it would be a pain in the butt to go and try to hunt up name collisions to see if they could claim a particular name. I reckon that at least some package maintainers, especially those with hard experience in GNU/Linux distributions, appreciated that the API was in flux, and so they gave _uchardet_'s header file a sandbox directory. If someone were to ask: "Why would you have a subdirectory of /usr/include for just one header file with the same name (barring the .h suffix) as the directory itself?" That'd be why. People downstream of the _uchardet_ developers had no idea what the future would hold. It appears that _uchardet_ began life as a paid development project of employees of the Mozilla Corporation. It's possible that these developers were suddenly "made redundant" and thus "uchardet.h" "stabilized"--by fossilizing as it was when the pink slips came down, like the half-finished breakfasts and open newspapers on the kitchen tables of Pripyat, Ukraine, in April 1986. That's tech sector capitalism for you--destruction is creative and while you can't turn a ship on a dime, you can fire people so fast that the optical Doppler shift is visible to the naked eye. > Otherwise, why use pkg-config then after all? To an extent, _pkg-config_ insulates software dependent on a library from disruptive changes to that library's interface at the coarsest level (where the header files and library objects are, and what they are named). There was, and is, an alternative--writing Autoconf tests to figure these things out. But few people find that more reliable, or enjoyable. Regards, Branden _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?66143> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
signature.asc
Description: PGP signature
