Re: Just some unfinished stuff.

Thomas G. Lockhart wrote:
> Anyway, is there any reason why you changed the behavior of configure to
> always prompt for the platform type? I've got patches which restore the
> Postgres configure behavior, which does not stop to prompt if it thinks
> it has a match.

Hmm... Forgive me a second. Are we talking when ./configure is done from
the top level Postgres directory(i.e. an integrated build) or are you
referring to a standalone build? Also I'm not sure what you mean by the
default Postgres behaviour. Remember I'm working from using the 6.3
source distribution. In the version I have Postgres, without any odbc
driver stuff, stops to prompt for my platform. If it doesn't stop in
the 6.4 version I don't think any of my changes should make it stop.

Maybe I should explain what I attempted and you can tell me if it
matches
what you see.

1) The 6.3 Postgres distribution configuration without our odbc stuff
stops to prompt for my platform, at least this is what I observed.
2) A STANDALONE odbc driver configuration stops to prompt for my
platform, this is because I started by copying the 6.3 configuration
files and edited to suit my needs.
3) My first run at integrating the two meant that the configuration
for an INTEGRATED build stopped twice.
4) After finding out that the TEMPLATE variable in the Postgres
configuration gets exported to the environment I made changes to
the odbc driver configuation such that if it was being built in
an integrated configuration that it's ./configure script would
NOT stop since it was able to get the TEMPLATE variable from the
environment.
5) After the changes in 4) a standalone build of the odbc driver
should still behave the same, i.e. it should stop and prompt for the
platform type.

If your saying that my observation in 1) is "wrong" than I don't
know what's up with that. If the original Postgres distribution,
without our integrated odbc source, isn't supposed to stop than
I don't think that any of my suggested changes to the Postgres
configure.in would have made it stop. On the other hand, your
working with the 6.4 configuation scripts, so... if the
6.4 configuration script doesn't stop AND it DOESN"T export
the TEMPLATE variable(condition 4 above) to the environment, than
attempting to build an integrated source with the odbc driver
WILL make it stop since the odbc configure script won't know
what the "current" value of TEMPLATE is. This would suggest to
me that there are "significant" changes to the 6.4 configure
script which I didn't have. Thus if you have fixes that can
easily be made to the odbc driver configure.in than by all
means make them.

NOTE: When I started this I always found it weird that the
6.3 configure script would stop and prompt. I had never seen
this before given that configure has access to exactly which
platform your running on through the AC_CONFIG_HOST(?) macro.
I was trying to make changes to avoid this behaviour but
I'm not good enough at this configure stuff yet to have
done it.

Sorry for the long winded explanation to what I'm sure seemed
like a straight forward question.

> Byron, apparently you and Gerald have already settled the WINDOWS vs.
> WIN32 problem? Do I have access to the latest source code? I hate asking
> you to do the ./configure integration if you don't have a way to test it
> (I'm not sure what your platform mix is, but assume that it has at least
> one windows machine :).

Don't worry I don't have Byron's changes either. Recall that I asked
Byron to check into this when I sent out my first configure attempt.
He reponsed(quite quickly I might add) that he had to change my
use of WINDOWS to WIN32 but that was it. I wasn't all that worried
figuring I'ld just pick up the new source in the next release but
I guess you should probably get it earlier than that.

>
> Gerald, do we have some ideas on who will take on the
> configure.in/template maintenance as we integrate more platforms (hint,
> hint)? I've got so many commitments to various pieces of Postgres
> already that I'd really like to avoid becoming the bottleneck for this
> support...

I have limited access to some SUN equipment for testing builds,
but I don't really like using it for this kind of thing since the
sys admin where the equipement is, is essentially doing me a favor
by keeping my (very) old account active. We have a Digital Alpha
dual boot system at work that I set up, so I can also do test builds
there under OSF/1 time permitted. Sooo.. I can't promise that I'll
put as much hard time in as I did on the configure and the original
port which both cut into my real job. But I'll stand as the Unix
"maintainer" if you like.

> Speaking of docs, Byron, do you have a preference for how we will do
> nice docs for the distribution? I've got some sgml source code for
> Unix-side issues, but have not integrated any other information. Could
> you summarize what docs resources currently exist, and which ones you
> would like to see in the future?

Oh goody. Real docs. I was hoping someone else would do them. Can I
assume that if your writing "nice docs" that I don't have to write
that new Readme I mentioned?

>
> A nice chapter on the odbc stuff in the main Postgres docs could also be
> built as a standalone document, which would give you both hardcopy and
> html for your distribution...

Just as a matter of completeness if your putting "maintainers" e-mail
addresses in the docs you might want to put in both of mine, at
work it's ggryschuk(at)scf(dot)sk(dot)ca and at home it's gerald(dot)gryschuk(at)home(dot)com(dot)
Some day I'll set up my Linux accounts so my e-mail gets automatically
forwarded depending on the time of day but it doesn't seem quite that
important right now.

>
> btw, it might be nice to keep the discussion on the interfaces mailing
> list so others can offer help and keep up to date with progress.

Done, I've CC'ed this response to the mailing list.

--
Gerald Gryschuk
gerald(dot)gryschuk(at)home(dot)com
MidNightOil Consulting - "We burn the midnight oil so you don't have
to."