Re: 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

"Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)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(at)sss(dot)pgh(dot)pa(dot)us>

> "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)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(at)postgresql(dot)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(at)commandprompt(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

"Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)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(at)guitar(dot)ocn(dot)ne(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce(at)momjian(dot)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(at)guitar(dot)ocn(dot)ne(dot)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(at)dunslane(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>; "Alvaro Herrera"
<alvherre(at)commandprompt(dot)com>; "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>; "Bruce
Momjian" <bruce(at)momjian(dot)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(at)guitar(dot)ocn(dot)ne(dot)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(at)dunslane(dot)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(at)dunslane(dot)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

2009/12/30 Hiroshi Saito <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>:
> Hi Andrew-san.
>
> This saves a windows users.
> I appreciate your suggestion.
> Thanks!

This one looks much better. +1 for this version :-)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

"Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)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(at)sss(dot)pgh(dot)pa(dot)us>

> "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers