Re: [HACKERS] Include files for SPI are not installed
Tom Lane wrote: client-devel and server-devel are the right division IMHO. SPI is a subset of server-side development, but not all server-side code needs SPI. Consider user-written functions and datatypes. These guys do not Ok, I can do that. Obsoletes:devel here we come! My thought was that we'd remove spi.h from the minimal install, along with anything else that's not useful for client-side programming. Thus the standard install footprint would get smaller. I haven't looked to see exactly what the list of client-side headers should be, but if people like this idea I will do the legwork to make the list. Count me as liking it. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Include files for SPI are not installed
Oliver Elphick wrote: Certain include files are installed by src/include/Makefile and by interfaces/libpq++/Makefile. However, they in turn include others that are not installed, thus obviating the usefulness of the ones that are. The missing files are these: [snip] The list can be regenerated with the attached script. Or use this one-liner (CWD=the include directory in the source dist): /lib/cpp -M -I. -I../backend executor/spi.h | \ xargs -n 1| \ grep \\W| \ grep -v ^/| \ grep -v spi.o | \ grep -v spi.h | \ sort (There are better ways of doing the regexps, I know). I use this in the RPM spec file to pull over the SPI headers, and have had to do so since 6.5.x days. Bruce, can we add a TODO item for make install to install _all_ necessary headers, including SPI ones? It is not at all necessary to have a source tree lying around to do SPI development (or at least it _shouldn't_ be necessary). A full source tree, configured and built, according to du, takes about 48MB of space (a pristine tree takes 36MB or so in comparison). The complete set of headers takes a little less than 1MB of space. (1MB of _headers_? Yow!) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Include files for SPI are not installed
Karel Zak wrote: On Tue, 6 Feb 2001, Oliver Elphick wrote: Certain include files are installed by src/include/Makefile and by interfaces/libpq++/Makefile. However, they in turn include others that are not installed, thus obviating the usefulness of the ones that are. In your module you can use arbitrary routines from PG not only SPI, for example you trigger needs work with some datetypes and for this needs include anything from include/utils/ ... It expect install *all* header files. Not is better download PG sources and use -I option for your gcc? No. Full tree takes at minimum 36MB -- even pulling the _entire_ src/include tree over is only 2MB. I expect header files on /usr/include/pgsql for client programming not for SPI. Why? I know of several people doing SPI work with no source tree installed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Include files for SPI are not installed
Tom Lane wrote: I agree with Karel on this --- it's difficult to visualize doing useful SPI work without a source tree at hand, and it also seems unlikely that SPI authors would get along for long with *only* those header files needed to pull in spi.h. So I think it's pretty pointless to add just those header files. I'm waiting to see what Mike Mascari says about the issue, as he is doing SPI work from an RPM install (no source) and was the gadfly (in the best sense of the word) that got me putting the SPI headers in in the first place. Besides headers, what files are required? Makefile.global? Makefile.shlib? ??? What would make more sense is for the standard install to install only those headers needed for *client side* programming, and then to have an optional install target that installs the whole darn src/include tree. I can go for that. (Or in RPM terms, a client-devel RPM and a separate server-devel RPM that adds the rest of src/include.) Anything in between is guaranteed to be the wrong set of files. Ok, RPM users who do SPI work, sound off. Which would you like? I'll admit to liking the idea Tom has put forward, but I want more feedback. I would have a 'postgresql-devel' and a 'postgresql-devel-spi' -- to throw out a tentative name. I am loath to split the existing -devel subpackage into two packages with different names, throwing out the original, but I can do that as well, if that is the consensus. The contents of -devel would be the headers installed by 'make install' -- although I question why spi.h and some friends are installed in the first place, given the 'client-side' focus (but this _is_ what Tom just said -- I'm just being a little more specific). The contents of -devel-spi (or maybe just -spi) would be all the other headers (no duplicates) (again, expounding upon what Tom said already). Comments? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Include files for SPI are not installed
I agree with Karel on this --- it's difficult to visualize doing useful SPI work without a source tree at hand, and it also seems unlikely that SPI authors would get along for long with *only* those header files needed to pull in spi.h. So I think it's pretty pointless to add just those header files. What would make more sense is for the standard install to install only those headers needed for *client side* programming, and then to have an optional install target that installs the whole darn src/include tree. (Or in RPM terms, a client-devel RPM and a separate server-devel RPM that adds the rest of src/include.) Anything in between is guaranteed to be the wrong set of files. Agreed. I hesitate to copy all those *.h files when few people use them. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] Include files for SPI are not installed
Lamar Owen [EMAIL PROTECTED] writes: Tom Lane wrote: What would make more sense is for the standard install to install only those headers needed for *client side* programming, and then to have an optional install target that installs the whole darn src/include tree. I can go for that. (Or in RPM terms, a client-devel RPM and a separate server-devel RPM that adds the rest of src/include.) Anything in between is guaranteed to be the wrong set of files. Ok, RPM users who do SPI work, sound off. Which would you like? I'll admit to liking the idea Tom has put forward, but I want more feedback. I would have a 'postgresql-devel' and a 'postgresql-devel-spi' -- to throw out a tentative name. I am loath to split the existing -devel subpackage into two packages with different names, throwing out the original, but I can do that as well, if that is the consensus. client-devel and server-devel are the right division IMHO. SPI is a subset of server-side development, but not all server-side code needs SPI. Consider user-written functions and datatypes. These guys do not need SPI (usually), but they do need access to header files that aren't installed now. The contents of -devel would be the headers installed by 'make install' -- although I question why spi.h and some friends are installed in the first place, given the 'client-side' focus (but this _is_ what Tom just said -- I'm just being a little more specific). My thought was that we'd remove spi.h from the minimal install, along with anything else that's not useful for client-side programming. Thus the standard install footprint would get smaller. I haven't looked to see exactly what the list of client-side headers should be, but if people like this idea I will do the legwork to make the list. regards, tom lane
