Thread: test/example does not support win32.

test/example does not support win32.

From
"Hiroshi Saito"
Date:
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

Re: test/example does not support win32.

From
Tom Lane
Date:
"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


Re: test/example does not support win32.

From
"Hiroshi Saito"
Date:
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


Re: test/example does not support win32.

From
Alvaro Herrera
Date:
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


Re: test/example does not support win32.

From
"Hiroshi Saito"
Date:
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


Re: test/example does not support win32.

From
Tom Lane
Date:
"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


Re: test/example does not support win32.

From
Bruce Momjian
Date:
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. +


Re: test/example does not support win32.

From
Tom Lane
Date:
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


Re: test/example does not support win32.

From
Andrew Dunstan
Date:

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


Re: test/example does not support win32.

From
"Hiroshi Saito"
Date:
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 



Re: test/example does not support win32.

From
Andrew Dunstan
Date:

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


Re: test/example does not support win32.

From
Tom Lane
Date:
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


Re: test/example does not support win32.

From
"Hiroshi Saito"
Date:
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

Re: test/example does not support win32.

From
Magnus Hagander
Date:
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/


Re: test/example does not support win32.

From
Tom Lane
Date:
"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


Re: test/example does not support win32.

From
"Hiroshi Saito"
Date:
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
Attachment