Follow-up Comment #15, bug #66143 (group groff): [comment #14 comment #14:] > Hi Branden! > > To answer your questions first: >
> grep UCHARDET_ config.status
> S["UCHARDET_LIBS"]="-L/opt/homebrew/Cellar/uchardet/0.0.8/lib -luchardet"
>
S["UCHARDET_CFLAGS"]="-I/opt/homebrew/Cellar/uchardet/0.0.8/include/uchardet"
Okay.
> and
>
> pkg-config --cflags "uchardet"
> -I/opt/homebrew/Cellar/uchardet/0.0.8/include/uchardet
> pkg-config --libs "uchardet"
> -L/opt/homebrew/Cellar/uchardet/0.0.8/lib -luchardet
Okay. So our build variables are being faithfully populated by the output of
_pkg_config_. That's good!
> So, I think this is equivalent to your path, just with a different prefix.
Looks that way to me, too.
> But, in the mean time I no longer think pkg-config, or autotools is at fault
here.
>
> My somewhat bold claim would be, that the #include statement with a
subdirectory is simply wrong and works only accidentally on systems where
/usr/include is on the default search path.
I disagree. Remember that C is a language without name spaces. So is C++,
when it comes to names of header files. (Or, at most, there are two name
spaces--the "system" name space accessed with `#include <whatever.h>` and the
"local" name space accessed with `#include "whatever.h"`.
Even if every library on your system has complete and accurate _pkg-config_
coverage, that tool cannot control the _order_ in which `-I`-included
directories are searched.
And that creates a problem.
What if, as is likely in C, multiple libraries exist with their own header
file for fairly basic data structures?
list.h
stack.h
dictionary.h
Or other fairly common concerns?
db.h
charenc.h
Which one the preprocessor will find depends on `-I` flag ordering.
Thus a tradition arose fairly early in the days of C programming--after the
_curses_ library revealed the full horror of the Bell Labs CSRC's failure to
contemplate name space matters when designing the language (ironically enough,
a matter of "not planning for success")--of stuffing header files for things
other than the C standard library into subdirectories named for the
project/package, leveraging the hierarchical structure of the file system for
a crude but effective name spacing system.
Thus, to take another hoary and early example:
#include <X11/Core.h>
#include <X11/Intrinsics.h>
#include <X11/Xos.h>
If _pkg-config_ existed back then, should it have directed people to rip the
"X11/"s out of these directives, trusting that `pkg-config --cflags libx11`
and `pkg-config --cflags libxt` would suffice to locate these header files
*uniquely*?
No.
> Works fine on both systems, as only now the pkg-config generated includes
are heeded. What do you think? Can you reproduce this on your systems?
To be honest, I didn't try, because I've concluded that Homebrew is
misconfiguring _uchardet_'s _pkg-config_ output.
Feel free to direct Homebrew developers to this ticket. Maybe I'm wrong.
And I could be, because I do note my own comment #13.
> $ pkg-config --cflags uchardet
-I/usr/include/uchardet
But I further note that _uchardet_ offers no man page documenting the API, of
which the full #include directive is a part in C and C++. As a programmer,
technical writer, and grumpy old man, my opinion of that lacuna can be
guessed. That `pkg-config --cflags uchardet` is working on my system is no
endorsement if that fact is due to chance.
Alternatively, or in addition, we have some macOS, and Homebrew, users on the
_groff_ mailing list. So you might mail groff@gnu dot org and ask for
opinions from people. Also please consider subscribing to that list if you're
not already.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?66143>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
