Re: #include oddity in v7.0b3
От | Didier Verna |
---|---|
Тема | Re: #include oddity in v7.0b3 |
Дата | |
Msg-id | muxya6ln83a.fsf@uzeb.lrde.epita.fr обсуждение исходный текст |
Ответ на | #include oddity in v7.0b3 (Didier Verna <didier@xemacs.org>) |
Ответы |
Re: #include oddity in v7.0b3
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: