Обсуждение: Re: Sorry 'bout that mild outburst, and here's another change.
Thomas G. Lockhart wrote: > > OK, from here on we will be making tweaks to the cvs tree based on your > files. I've modified src/configure.in to do the configuration of > interfaces/odbc using that configure pass, rather than the "independent > package" configure that we were trying earlier. If compiling standalone, > then the local interfaces/odbc/configure is used instead. Huh? Are you saying that you added commands other than AC_CONFIG_SUBDIRS to the Postgres distribution configure.in such that it "builds" the odbc makefiles itself rather than having the odbc driver's configure script do it? Or am I misinterpreting what you've said? > > I haven't retried the standalone package, and will be happy to look at > it soon. The "make standalone" might work a bit better if it takes the > template directory from ../../template rather than from ./template > (using -C on tar to untar things locally), but that is a detail that I > won't bother with right now. Again, huh? I'm sure its only a minor detail but pray explain some more. I use -C ../../template to get the template files from the Postgres top-level directory. Than all someone has to do with the tarball is tar -xzf tarfile.tar.gz in some empty directory and they have the complete source ready to just ./configure. What am I missing? > > At some point we should think about yanking the platform-specific stuff > out of the GNUmakefile.in and using the templates for that instead. But > let's stop polishing for right now and get something committed and on > the air. I agree, I'm kinda tired of looking at configure scripts. Besides I have a real job. I suppose if we get enough ports to other systems eventually we can do that but I think it can wait. Bet you thought you could trick me again and have me just jump right on it huh? :-) > > So, thanks. I'll look at it once more and then commit to the cvs tree > and send a tarball (zipball?) to Byron. Haven't heard from Byron in a few days, what's up Byron you fall asleep? I suspect he'ld appreciate a zipball more than a tarball. > > btw, I've got at least 3 Unix/linux beta testers lined up (mostly from > the ApplixWare support list), and will send them the tarball also. At > least one of them is very capable (I've seen him on the lists for quite > a while) and he should provide some good feedback. Sounds good. BTW. I CC'd this back to the mailing list. -- Gerald Gryschuk gerald.gryschuk@home.com MidNightOil Consulting - "We burn the midnight oil so you don't have to."
> Huh? Are you saying that you added commands other than
> AC_CONFIG_SUBDIRS to the Postgres distribution configure.in such that
> it "builds" the odbc makefiles itself rather than having the odbc
> driver's configure script do it?
Yes, exactly. It's pretty neat, really, in that either configure routine
will handle the build for that package. And for the integrated Postgres
tree we can count on others being careful with that main build script,
where a configure hidden down in interfaces/odbc won't get as much
attention.
> > The "make standalone" might work a bit better if it takes the
> > template directory from ../../template rather than from ./template
> > (using -C on tar to untar things locally),
> I'm sure its only a minor detail but pray explain some more.
> I use -C ../../template to get the template files from the Postgres
> top-level directory. Than all someone has to do with the tarball is
> tar -xzf tarfile.tar.gz in some empty directory and they have the
> complete source ready to just ./configure. What am I missing?
You're missing nothing. I didn't see the "-C" in the tar command line
(wasn't looking before the -f for that kind of option). It looks great.
> > At some point we should think about yanking the platform-specific
> > stuff out of the GNUmakefile.in and using the templates for that
> > instead. But let's stop polishing for right now and get something
> > committed and on the air.
> I agree, I'm kinda tired of looking at configure scripts. Besides I
> have a real job. I suppose if we get enough ports to other systems
> eventually we can do that but I think it can wait. Bet you thought
> you could trick me again and have me just jump right on it huh? :-)
No need for you to do anything, it's *almost* where it needs to be. I
have a problem getting HAVE_PWD_H set from the main configure script in
the odbc/config.h which I'm looking at now. I'll fix that, and then send
the tarball to the beta testers and to Byron, and let things settle down
a bit. We'll probably have some minor tweaks for the final v6.4 release
(hopefully getting some Solaris support, for example) but I think this
is a solid package. The only other thing we might need to address is
some patches to get Byron's VC support files updated.
Talk to you soon.
- Tom
Doh! did it again. Thomas G. Lockhart wrote: > Yes, exactly. It's pretty neat, really, in that either configure routine > will handle the build for that package. And for the integrated Postgres > tree we can count on others being careful with that main build script, > where a configure hidden down in interfaces/odbc won't get as much > attention. I don't want to sound harsh but you do realize this significantly reduces the flexibility we have to update just the odbc driver? With AC_CONFIG_SUBDIRS, its the package itself that gets to decide how it should be built. Just as an example, lets say I have to add code in socket.cxx for Solaris, a significant possibility, and maybe I need a HAVE_SOLARIS in the config.h to turn that part of the code on. With AC_CONFIG_SUBDIRS I just update the odbc driver's configure.in and config.h.in files and it will configure without any changes to the Postgres configure file. But if I'm interpreting what your saying correctly than I would also have to change the Postgres distribution's configure.in, an eventuality that I don't relish. Given that the odbc driver has many more ports, and therefore changes, to be made before it catches up with the distribution I suspect there may still be a few changes necessary in the configure files. It would be nice if this could be updated independently of the distribution itself. -- Gerald Gryschuk(ggryschuk@scf.sk.ca) Programmer Analyst Saskatoon Cancer Centre ((306)655-2746)
(topic: standalone configuration of psqlodbc vs Postgres tree config)
> I don't want to sound harsh but you do realize this significantly
> reduces the flexibility we have to update just the odbc driver?
No, it's good to make sure we are covering all the points. Yes, I
realize all (?) of the implications here. I don't see this as reducing
flexibility; imho it gives us more of it, since we can have the
standalone distribution evolve, then snapshot it into the Postgres tree
when desired. For example, the Postgres tree didn't have v6.30.0250,
even though it has been available for a while. Of course, I've got an
obligation to make the "integrated distribution" work correctly, and to
make sure it doesn't stomp on the "standalone distribution" which to be
clear consist of the same set of source code as the integrated one.
I'm also trying to look out for overall Postgres issues:
1) there are no other "independent configures" in the tree (yet).
2) Postgres has no experience (yet) with long-term support for ODBC
under Unix.
3) there is an upcoming v6.4 release, needing a workable integration
now.
4) you have indicated that you are reaching your time limits on this,
and we didn't yet have a tree which completely works. I've also dumped
some time into this, and I'm running out of it too (I'm pushing 20-30
hours of work per week on Postgres at the moment :). We're all motivated
to get this stuff working, and it's time to have a firm starting point.
5) we get configure support "for free" in the main distribution. The
standalone configure is on your/our shoulders entirely. So if we have
support for ODBC in the main configure, then our standalone support can
just tag along, with us occasionally needing to push something up into
the main configure, maybe.
6) I've fixed one or two problems in the main configure at the same
time, so Postgres overall will benefit from this exercise.
7) things can be adjusted once we have a solid starting point. When we
have that, then things can evolve. For example, our main configure gurus
may have opinions on standalone vs integrated, and will be happy to have
the "independent configure". We now have something they can play with.
> Given that the odbc driver has many more ports, and therefore changes,
> to be made before it catches up with the distribution I suspect there
> may still be a few changes necessary in the configure files. It would
> be nice if this could be updated independently of the distribution
> itself.
It can. The standalone configure should still work. I'm working out some
final details in the src/configure & odbc/configure integration, but it
looks like it is coming together nicely. Wait a few hours for me to
commit another round of configure/makefile changes into the cvs tree
before looking closely at it; it doesn't quite work with the large blob
of changes I committed last night.
Do you have access to the cvs tree, or should I send you a tarball? btw,
we'll need to start exchanging patch files rather than these full
tarballs now that we have the Postgres tree for a reference.
Talk to you soon...
- Tom
Thomas G. Lockhart wrote: > I'm also trying to look out for overall Postgres issues: Well, o.k. far be it from me to argue, I'm new at this, and come to think of it your right. The scenario I was having a problem with only breaks down if someone adds a new odbc source release to their Postgres distribution and than tries to configure from the top-level Postgres ./configure. Unless they want to watch the rest of Postgres reconfigure itself this scenario is probably unlikely, more likely they'll just run configure from the odbc driver directory. Of course we should make this clear in the docs probably. > Do you have access to the cvs tree, or should I send you a tarball? btw, > we'll need to start exchanging patch files rather than these full > tarballs now that we have the Postgres tree for a reference. Unfortunately no I don't. I'm behind a firewall, don't know if that means anything but I haven't had time to even try to connect to a cvs tree to test it. So tarballs and patch files it is. -- Gerald Gryschuk(ggryschuk@scf.sk.ca) Programmer Analyst Saskatoon Cancer Centre ((306)655-2746)