Re: #include oddity in v7.0b3 - Mailing list pgsql-bugs
From | Peter Eisentraut |
---|---|
Subject | Re: #include oddity in v7.0b3 |
Date | |
Msg-id | Pine.GSO.4.02A.10004111414410.7708-100000@Myrslok.DoCS.UU.SE Whole thread Raw |
In response to | Re: #include oddity in v7.0b3 (Didier Verna <didier@xemacs.org>) |
List | pgsql-bugs |
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@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
pgsql-bugs by date: