SEO

#1 (**permalink**) 05-05-2008, 05:53 AM

Tom Lane wrote:
>> However, all the values are hardcoded, so nothing in it should relate to
>> settings that come from configure, I believe. These should be dealt with
>> in src/tools/msvc/Solution.pm (mostly in GenerateFiles() ).
>>
>
> FYI, I'm about to commit changes moving XLOG_BLCKSZ and XLOG_SEG_SIZE
> into the domain of configurable stuff, too.
>
>
>

This patch should fix things for both sets of changes. And it
demonstrates pretty much what you need to do for config options for MSVC.

If there's no objection I will apply shortly.

cheers

andrew

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

#2 (**permalink**) 05-05-2008, 05:53 AM

Andrew Dunstan <andrew@dunslane.net> writes:
> ! print O "#define RELSEG_SIZE ",
> ! (1024 / $self->{options}->{blocksize}) *
> ! $self->{options}->{segsize} * 1024, "\n";

This doesn't look quite right; unless the arithmetic is being done in
floating point? I had it like this in configure.in:

RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`

Also it looks like you missed adding segsize to the config.pl comments.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

#3 (**permalink**) 05-05-2008, 05:53 AM

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> This doesn't look quite right; unless the arithmetic is being done in
>> floating point? I had it like this in configure.in:
>>
>> RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`

> blocksize is one of (1,2,4,8,16,32) so it should always be a factor of
> 1024 unless my arithmetic is awry. I did it that way because I dislike
> expressions with unbracketed mixed operations - they make me think too
> much.

Well, if you dislike the original on style grounds, you should change it
to match. Doing the same thing in two different ways in two places
isn't good.

>> Also it looks like you missed adding segsize to the config.pl comments.

> That's deliberate - we are currently only allowing a value of 1 here, so
> I don't see any point in putting it in the sample config file, even as a
> comment. When we enable other seg sizes we can add it to the sample file.

Ah, OK.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

#4 (**permalink**) 05-05-2008, 05:53 AM

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> ! print O "#define RELSEG_SIZE ",
>> ! (1024 / $self->{options}->{blocksize}) *
>> ! $self->{options}->{segsize} * 1024, "\n";
>>
>
> This doesn't look quite right; unless the arithmetic is being done in
> floating point? I had it like this in configure.in:
>
> RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`
>

blocksize is one of (1,2,4,8,16,32) so it should always be a factor of
1024 unless my arithmetic is awry. I did it that way because I dislike
expressions with unbracketed mixed operations - they make me think too
much.

> Also it looks like you missed adding segsize to the config.pl comments.
>
>
>

That's deliberate - we are currently only allowing a value of 1 here, so
I don't see any point in putting it in the sample config file, even as a
comment. When we enable other seg sizes we can add it to the sample file.

cheers

andrew

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

#5 (**permalink**) 05-05-2008, 05:53 AM

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>
>> Tom Lane wrote:
>>
>>> This doesn't look quite right; unless the arithmetic is being done in
>>> floating point? I had it like this in configure.in:
>>>
>>> RELSEG_SIZE=`expr '(' 1024 '*' ${segsize} / ${blocksize} ')' '*' 1024`
>>>
>
>
>> blocksize is one of (1,2,4,8,16,32) so it should always be a factor of
>> 1024 unless my arithmetic is awry. I did it that way because I dislike
>> expressions with unbracketed mixed operations - they make me think too
>> much.
>>
>
> Well, if you dislike the original on style grounds, you should change it
> to match. Doing the same thing in two different ways in two places
> isn't good.
>

OK, done. Patch applied with that addition (it was time I deployed
autoconf 2.61 anyway).

cheers

andrew

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

#6 (**permalink**) 05-05-2008, 05:53 AM

Andrew Dunstan wrote:
> This patch should fix things for both sets of changes. And it
> demonstrates pretty much what you need to do for config options for MSVC.

Btw., it is quite easily possible to use the autom4te tracing facility to
parse the configure.ac file, in case you are interested in generating some of
the Windows build code automatically.

For example:

$ autoconf -t 'AC_ARG_ENABLE:$1' configure.in
integer-datetimes
nls
shared
rpath
spinlocks
debug
profiling
dtrace
segmented-files
depend
cassert
thread-safety
thread-safety
thread-safety-force
largefile

Let me know if you want to do something with that.

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

#7 (**permalink**) 05-05-2008, 05:53 AM

Peter Eisentraut wrote:
> Andrew Dunstan wrote:
>
>> This patch should fix things for both sets of changes. And it
>> demonstrates pretty much what you need to do for config options for MSVC.
>>
>
> Btw., it is quite easily possible to use the autom4te tracing facility to
> parse the configure.ac file, in case you are interested in generating some of
> the Windows build code automatically.
>
> For example:
>
> $ autoconf -t 'AC_ARG_ENABLE:$1' configure.in
> integer-datetimes
> nls
> shared
> rpath
> spinlocks
> debug
> profiling
> dtrace
> segmented-files
> depend
> cassert
> thread-safety
> thread-safety
> thread-safety-force
> largefile
>
> Let me know if you want to do something with that.
>
>

Yeah, maybe. Let's fix the issue pg_config.h.win32 that Tom raised first.

cheers

andrew

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

#8 (**permalink**) 05-05-2008, 05:53 AM

Andrew Dunstan <andrew@dunslane.net> writes:
> Peter Eisentraut wrote:
>> Btw., it is quite easily possible to use the autom4te tracing facility to
>> parse the configure.ac file, in case you are interested in generating some of
>> the Windows build code automatically.

> Yeah, maybe. Let's fix the issue pg_config.h.win32 that Tom raised first.

+1 for both. We really need to eliminate as much redundancy as we can
between the two build systems, because it'll keep biting us until we do.

regards, tom lane

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

#9 (**permalink**) 05-05-2008, 05:53 AM

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Peter Eisentraut wrote:
>>> Btw., it is quite easily possible to use the autom4te tracing facility to
>>> parse the configure.ac file, in case you are interested in generating some of
>>> the Windows build code automatically.
>
>> Yeah, maybe. Let's fix the issue pg_config.h.win32 that Tom raised first.
>
> +1 for both. We really need to eliminate as much redundancy as we can
> between the two build systems, because it'll keep biting us until we do.

+1 from here as well, if that wasn' obvious :-)

(will get back to the actual issues at hand when I get back in a more
connected mode in a couple of days, unless they are already solved by then)

//Magnus

--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

SEO

Re: [COMMITTERS] pgsql: Sigh ...