Thread: test/example does not support win32.
Hi. test/example does not support win32. Although I posted also in the past, I am slightly persistent. I think whether it also needs correction of a document. == CVS-HEAD on as for MinGW + gcc == testlibpq2.c: In function `main': testlibpq2.c:98: error: `fd_set' undeclared (first use in this function) testlibpq2.c:98: error: (Each undeclared identifier is reported only once testlibpq2.c:98: error: for each function it appears in.) testlibpq2.c:98: error: syntax error before "input_mask" testlibpq2.c:105: warning: implicit declaration of function `FD_ZERO' testlibpq2.c:105: error: `input_mask' undeclared (first use in this function) testlibpq2.c:106: warning: implicit declaration of function `FD_SET' testlibpq2.c:108: warning: implicit declaration of function `select' make: *** [testlibpq2] Error 1 testlibpq3.c: In function `show_binary_results': testlibpq3.c:82: error: `uint32_t' undeclared (first use in this function) testlibpq3.c:82: error: (Each undeclared identifier is reported only once testlibpq3.c:82: error: for each function it appears in.) testlibpq3.c:82: error: syntax error before ')' token testlibpq3.c: In function `main': testlibpq3.c:115: error: `uint32_t' undeclared (first use in this function) testlibpq3.c:115: error: syntax error before "binaryIntVal" testlibpq3.c:183: error: `binaryIntVal' undeclared (first use in this function) testlibpq3.c:183: error: syntax error before numeric constant make: *** [testlibpq3] Error 1 Please take into consideration. Regards, Hiroshi Saito
Attachment
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
> test/example does not support win32.
The proposed added #includes seem quite inappropriate. postgres_fe.h
is meant for PG-project code, it is not supposed to have to be included
by all end-user code.
regards, tom lane
Hi Tom-san. Um, How do you consider sample which cannot build? Regards, Hiroshi Saito ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> > "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes: >> test/example does not support win32. > > The proposed added #includes seem quite inappropriate. postgres_fe.h > is meant for PG-project code, it is not supposed to have to be included > by all end-user code. > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
Hiroshi Saito wrote: > Hi Tom-san. > > Um, How do you consider sample which cannot build? I think testlibpq2.c is missing a couple of system includes, sys/types.h and unistd.h (or alternatively select.h); and testlibpq3.c is missing stdint.h. Or so say my (POSIX) manpages anyway. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Hi Alvaro-san. Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set complains.... Thanks! It seems that pg_bench takes the thing same again into consideration. Anyway, If it is called example of end-user code, what is the evasion method of fd_set? Regards, Hiroshi Saito ----- Original Message ----- From: "Alvaro Herrera" <alvherre@commandprompt.com> > Hiroshi Saito wrote: >> Hi Tom-san. >> >> Um, How do you consider sample which cannot build? > > I think testlibpq2.c is missing a couple of system includes, sys/types.h > and unistd.h (or alternatively select.h); and testlibpq3.c is missing > stdint.h. Or so say my (POSIX) manpages anyway. > > -- > Alvaro Herrera http://www.CommandPrompt.com/ > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
> Yes, I thinks that it is an exact idea. However, this example was not helped.
> fd_set complains....
> Thanks!
> It seems that pg_bench takes the thing same again into consideration.
> Anyway, If it is called example of end-user code, what is the evasion method
> of fd_set?
On reflection I think it's just wrong to expect that the examples will
compile out-of-the-box on every platform. The only way that that can
possibly happen is if they depend on our configuration infrastructure,
which is exactly what I feel they should not depend on. Any client
program that has ambitions of portability is going to have its own
autoconf stuff, so injecting ours into a piece of sample code is just
going to result in headaches. Even including only pg_config.h would
be a serious invasion of application namespace.
Looking at pgbench, or any other one of our client-side programs,
is not relevant to the point here. Those programs *are* supposed
to rely on the PG autoconf environment.
We can certainly add some more standard #includes to the examples
if they're obviously missing some. But that isn't going to get us
to a point where they'll compile everywhere without change.
regards, tom lane
Tom Lane wrote: > "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes: > > Yes, I thinks that it is an exact idea. However, this example was not helped. > > fd_set complains.... > > Thanks! > > > It seems that pg_bench takes the thing same again into consideration. > > Anyway, If it is called example of end-user code, what is the evasion method > > of fd_set? > > On reflection I think it's just wrong to expect that the examples will > compile out-of-the-box on every platform. The only way that that can > possibly happen is if they depend on our configuration infrastructure, > which is exactly what I feel they should not depend on. Any client > program that has ambitions of portability is going to have its own > autoconf stuff, so injecting ours into a piece of sample code is just > going to result in headaches. Even including only pg_config.h would > be a serious invasion of application namespace. > > Looking at pgbench, or any other one of our client-side programs, > is not relevant to the point here. Those programs *are* supposed > to rely on the PG autoconf environment. > > We can certainly add some more standard #includes to the examples > if they're obviously missing some. But that isn't going to get us > to a point where they'll compile everywhere without change. Well, those example programs are pretty clean libpq apps so I don't see why they should using platform-specific stuff. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Well, those example programs are pretty clean libpq apps so I don't see
> why they should using platform-specific stuff.
Example #2 depends on select(), which depends on fd_set, so you're
already into territory where there are issues.
regards, tom lane
Tom Lane wrote: > "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes: > >> Yes, I thinks that it is an exact idea. However, this example was not helped. >> fd_set complains.... >> Thanks! >> > > >> It seems that pg_bench takes the thing same again into consideration. >> Anyway, If it is called example of end-user code, what is the evasion method >> of fd_set? >> > > On reflection I think it's just wrong to expect that the examples will > compile out-of-the-box on every platform. The only way that that can > possibly happen is if they depend on our configuration infrastructure, > which is exactly what I feel they should not depend on. Any client > program that has ambitions of portability is going to have its own > autoconf stuff, so injecting ours into a piece of sample code is just > going to result in headaches. Even including only pg_config.h would > be a serious invasion of application namespace. > > Looking at pgbench, or any other one of our client-side programs, > is not relevant to the point here. Those programs *are* supposed > to rely on the PG autoconf environment. > > We can certainly add some more standard #includes to the examples > if they're obviously missing some. But that isn't going to get us > to a point where they'll compile everywhere without change. > > > That would be all good and well if we didn't already rely on the configure setup. But we do - the Makefile includes src/Makefile.global, which is built by configure. Anyway, let's see how far we can get with including some standard header files. cheers andrew
Hi Andrew-san. Although this is a standard in windows. *** testlibpq2.c.orig Wed Dec 30 13:19:03 2009 --- testlibpq2.c Thu Dec 31 00:52:52 2009 *************** *** 24,34 **** --- 24,39 ---- * * INSERT INTO TBL1 VALUES (10); */ + + #ifdef WIN32 + #include <windows.h> + #endif #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <sys/time.h> + #include <sys/types.h> #include "libpq-fe.h" static void Does this become the standard which you consider? or #IFDEF Isn't it allowed? Regards, Hiroshi Saito ----- Original Message ----- From: "Andrew Dunstan" <andrew@dunslane.net> To: "Tom Lane" <tgl@sss.pgh.pa.us> Cc: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>; "Alvaro Herrera" <alvherre@commandprompt.com>; "pgsql-hackers" <pgsql-hackers@postgresql.org>; "Bruce Momjian" <bruce@momjian.us> Sent: Thursday, December 31, 2009 12:45 AM Subject: Re: [HACKERS] test/example does not support win32. > > > Tom Lane wrote: >> "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes: >> >>> Yes, I thinks that it is an exact idea. However, this example was not helped. fd_set >>> complains.... Thanks! >>> >> >> >>> It seems that pg_bench takes the thing same again into consideration. Anyway, If it is >>> called example of end-user code, what is the evasion method >>> of fd_set? >> >> On reflection I think it's just wrong to expect that the examples will >> compile out-of-the-box on every platform. The only way that that can >> possibly happen is if they depend on our configuration infrastructure, >> which is exactly what I feel they should not depend on. Any client >> program that has ambitions of portability is going to have its own >> autoconf stuff, so injecting ours into a piece of sample code is just >> going to result in headaches. Even including only pg_config.h would >> be a serious invasion of application namespace. >> >> Looking at pgbench, or any other one of our client-side programs, >> is not relevant to the point here. Those programs *are* supposed >> to rely on the PG autoconf environment. >> >> We can certainly add some more standard #includes to the examples >> if they're obviously missing some. But that isn't going to get us >> to a point where they'll compile everywhere without change. >> >> >> > > That would be all good and well if we didn't already rely on the configure setup. But we > do - the Makefile includes src/Makefile.global, which is built by configure. > > Anyway, let's see how far we can get with including some standard header files. > > cheers > > andrew
Hiroshi Saito wrote: > Hi Andrew-san. > > Although this is a standard in windows. > > *** testlibpq2.c.orig Wed Dec 30 13:19:03 2009 > --- testlibpq2.c Thu Dec 31 00:52:52 2009 > *************** > *** 24,34 **** > --- 24,39 ---- > * > * INSERT INTO TBL1 VALUES (10); > */ > + > + #ifdef WIN32 > + #include <windows.h> > + #endif > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > #include <errno.h> > #include <sys/time.h> > + #include <sys/types.h> > #include "libpq-fe.h" > > static void > > Does this become the standard which you consider? > or #IFDEF Isn't it allowed? > > I certainly think we can use ifdefs. This addition seems OK to me at first glance. Does it solve the problem you encountered? cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> On reflection I think it's just wrong to expect that the examples will
>> compile out-of-the-box on every platform.
> That would be all good and well if we didn't already rely on the
> configure setup. But we do - the Makefile includes src/Makefile.global,
> which is built by configure.
That makefile is not part of the examples. It wouldn't get copied and
pasted into someone's source code.
> Anyway, let's see how far we can get with including some standard header
> files.
Sure, no objection to that. It's when somebody starts wanting to use
HAVE_FOO symbols that I get unhappy.
regards, tom lane
Hi Andrew-san. This saves a windows users. I appreciate your suggestion. Thanks! P.S) I often use by the test by nmake at the time of independent creation of libpq. Regards, Hiroshi Saito ----- Original Message ----- From: "Andrew Dunstan" <andrew@dunslane.net> > > > Hiroshi Saito wrote: >> Hi Andrew-san. >> >> Although this is a standard in windows. >> >> *** testlibpq2.c.orig Wed Dec 30 13:19:03 2009 >> --- testlibpq2.c Thu Dec 31 00:52:52 2009 >> *************** >> *** 24,34 **** >> --- 24,39 ---- >> * >> * INSERT INTO TBL1 VALUES (10); >> */ >> + >> + #ifdef WIN32 >> + #include <windows.h> >> + #endif >> #include <stdio.h> >> #include <stdlib.h> >> #include <string.h> >> #include <errno.h> >> #include <sys/time.h> >> + #include <sys/types.h> >> #include "libpq-fe.h" >> >> static void >> >> Does this become the standard which you consider? >> or #IFDEF Isn't it allowed? >> >> > I certainly think we can use ifdefs. This addition seems OK to me at > first glance. Does it solve the problem you encountered? > > cheers > > andrew
Attachment
2009/12/30 Hiroshi Saito <z-saito@guitar.ocn.ne.jp>: > Hi Andrew-san. > > This saves a windows users. > I appreciate your suggestion. > Thanks! This one looks much better. +1 for this version :-) -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes:
> [ examples_win32_patch2 ]
Is the addition of -DFRONTEND actually needed, and if so why?
We shouldn't be depending on that in any user-exposed code, I would
think. Otherwise I don't have any objection to this version.
regards, tom lane
Hi Tom-san. Ahh.. It was correction of the test of often... again, the pursued relation was seen, I think that it is good now. Thanks!! Regards, Hiroshi Saito ----- Original Message ----- From: "Tom Lane" <tgl@sss.pgh.pa.us> > "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> writes: >> [ examples_win32_patch2 ] > > Is the addition of -DFRONTEND actually needed, and if so why? > We shouldn't be depending on that in any user-exposed code, I would > think. Otherwise I don't have any objection to this version. > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers