Thread: #include oddity in v7.0b3
[ Cc'ed to the XEmacs development list and the postgres debian package maintainer ] Hi! After upgrading my debian system (woody), the postgres package went from 6.5 to 7.0b3. On debian linux boxes, the postgres headers are located under /usr/include/postgresql/. The file `libpq-fe.h' #include's the file `postgres_ext.h' using <> instead of "" (line 27). As a consequence, applications that just do: | #include <full/path/to/libpq-fe.h> can't build anymore because the file `postgres_ext.h' is not in the path. This happens to be the case for XEmacs. I believe this is a bug because: 1/ this didn't happen with my former version 6.5 2/ the usage of <> or "" doesn't seem to be coherent among the headers 3/ it's better to use "" when headers installed in the same place have to include each others What do you think ? Was this change intentional ? Thanks. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier@lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
Didier Verna <didier@xemacs.org> writes: > The file `libpq-fe.h' #include's the file `postgres_ext.h' using <> > instead of "" (line 27). As a consequence, applications that just do: > | #include <full/path/to/libpq-fe.h> > can't build anymore because the file `postgres_ext.h' is not in the path. > What do you think ? Was this change intentional ? It was. Someone else complained that the other way didn't work for them. At least from the point of libpq, I think they were right. Offhand, if you do not put -I into your compile switches, I'd be somewhat surprised that either way would work for you. Certainly hardcoding a full path into application source code is a completely unportable way to do things... regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> wrote: > > What do you think ? Was this change intentional ? > > It was. Someone else complained that the other way didn't work for them. > At least from the point of libpq, I think they were right. I don't understand why. Could you explain ? > Certainly hardcoding a full path into application source code is a > completely unportable way to do things... Obviously, we're smarter than that. I had simplified the example to point at the problem clearly. Since we've already encountered different possible locations for postgresql headers, we actually detect their location at configure time, #define a macro containing the path, and use something like #include <THE_PATH/the_file.h> (this is yet simplified, but that's the idea). But that's not the point. When an application has to include a single header from a library, and when this application knows where to find it, it should be able to include it directly without special cpp cooking. That's why headers installed in the same place should use "" and not <> to #include each others. The only valid reason for this change I can see is that libpq-fe.h and postgres_ext.h could happen to be installed at different locations. Can this be the case ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier@lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
On Mon, Apr 10, 2000 at 01:45:39PM -0400, Tom Lane wrote: > Offhand, if you do not put -I into your compile switches, I'd be > somewhat surprised that either way would work for you. Certainly > hardcoding a full path into application source code is a completely > unportable way to do things... Not when it's autoconf that does the hardcoding :-) With the number of external librairies we use, the amount of -I was becoming a bit too high for our tastes... OG.
Didier Verna <didier@xemacs.org> writes: > Obviously, we're smarter than that. I had simplified the > example to point at the problem clearly. Since we've already > encountered different possible locations for postgresql headers, we > actually detect their location at configure time, #define a macro > containing the path, and use something like #include > <THE_PATH/the_file.h> (this is yet simplified, but that's the idea). The usual way to do this is to detect the location and then add a -I switch to your compile switches. But I suppose XEmacs is smarter than every other project on the planet. > But that's not the point. When an application has to include a single > header from a library, and when this application knows where to find it, it > should be able to include it directly without special cpp cooking. That's why > headers installed in the same place should use "" and not <> to #include each > others. Where in the ANSI C spec does it say that #include "" behaves that way and #include <> doesn't? Where does it even say that you're allowed to specify a path in #include at all? It seems to me you are treating an implementation choice made by your compiler as gospel. (Yes, I know gcc behaves that way.) > The only valid reason for this change I can see is that > libpq-fe.h and postgres_ext.h could happen to be installed at > different locations. Can this be the case ? That is the case at build time, for example. I think the previous complainer was unhappy about what his compiler did (or maybe what his makefile dependency generator did) while building one of the other Postgres interface libraries or executables that depend on libpq. Unfortunately the details seem to have vanished into the mailing list lossages we had last month. I should make it clear that I agree with you: include "" makes more sense than include <> in this context, and IIRC I argued against changing it at the time. But I can't see putting much weight on arguments that are based on a practice as unusual and non-standards- compliant as putting full paths directly into #include commands. In the normal context where search paths are driven by -I, it won't matter which form we use. Give me a better reason, and I'll change it back. But I don't want to have to explain to the other guy that we're not going to support his situation just to make the world safe for an arguably broken coding method, even if it is one used by a project as big as XEmacs. regards, tom lane
Didier Verna wrote: > >[ Cc'ed to the XEmacs development list and the postgres debian package > maintainer ] > > Hi! > > After upgrading my debian system (woody), the postgres package went >from 6.5 to 7.0b3. On debian linux boxes, the postgres headers are located >under /usr/include/postgresql/. > > The file `libpq-fe.h' #include's the file `postgres_ext.h' using <> >instead of "" (line 27). As a consequence, applications that just do: > >| #include <full/path/to/libpq-fe.h> > >can't build anymore because the file `postgres_ext.h' is not in the path. Th >is >happens to be the case for XEmacs. I believe this is a bug because: > >1/ this didn't happen with my former version 6.5 >2/ the usage of <> or "" doesn't seem to be coherent among the headers >3/ it's better to use "" when headers installed in the same place have to > include each others The Debian documentation used to include a statement that `-I/usr/include/postgresql' should be included in the compilation options. That seems to have got lost. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 ======================================== "But seek ye first the kingdom of God, and his righteousness; and all these things shall be added unto you." Matthew 6:33
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: Tom> Where in the ANSI C spec does it say that #include "" behaves Tom> that way and #include <> doesn't? Where does it even say Tom> that you're allowed to specify a path in #include at all? It Consider X11. The normal procedure is to include via forms like <X11/Xlocale.h>. A compiler that doesn't support that may be ANSI-compliant. I doubt it will be used much, and certainly not for building XEmacs. Tom> seems to me you are treating an implementation choice made by Tom> your compiler as gospel. (Yes, I know gcc behaves that way.) I'll stipulate that you're right about the specs; it is simply the fact that the "detect the path" method is working well for us in other cases. This is the first time it has broken for us because the assumption that "" would find all recursively included headers installed in the same place failed. As for "our compiler", do you mean the HPUX compiler, MS VC++, the AIX compiler, the IRIX compiler, the DEC compiler, Solaris's compiler, or what? Not only does XEmacs build under all those compilers IIRC, but it also builds under at several C++ compilers without changing the code. XEmacs must be built under as many compilers as PostgreSQL. It's probably true that the most-used compiler is GCC. That's why we regularly see patches being rejected, even reversed, for depending on GCCisms. If this is a GCCism, it can be reversed, too. But as far as I know, all compilers used to build XEmacs do includes the way our code expects. That's a lot of compilers! And the current PostgreSQL 7.0b3 setup will break every single one of them as far as XEmacs is concerned. Tom> But I can't see putting much weight on arguments that are Tom> based on a practice as unusual and non-standards-compliant "Portability" means never being able to say "we're standards-compliant." Heck, we build on the MS Windows platform. "Standards? We embrace, extend, and, ultimately, extinguish." 100% compliance is impossible (notwithstanding the foreseeable breakup of Microsoft). The reason we use the method we do is to localize the non-compliant code to a very few well-known places, and only when conditional on the platforms that need it. It's a fact of life for multi-platform applications, as you are arguing yourself (see below), that some platforms will choose to do things differently. Just as you do, we want to support those platforms. We prefer to do so in a way that hides their differences from the main body of source code where possible. We think it improves maintainability. We could use the `-I' method, but who knows what other cruft we'll pick up on some systems? XEmacs _is_ rather unusual in that we currently automatically detect and use nearly a score of add-on capabilities by default, and have several configure options whose default is off, but when "on" also search for and automatically configure perhaps a dozen more. I think that making such versatility maintainable is deserving of your support. Putting in more than 20 `-I's means we cannot guarantee where anything will get included from. We know from past experience that we cannot rely on packages to have their devel support files in sensible places, not even on platforms like Debian which claim strict adherence to a file system standard. Certainly not cross-platform! With short names like "libpq-fe.h" and "drop-in replacement" libraries like Xaw3d as common as they are, we also need to find a way to avoid name collisions on the preprocessor's include path. Our approach allows a flexible response to both unusual locations for devel support files and collisions, without excessively uglifying the source files. I think it is equally arguable that in the real world any subsystem which knows where its headers are but doesn't use that information, and instead relies on `-I' to find them, is broken, since `-I' is broken by design in regard to collisions. There doesn't seem to be an ANSI way of specifying the recursive header location information, but both `"" searches current directory' and `<app-includes/header.h>' as used by X11 seem to work well enough in practice. The `""' approach seems preferable, since it allows for glitches like Debian's renaming of the PostgreSQL application includes directory. But the current PostgreSQL setup doesn't support either of these methods. Tom> as putting full paths directly into #include commands. In But we don't actually use full paths anyway; in the case of PostgreSQL 7.0 under Debian "woody", the path that CPP eventually sees is <postgresql/libpq-fe.h> (by expansion of POSTGRES_INCLUDE(libpq-fe.h); it's done that way so that we don't need to clutter source code with #ifdef's for different systems or remember to munge all source files dealing with a given 3rd-party package: the POSTGRES_INCLUDE macro is defined in one place, src/config.h). In the end, just like X11. And also do note that ./configure has actually located and confirmed the usability of the header file in question. This is not hard-coded; it is autodetected. Tom> the normal context where search paths are driven by -I, it Tom> won't matter which form we use. If that's so, then ... Tom> Give me a better reason, and I'll change it back. But I Tom> don't want to have to explain to the other guy that we're not Tom> going to support his situation just to make the world safe Tom> for an arguably broken coding method, even if it is one used Tom> by a project as big as XEmacs. ... if the _other_ user is using the "search path driven by -I" method, then he _can't_ be broken by supporting our practice according to your argument. I infer _he's_ also doing something "arguably broken." A matter of taste which to support. No? We know our way works simultaneously for several add-on packages and on many compilers. Maybe it or something similar would work for him, too. Personally, I'm not going to be upset if you decide that you are going to treat "" and <> as interchangable in PostgreSQL header files, to support somebody else's brokenness in preference to ours. In practice we can accede to your demand that we treat PostgreSQL specially. I'm just not willing to accept the argument that we're badly broken when all the compilers we buld under seem to support the `"" searches current directory, <> does not (unless specified by -I)' distinction. Our experience is that making this assumption allows us to minimize brokenness subject to localizing brokenness to known places as much as possible. Brokenness exists. Given that, I think our goal of minimizing and localizing it is deserving of your support. I think that it is true that our coding practice improves maintainability, and I hope you will give that due consideration. (Of course in combination with finding some way to support your other client projects.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."
I am that other guy. We have fixed our dependency maker in the meantime. Here is the last state of the previous discussion again: Regards, Andreas Kardos ------------------------- "Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes: OK, but in general it is not usual that a system header includes another system header with #include "" (from the application programmers point of view). I do not intend to break the consistency of the PostgreSQL make system. So feel free to rollback. But to be consistent you should replace at least the following includes as well: ecpglib.h:#include <postgres.h> ecpglib.h:#include <libpq-fe.h> ecpglib.h:#include <ecpgerrno.h> Next week I will discuss the situation with our guy who is responsible for this dependency maker. He is currently out of town. Regards, Andreas Kardos -----Ursprüngliche Nachricht----- Von: Tom Lane <tgl@sss.pgh.pa.us> An: Kardos, Dr. Andreas <kardos@repas-aeg.de> Cc: Bruce Momjian - CVS <momjian@news.tht.net>; <pgsql-committers@postgresql.org> Gesendet: Donnerstag, 23. März 2000 17:49 Betreff: Re: [COMMITTERS] pgsql/src/interfaces/libpq (libpq-fe.h) > "Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes: > > The reason is: We are using at here for historical reasons our own make > > system for applications. Our dependency maker assumes that a file must be in > > the local source directory if it is included by > > #include "file" > > OK, this is a lack of this dependency maker. To solve this (our) specific > > problem I must copy or symlink postgres_ext.h to the local source directory. > > Hmm. So, to cater to a dependency maker that you admit is broken, we > should change the sources so that they'll generate wrong output on non- > broken dependency makers? > > Since postgres_ext.h hardly ever changes, and probably can't change > without a system-wide recompile, the lack of a dependency for it isn't > likely to be real critical. So I'll let this slide for now. But if > someone else complains, I'll change it back ;-). Consider that you've > been given a grace period to fix your dependency analyzer. > > regards, tom lane > -----Ursprüngliche Nachricht----- Von: Tom Lane <tgl@sss.pgh.pa.us> An: Didier Verna <didier@xemacs.org> Cc: <bugs@postgresql.org>; XEmacs beta testers <xemacs-beta@xemacs.org>; Oliver Elphick <Oliver.Elphick@lfix.co.uk> Gesendet: Montag, 10. April 2000 21:15 Betreff: Re: [BUGS] #include oddity in v7.0b3 > Didier Verna <didier@xemacs.org> writes: > > Obviously, we're smarter than that. I had simplified the > > example to point at the problem clearly. Since we've already > > encountered different possible locations for postgresql headers, we > > actually detect their location at configure time, #define a macro > > containing the path, and use something like #include > > <THE_PATH/the_file.h> (this is yet simplified, but that's the idea). > > The usual way to do this is to detect the location and then add a -I > switch to your compile switches. But I suppose XEmacs is smarter than > every other project on the planet. > > > But that's not the point. When an application has to include a single > > header from a library, and when this application knows where to find it, it > > should be able to include it directly without special cpp cooking. That's why > > headers installed in the same place should use "" and not <> to #include each > > others. > > Where in the ANSI C spec does it say that #include "" behaves that way > and #include <> doesn't? Where does it even say that you're allowed to > specify a path in #include at all? It seems to me you are treating an > implementation choice made by your compiler as gospel. (Yes, I know gcc > behaves that way.) > > > The only valid reason for this change I can see is that > > libpq-fe.h and postgres_ext.h could happen to be installed at > > different locations. Can this be the case ? > > That is the case at build time, for example. I think the previous > complainer was unhappy about what his compiler did (or maybe what his > makefile dependency generator did) while building one of the other > Postgres interface libraries or executables that depend on libpq. > Unfortunately the details seem to have vanished into the mailing list > lossages we had last month. > > I should make it clear that I agree with you: include "" makes more > sense than include <> in this context, and IIRC I argued against > changing it at the time. But I can't see putting much weight on > arguments that are based on a practice as unusual and non-standards- > compliant as putting full paths directly into #include commands. > In the normal context where search paths are driven by -I, it won't > matter which form we use. > > Give me a better reason, and I'll change it back. But I don't want > to have to explain to the other guy that we're not going to support > his situation just to make the world safe for an arguably broken > coding method, even if it is one used by a project as big as XEmacs. > > regards, tom lane >
Tom Lane <tgl@sss.pgh.pa.us> wrote: > The usual way to do this is to detect the location and then add a -I > switch to your compile switches. But I suppose XEmacs is smarter than > every other project on the planet. Please tell me M. Lane, what makes you react so aggressively ? > Where in the ANSI C spec does it say that #include "" behaves that way > and #include <> doesn't? Where does it even say that you're allowed to > specify a path in #include at all? C'mon. This is pure and simple bad faith. Postgresql itself has examples of using "" and <>, and paths in inclusion macros. Don't get me wrong on this: all XEmacs strictly requires to compile is an ANSI C compiler. > It seems to me you are treating an implementation choice made by your > compiler as gospel. (Yes, I know gcc behaves that way.) *your* compiler ? XEmacs compiles on Suns, PCs (Unix and Windows), HPs, SGIs, DECs with gcc but native compilers also. That makes a lot of platforms. On all of these platforms, the preprocessor works the way the ANSI C spec doesn't specify. Geeze, if we follow your reasoning, one couldn't even compile the simplest X11 application. > I should make it clear that I agree with you: include "" makes more > sense than include <> in this context, That's surprising to hear, to say the least. > and IIRC I argued against changing it at the time. But I can't see putting > much weight on arguments that are based on a practice as unusual and > non-standards- compliant as putting full paths directly into #include > commands. I'm sorry about this, I should have made it clearer. It's not full path actually. On my debian woody system, it expands to: #include <postgresql/libpq-fe.h> just like you would #include <X11/Intrinsic.h> and _this doesn't work anymore_. > In the normal context where search paths are driven by -I, it won't matter > which form we use. The context you're talking about is not more "normal" than any other. -I is broken by concept in many respects. But the most important is that dozens of -I on the command line is actually not portable because command lines too long can break some systems. Standards are a good think, but we're concerned by portability first. > Give me a better reason, and I'll change it back. But I don't want > to have to explain to the other guy that we're not going to support > his situation just to make the world safe for an arguably broken > coding method, even if it is one used by a project as big as XEmacs. "The other guy" for sure must do something as broken as we do. The size of XEmacs has nothing to do with this. Tom, let me make this clear: we support many different packages differently installed on different platforms. We always try to be as compliant as possible with the standards, and write tricks for very special cases only. When such tricks are needed, we hide them as much as possible (most of the time under the form of a configure test and one or two macros). The way we include `libpq-fe.h' (see above) is not unusual at all. Currently, *only* postgres 7.0 breaks this scheme. That sounds to me as a good enough reason. One more thing: I was trying to have a constructive discussion with you. We could perfectly well make a special case for postgresql. No problem. We do that already for soooo many broken stuff that we support. However, my policy has always been to try to try first to cooperate with external software developers before writing tricks. I don't know if something was wrong in my english wording, but I must say that in this context, I'm rather upset by your reaction. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier@lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
On Tue, 11 Apr 2000, Stephen J. Turnbull wrote: > Consider X11. The normal procedure is to include via forms like > <X11/Xlocale.h>. A compiler that doesn't support that may be > ANSI-compliant. I doubt it will be used much, and certainly not for > building XEmacs. The way I see it, the only thing you can reasonably assume is that given #include <foo> (where "foo" is any string) the compiler will try to consider a file XXXfoo, for each XXX in the search path for include files (which is partially hard-coded into the compiler and partially controlled by setting -I or similar options and may or may not include the current directory, or the directory the containing file is in). You cannot assume that "" does anything differently than <>. The difference is cosmetic. > I'll stipulate that you're right about the specs; it is simply the > fact that the "detect the path" method is working well for us in other > cases. This is the first time it has broken for us because the > assumption that "" would find all recursively included headers > installed in the same place failed. I did a quick scan of my system and both practices are used equally widely, so unless you intend to address all the authors of all the other packages as well I suggest you give it up. > We could use the `-I' method, but who knows what other cruft we'll pick > up on some systems? Everybody uses the '-I method'. If you have too many -I's all at once I suggest either not bothering, or modularizing your code. > Putting in more than 20 `-I's means we cannot guarantee where anything > will get included from. If people have duplicatedly named header files in the default search paths chances are that *anything* that will use them is going to break. There is no grand-unified work around so people will have to get down to organizing their system sooner or later. Just because you guys are constantly trying to subvert autoconf there's no reason to let it out on us. :-/ Okay, now *why* does XEmacs need PostgreSQL? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <e99re41@DoCS.UU.SE> wrote: > You cannot assume that "" does anything differently than <>. The difference > is cosmetic. Really, I'd like you to point me to one known C preprocessor that does not make the difference. Standards are a good thing, but they are not immutable, and the evolution leans towards this semantic difference between "" and <>. It's already explicit in C++ for instance. If 99% of the preprocessors of the planet work a certain way, I don't see anything wrong in following a de-facto convention, and I'd encourage people to conform to it, in view to a very probable standardization. That's exactly what happened in this particular case. > I did a quick scan of my system and both practices are used equally > widely, so unless you intend to address all the authors of all the other > packages as well I suggest you give it up. 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. We usually try to "address the authors of the packages we interact with". This policy is IMHO of a better citizenship. > Everybody uses the '-I method'. If you have too many -I's all at once I > suggest either not bothering, or modularizing your code. Please, don't you think we already have modularized code ? We're not trying to find a solution to our problem here. We're trying to find the *cleanest* solution for *everybody*. Why don't you want to understand that ? Without any modification on your part, we know how to fix the problem in at least 3 different manners. But that's just not the point. 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.". What's wrong with that ?! Given that Tom actually seems to agree with this, and given the answer of the Andres Kardos' answer, I don't understand your attitude here. > Just because you guys are constantly trying to subvert autoconf there's no > reason to let it out on us. :-/ *subvert* autoconf ?! We're using autoconf exactly in the way it is done for: to make the life of our users better. > Okay, now *why* does XEmacs need PostgreSQL? 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. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier@lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
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
Peter Eisentraut <e99re41@DoCS.UU.SE> writes: > 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. This in fact one of the problems that caused us to switch to the newer inclusion mechanism. (prompted by the mess that is libXawXXXX) Jan P.S. I would be interested in knowing what problem the user had for which you made change. Maybe it is relevant for use too?
Peter Eisentraut <e99re41@DoCS.UU.SE> wrote: > > 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. Please read my messages carefully. We *don't* have 20 -I one the command line, and we don't want to. That's the whole point. Obviously, we can rewrite particular targets in Makefile.in in order to add the proper -I flags only to the concerned sources. We have to do this already at some places. However, this is even dirtier and we want to avoid this as much as possible. > See above what the cleanest solution for everybody might be and why this > one certainly isn't. This one doesn't prevent you from using the other one, if you consider it cleaner which is arguable. On the contrary, the current state breaks our solution, without bringing any benefit to anybody (see Andreas'message). > The bottom line is that what you're trying is not the way things were > supposed to work. "supposed to work" sounds really subjective in this context. Anyway, that shouldn't prevent us from improving the software by making it work other ways too (let me remind you that it worked before 7.0). > 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. You can't image how much you're right !! Postgres happens to install a header file named `config.h' in its installation directory. As a consequence, if we follow your reasoning and if, as you suggest, we don't rely on the semantic difference of "" and <>, no application using autoconf will be able to compile a postgres support !! There's really nothing to be proud of :-( > Rewriting almost every single provided macro in order to disable the cache > surely sounds like subversion to me. It is not. It is trying to improve autoconf when we find deficiencies (just like I'm trying to do with you here): the autoconf developers are aware of this and as a matter of fact, the next version of autoconf will have the cache disable by default. Our script will little by little get simpler, as both communities will benefit from the work. That's the way I like free software development the more. > > 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. Yes :-). Thank Steven Baur for that. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier@lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
"Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes: > I am that other guy. We have fixed our dependency maker in the meantime. Well, given that Andreas no longer cares, I'm happy to change it back to the way it was. "" is definitely more consistent with what we have done in other include files. regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kardos, Dr. Andreas" <kardos@repas-aeg.de> writes: > > I am that other guy. We have fixed our dependency maker in the meantime. > > Well, given that Andreas no longer cares, I'm happy to change it back to > the way it was. "" is definitely more consistent with what we have done > in other include files. Great, thanks Tom ! -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier@lrde.epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99