Thread: Re: [COMMITTERS] pgsql: Enable probes to work with Mac OS X Leopard and other OSes that

Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane wrote:
> >> Peter Eisentraut <peter_e@gmx.net> writes:
> >>> I think if they can run Gen_fmgrtab, they can get this to work.
> >>
> >> They can't.
> >
> > They can't run Gen_fmgrtab or they can't get this to work?
>
> They can't run Gen_fmgrtab.  The MSVC port has its own reimplementation
> of that script, and I suppose now it's going to need one to substitute
> for this, too.

Well, yes.  I meant to say, a build system that can supply the functionality 
of Gen_fmgrtab can surely implement this new thing.  I see there is Perl 
being used, so it should be simple.

Peter Eisentraut wrote:
> Well, yes.  I meant to say, a build system that can supply the functionality 
> of Gen_fmgrtab can surely implement this new thing.  I see there is Perl 
> being used, so it should be simple.
>   
I was thinking of using a Perl script to generate the dummy header file 
but decided against it to avoid disrupting the build on other platforms. 
If sed doesn't work on Windows for some reason, we can use a Perl script 
instead.

Regards,
-Robert

Robert Lor wrote:
> Peter Eisentraut wrote:
>> Well, yes.  I meant to say, a build system that can supply the 
>> functionality of Gen_fmgrtab can surely implement this new thing.  I 
>> see there is Perl being used, so it should be simple.
>>   
> I was thinking of using a Perl script to generate the dummy header 
> file but decided against it to avoid disrupting the build on other 
> platforms. If sed doesn't work on Windows for some reason, we can use 
> a Perl script instead.
>
>

Perl is required for all MSVC builds, and for all builds from CVS on any 
platform too, IIRC, so it's a fairly safe bet for any tool you provide.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Robert Lor wrote:
>> I was thinking of using a Perl script to generate the dummy header 
>> file but decided against it to avoid disrupting the build on other 
>> platforms. If sed doesn't work on Windows for some reason, we can use 
>> a Perl script instead.

> Perl is required for all MSVC builds, and for all builds from CVS on any 
> platform too, IIRC, so it's a fairly safe bet for any tool you provide.

The key phrase in that is "from CVS".  Changing the sed script to Perl
would introduce an unacceptable new dependency for builds from tarballs.

However, there's nothing wrong with using Perl in the MSVC case,
since those scripts need it anyway.
        regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 18 Mar 2008 18:14:32 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> > Perl is required for all MSVC builds, and for all builds from CVS
> > on any platform too, IIRC, so it's a fairly safe bet for any tool
> > you provide.
> 
> The key phrase in that is "from CVS".  Changing the sed script to Perl
> would introduce an unacceptable new dependency for builds from
> tarballs.

At some point, do we recognize that Perl is installed on every
reasonable platform in existence or can be easily? I mean, we already
require autoconf/make etc... What is adding Perl in practice?

Sincerely,

Joshua D. Drake


- -- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate     PostgreSQL political pundit | Mocker of
Dolphins

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH4ECDATb/zqfZUUQRApTmAJ9+N+vEuBnydMB1ozkg7FMZgBeA9ACgq6fz
WJXzPkgvqrSkkzV9vnoMYiM=
=n7BS
-----END PGP SIGNATURE-----

Joshua D. Drake wrote:
> At some point, do we recognize that Perl is installed on every
> reasonable platform in existence or can be easily? I mean, we already
> require autoconf/make etc... What is adding Perl in practice?

For one thing, a moving target.  If we rely on "standard" Unix tools, we have 
something fairly stable, if you are careful to read the documentation to omit 
the occasional GNU extension.  But with Perl, you'd have a constant worry, 
which Perl versions to support and which features that Perl version provides.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 19 Mar 2008 00:07:09 +0100
Peter Eisentraut <peter_e@gmx.net> wrote:

> Joshua D. Drake wrote:
> > At some point, do we recognize that Perl is installed on every
> > reasonable platform in existence or can be easily? I mean, we
> > already require autoconf/make etc... What is adding Perl in
> > practice?
> 
> For one thing, a moving target.  If we rely on "standard" Unix tools,
> we have something fairly stable, if you are careful to read the
> documentation to omit the occasional GNU extension.  But with Perl,
> you'd have a constant worry, which Perl versions to support and which
> features that Perl version provides.
> 

That is certainly reasonable and I have to admit, I don't follow Perl
releases as much as I probably should but I can't remember the last
time something I would do in "standard" perl wouldn't work for every
version of perl since 5.6. I guess there is a consideration with the
imminent, supposedly in our lifetime release of 6. 

Fair enough.

Sincerely,

Joshua D. Drake


- -- 
The PostgreSQL Company since 1997: http://www.commandprompt.com/ 
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate     PostgreSQL political pundit | Mocker of
Dolphins

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFH4EwQATb/zqfZUUQRAueHAJ9+YH28v862MP1nBSk16XH5rMQKmQCgnWm1
UimwrFV0siRHC5JGp0o/xic=
=WKN3
-----END PGP SIGNATURE-----

Peter Eisentraut <peter_e@gmx.net> writes:
> Joshua D. Drake wrote:
>> What is adding Perl in practice?

> For one thing, a moving target.

Well, if we were that afraid of Perl version discrepancies, we shouldn't
be using it at all anywhere.  My point was just that we should not add
a new build tool dependency without a darn good reason; and something
you can easily do in sed doesn't qualify as a darn good reason.
        regards, tom lane

Robert Lor wrote:
> Peter Eisentraut wrote:
>> Well, yes.  I meant to say, a build system that can supply the 
>> functionality of Gen_fmgrtab can surely implement this new thing.  I 
>> see there is Perl being used, so it should be simple.
>>   
> I was thinking of using a Perl script to generate the dummy header 
> file but decided against it to avoid disrupting the build on other 
> platforms. If sed doesn't work on Windows for some reason, we can use 
> a Perl script instead.
>
>

What we should do in fact is to use psed on Windows to execute the 
script. This is a sed emulator that is part of the standard perl 
install, and will save us the bother of having to maintain two 
generation scripts, or switching from sed to perl. We just need to find 
where to plug that into the Windows build process.

cheers

andrew

Andrew Dunstan wrote:
> 
> 
> Robert Lor wrote:
>> Peter Eisentraut wrote:
>>> Well, yes.  I meant to say, a build system that can supply the 
>>> functionality of Gen_fmgrtab can surely implement this new thing.  I 
>>> see there is Perl being used, so it should be simple.
>>>   
>> I was thinking of using a Perl script to generate the dummy header 
>> file but decided against it to avoid disrupting the build on other 
>> platforms. If sed doesn't work on Windows for some reason, we can use 
>> a Perl script instead.
>>
>>
> 
> What we should do in fact is to use psed on Windows to execute the 
> script. This is a sed emulator that is part of the standard perl 
> install, and will save us the bother of having to maintain two 
> generation scripts, or switching from sed to perl. We just need to find 
> where to plug that into the Windows build process.

Hadn't heard about that one. Sounds like a good way to do it, if you can 
find the correct place for it :-)

//Magnus

Magnus Hagander wrote:
> Andrew Dunstan wrote:
>>
>>
>> Robert Lor wrote:
>>> Peter Eisentraut wrote:
>>>> Well, yes.  I meant to say, a build system that can supply the 
>>>> functionality of Gen_fmgrtab can surely implement this new thing.  
>>>> I see there is Perl being used, so it should be simple.
>>>>   
>>> I was thinking of using a Perl script to generate the dummy header 
>>> file but decided against it to avoid disrupting the build on other 
>>> platforms. If sed doesn't work on Windows for some reason, we can 
>>> use a Perl script instead.
>>>
>>>
>>
>> What we should do in fact is to use psed on Windows to execute the 
>> script. This is a sed emulator that is part of the standard perl 
>> install, and will save us the bother of having to maintain two 
>> generation scripts, or switching from sed to perl. We just need to 
>> find where to plug that into the Windows build process.
>
> Hadn't heard about that one. Sounds like a good way to do it, if you 
> can find the correct place for it :-)


I'm thinking of the patch below.  I'll try it out tomorrow.

cheers

andrew

Index: Solution.pm
===================================================================
RCS file: /cvsroot/pgsql/src/tools/msvc/Solution.pm,v
retrieving revision 1.36
diff -c -r1.36 Solution.pm
*** Solution.pm 28 Feb 2008 12:17:59 -0000      1.36
--- Solution.pm 20 Mar 2008 00:02:05 -0000
***************
*** 205,210 ****
--- 205,216 ----         close(T);     }
+     if 
(IsNewer('src\include\utils\probes.h','src\backend\utils\probes.d'))
+     {
+               print "Generating probes.h...\n";
+               system('psed -f src\backend\utils\Gen_dummy_probes.sed 
src\backend\utils\probes.d > src\include\utils\probes.h');
+       }
+     if 
(IsNewer('src\interfaces\libpq\libpq.rc','src\interfaces\libpq\libpq.rc.in'))     {         print "Generating
libpq.rc...\n";