Thread: 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)