Re: #include oddity in v7.0b3

On 11 Apr 2000, Didier Verna wrote:

> That's indeed the two attitudes one can adopt. Either you do your on
> personal little cruft alone in your corner, or you try to talk with people.

I'm not doing that, I'm just saying that your mission is extremely tough.
I don't really care regarding the original issue of "" vs <> but
considering that you can't rely on this other than on a package by package
and version by version basis your solution is going to be a kludge to the
very end. If you really want to go through with it (substituting absolute
paths into #include statements, that is) I suggest you write a configure
test to see if it works and only use it if it does.

> Please, don't you think we already have modularized code ?

If you have 20 -I's on the compile line, perhaps not, although I'm not to
judge here.

> We're not trying to find a solution to our problem here. We're trying
> to find the *cleanest* solution for *everybody*.

See above what the cleanest solution for everybody might be and why this
one certainly isn't.

> Let me rephrase what I originally wanted to underline:
>
> - Joe provides a library libfoo.
> - Joe provides a header libfoo.h, located at /usr/include/libfoo/libfoo.h in
> order to use the library.
>
> Now if this program:
>
> | #include <libfoo/libfoo.h>
> | main () {}
>
> can't compile, then, I consider that the installation of the library is
> broken, and instead of writing yet another trick in my code, I say to myself
> "OK I should tell Joe about this.".

The only difference is that we provide a header file which is supposed to
be included as #include <libpq-fe.h>. If you do that then it works. If the
location of this header file is not in the search path for include files,
then tell your compiler about it. The names used in #include are
immutable, they are not expected to follow file system semantics. The
bottom line is that what you're trying is not the way things were supposed
to work. All I'm saying is that you might want to consider not doing it.
There is no harm in having 20 -I's on the compile line unless the user has
more than one header file with the same name on his system, in which case
most everything else on it is going to break as well.

> *subvert* autoconf ?! We're using autoconf exactly in the way it is
> done for: to make the life of our users better.

Rewriting almost every single provided macro in order to disable the cache
surely sounds like subversion to me. (But I agree that the cache is evil.)

> XEmacs doesn't need postgresql. It nows supports it, which means
> people can write Emacs Lisp packages interfacing with postgres databases, and
> benefit from the XEmacs editing features and environment.

Cool.

--
Peter Eisentraut Sernanders väg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden