Thread: Unintegrated stuff in source tree
There seems to have been an accumulation lately of stuff that was simply dumped into the source tree without any sort of integration. I am particularly talking about interfaces/ssl and interfaces/libpqxx. No doubt both of these things are useful in the end, but as they are right now they're a headache waiting to happen. Could someone try to address the following issues? SSL: * A bunch of cryptic configuration files -- what do they do? * Weird shell scripts -- what do they do? * The shell scripts are written in a completely unportable fashion and have inappropriate names (surely PostgreSQL isn't the only application in the world that allows to "mkcert"). * They don't even belong into interfaces. * No build instructions, let alone a makefile. Libpqxx: * I'm no C++ whizz, but I guarantee that this coding style is not nearly as portable as we've tried to make libpq++ be. Who wants to answer those support calls all over again? * What's the deal with libpq++ vs. libpqxx? Who's going to want to explain that to the crowd for the next 5 years? * Bogus Automake stuff -- hurts my eyes. ;-) * Doxygen -- is that going to be a quasi-required tool now? * Bonus points for documentation in DocBook format -- but unfortunately version 4.1, and unfortunately not integrated with the rest of the documentation set. * No build integration. * Why are half the text files executable? Personally, I'm uneasy about carrying around another interface library that appears to have no basis in any sort of standard. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > There seems to have been an accumulation lately of stuff that was simply > dumped into the source tree without any sort of integration. I am > particularly talking about interfaces/ssl and interfaces/libpqxx. No > doubt both of these things are useful in the end, but as they are right > now they're a headache waiting to happen. > > Could someone try to address the following issues? > > SSL: > > * A bunch of cryptic configuration files -- what do they do? > > * Weird shell scripts -- what do they do? > > * The shell scripts are written in a completely unportable fashion and > have inappropriate names (surely PostgreSQL isn't the only application in > the world that allows to "mkcert"). > > * They don't even belong into interfaces. > > * No build instructions, let alone a makefile. I have requested info from the ssl author with no replies. Yank it from CVS or I will do the honors. > Libpqxx: > > * I'm no C++ whizz, but I guarantee that this coding style is not nearly > as portable as we've tried to make libpq++ be. Who wants to answer those > support calls all over again? > > * What's the deal with libpq++ vs. libpqxx? Who's going to want to > explain that to the crowd for the next 5 years? > > * Bogus Automake stuff -- hurts my eyes. ;-) > > * Doxygen -- is that going to be a quasi-required tool now? > > * Bonus points for documentation in DocBook format -- but unfortunately > version 4.1, and unfortunately not integrated with the rest of the > documentation set. > > * No build integration. > > * Why are half the text files executable? > > Personally, I'm uneasy about carrying around another interface library > that appears to have no basis in any sort of standard. The idea was that someone with more knowledge of PostgreSQL would integrate the new C++ interface into our build system. If it doesn't happen, we will yank it before 7.3. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> > There seems to have been an accumulation lately of stuff that was simply > > dumped into the source tree without any sort of integration. I am > > particularly talking about interfaces/ssl and interfaces/libpqxx. No > > doubt both of these things are useful in the end, but as they are right > > now they're a headache waiting to happen. > I have requested info from the ssl author with no replies. Yank it from > CVS or I will do the honors. Let's not yank the SSL stuff just yet. It's all good stuff. Let's give him time to reply before 7.3. Chris
On Tue, Jul 09, 2002 at 11:06:10PM -0400, Bruce Momjian wrote: > Peter Eisentraut wrote: > > Personally, I'm uneasy about carrying around another interface library > > that appears to have no basis in any sort of standard. Erm, upon which standards are the other language interfaces based? > The idea was that someone with more knowledge of PostgreSQL would > integrate the new C++ interface into our build system. If it doesn't > happen, we will yank it before 7.3. Has the author been given CVS access yet? Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway wrote: > On Tue, Jul 09, 2002 at 11:06:10PM -0400, Bruce Momjian wrote: > > Peter Eisentraut wrote: > > > Personally, I'm uneasy about carrying around another interface library > > > that appears to have no basis in any sort of standard. > > Erm, upon which standards are the other language interfaces based? > > > The idea was that someone with more knowledge of PostgreSQL would > > integrate the new C++ interface into our build system. If it doesn't > > happen, we will yank it before 7.3. > > Has the author been given CVS access yet? Yes, he has. I got him in touch with Marc. I was just pointing out that while he knows C++, he needs help getting the connecting stuff merged to our coding style. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Christopher Kings-Lynne wrote: > > > There seems to have been an accumulation lately of stuff that was simply > > > dumped into the source tree without any sort of integration. I am > > > particularly talking about interfaces/ssl and interfaces/libpqxx. No > > > doubt both of these things are useful in the end, but as they are right > > > now they're a headache waiting to happen. > > > I have requested info from the ssl author with no replies. Yank it from > > CVS or I will do the honors. > > Let's not yank the SSL stuff just yet. It's all good stuff. Let's give him > time to reply before 7.3. OK, not knowing SSL, I can't judge it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Wed, Jul 10, 2002 at 12:18:16AM +0200, Peter Eisentraut wrote: > There seems to have been an accumulation lately of stuff that was simply > dumped into the source tree without any sort of integration. I am > particularly talking about interfaces/ssl and interfaces/libpqxx. No > doubt both of these things are useful in the end, but as they are right > now they're a headache waiting to happen. Well, I guess as the author I should comment on the libpqxx side of things here. We decided to drop it into the source tree as-is because (1) it's fairly hard to come by the autoconf/automake expertise required to make it work from the main source tree's configure script, and (2) not all systems or C++ compilers support enough of the Standard to make it work, so it ought to remain a separate, optional thing in the beginning. > Libpqxx: > > * I'm no C++ whizz, but I guarantee that this coding style is not nearly > as portable as we've tried to make libpq++ be. Who wants to answer those > support calls all over again? Please explain. I'm sure this is not all portable, but what does coding style have to do with that? Sure, Microsoft compilers have a problem with it, but that's just because they don't support the basic concepts of the language. We've tried to fix that, but it's very hard to work around a bad compiler. If your compiler doesn't handle C++, don't try to compile C++ with it. I'd try to run it through more critical compilers, but according to existing compliance tests, gcc 2.95 through 3.1 happpen to be the best compilers around. As far as I know, libpqxx relies on only two things: first, the C++ standard, and second, libpq. If your system doesn't support those, why bother addressing PostgreSQL from C++ in the first place? > * What's the deal with libpq++ vs. libpqxx? Who's going to want to > explain that to the crowd for the next 5 years? Frankly, libpq++ was severely broken. That's a simple story to tell the crowd in 5 years' time. As it turned out, there was no way to fix it except by writing a completely new library. Use libpq++ if you must; libpqxx if you have the choice. If your compiler only supports C++ as "A Better C" then libpqxx is not for you. If there is some other problem with the code--and I can't say I've heard of any such case in a while--then it ought to be fixed. > * Bogus Automake stuff -- hurts my eyes. ;-) Please elaborate. Like the docs say, the automake stuff was contributed by external dcvelopers, and I merely tried to edit it. If you could just say *what* is so bogus about it, perhaps it could be fixed. Just saying that it's bogus and that it hurts your eyes isn't going to help anyone. The library has its own automake setup so that it can be installed separately on systems that support it. Hopefully someone will see fit to integrate it into the existing setup at some point. This is not proprietary software, after all. > * Doxygen -- is that going to be a quasi-required tool now? It comes with docs generated by doxygen. I don't think that means that doxygen is "quasi-required" any more than emacs is, just because some of the text may have been written with it. If reading HTML is a problem for you, you have other problems. Sure, re-generate the docs with doxygen if you like; you're going to end up with essentially the same stuff that's bundled with the library. If you think that's a useful exercise, you're better off with doxygen. If you don't, there's nothing wrong with the way things are. > * Bonus points for documentation in DocBook format -- but unfortunately > version 4.1, and unfortunately not integrated with the rest of the > documentation set. > > * No build integration. These are on the to-do list, and some are beyond my control so I can't really address them. But if you have time to complain about them, perhaps you can help fix them as well. That would be most welcome; I've essentially been flying blind when writing the docs, mimicking what was already there. > * Why are half the text files executable? Interesting. Haven't been able to find a single file with this problem in the libpqxx distribution archive, so they may have been mangled somewhere else. Where did you find the archive with this problem? > Personally, I'm uneasy about carrying around another interface library > that appears to have no basis in any sort of standard. This suggests that either you haven't actually looked at it, or you're unfamiliar with C++. The thing about libpqxx is that it makes database access adhere to standard C++ interfaces. So saying that it has "no basis in any sort of standard" is just plain wrong. In fact, some C++ programmers have found this tremendously useful, and some have chosen PostgreSQL over competing databases because of this library. Now if you want to maintain that it doesn't adhere to an existing, set standard for C++ database access you may have a point--because there currently are none (unless you count "industry standards" like the pitiful crap MFC users are forced to put up with). But someday there will be, and rest assured that they will look very much like the way libpqxx does things, because it sticks very closely to existing STL standards. So far, all C++ experts I've presented this to (including some involved in the C++ standards process, albeit loosely) have been very supportive of libpqxx because of this existing lack of standards, and the way libpqxx tries to fit things in. In my opinion, libpqxx is a good replacement for libpq++. It does more to conform to standards, it fixes some serious problems with the original design, and it makes it easy to write solid programs using PostgreSQL. In the future it will probably be extended to cover other databases as well, but for now it's a competitive advantage. Finally, it fills a void in the C++ world in a way that may someday define new standards. I don't think this would be hard to explain to new or existing programmers. Jeroen
On Tue, Jul 09, 2002 at 11:20:47PM -0400, Bruce Momjian wrote: > > > > Has the author been given CVS access yet? > > Yes, he has. I got him in touch with Marc. I was just pointing out > that while he knows C++, he needs help getting the connecting stuff > merged to our coding style. Haven't had a reply from Marc yet, so I guess I don't have CVS access yet. Anyway, my main problem at this time is know how to begin to integrate the automake/autoconf stuff into the main source tree. Can't say I know a whole lot about these tools or how PostgreSQL uses them, so as you say I'll need some help making this work in harmony with the PostgreSQL stuff. Any takers? Jeroen
On Wed, 10 Jul 2002, jtv wrote: > On Tue, Jul 09, 2002 at 11:20:47PM -0400, Bruce Momjian wrote: > > > > > > Has the author been given CVS access yet? > > > > Yes, he has. I got him in touch with Marc. I was just pointing out > > that while he knows C++, he needs help getting the connecting stuff > > merged to our coding style. > > Haven't had a reply from Marc yet, so I guess I don't have CVS access > yet. Anyway, my main problem at this time is know how to begin to > integrate the automake/autoconf stuff into the main source tree. Can't > say I know a whole lot about these tools or how PostgreSQL uses them, > so as you say I'll need some help making this work in harmony with the > PostgreSQL stuff. > > Any takers? Damn, thanks for teh reminder ... spent today working on the mailing list lag, and totally forgot about it ... will get that all setup tomorrow, sorry :(