[Mysqlcppapi-main] Re: [ mysqlcppapi-Patches-632734 ] mystery patch

[<mu...@t-...>]

On Sun, 2002-11-03 at 22:58, Bryan W. Headley wrote:
> no...@so... wrote:
> 
> > Patches item #632734, was opened at 2002-11-02 22:39
> > You can respond by visiting:
> > https://sourceforge.net/tracker/?func=detail&atid=307869&aid=632734&group_id=7869
> >
> >
> > >Summary: mystery patch
> >
> > ----------------------------------------------------------------------
> >
> 
> If you are going to have a conversation, use email. Don't use the bug 
> tracking system. I'll chat privately, I'll chat publically

It make sense to discuss/develop patches in patch manager, next to the
patch. I find that works well for the gtkmm project.

If you don't want to do that, please at least use the mailing list.

> > 1. This is not a cvs patch - it patches generated files so
> > it's difficult to read.
> >
> I use CVS as a baseline establishing tool only. Doing a diff between my 
> file and the repository, when the file(s) in the repository are 
> changeable is not acceptable.

Other people do not have problems proviging cvs patches. It works well
enough for everbody else on almost every other open-source project.

>  By definition, my window for making a 
> change to a file = the amount of time between my doing a CVS update and 
> someone else submitting a patch to that file for merging.
> 
> Unless you don't mind constantly reintegrating using a non-centralized 
> repository, you use the ability to work effectively. Maybe subversion or 
> arch would help, but we don't use either, and SV isn't ready for heavy 
> use, besides. Arch is ready, but needs a UI.
> 
> BitKeepers' licensing keeps me away from using their stuff.

I don't understand most of that, and I'm not interested anyway. Please
provide cvs patches or expect to wait longer for your patches to be
applied.

> I tried my best to avoid sending diff information on any generated 
> files. I expect you are referring to config.h.in, which I admit is a 
> shade of gray as to whether it's generated or not.

I seem to remember some Makefile, Makefile.in, or configure changes.

> > 2.
> >
> > mysqlcppapi uses .h extensions so far, so lets keep it
> >
> > consistent.
> >
> I don't recall sending you a header without the .h extension. What are 
> you referring to?

I think I was referring to your API.hh file.

> > 3.
> >
> > Please don't give copyright of new files to me, if you have
> >
> > written them, and particularly not if you mispell my name.
> >
> > "The mysqlcppapi team" would be best.
> 
> 
> I regret misspelling your name; I don't know if claiming a copyright to 
> a non-extant legal entity is the right thing to do, even if "they" in 
> turn grant rights under LGPL. I'm aware that the Gtk+ folks did it that 
> way. I just feel that there should be a legally-definable steward of the 
> copyright, who can then confer usage rights.


> 
> In the case of any sort of legal challenge, you see, who is "the 
> mysqlcppapi team"? Nobody you can identify for a subpema/disposition 
> purposes.

Yes, it's legally unclear. Please use "The mysqlcppapi team". If it's
good enough for other high-profile projects then it's good enough for
us.

> Also, I don't see any other header discuss the LGPL, or a COPYRIGHT file 
> with the usage terms spelt out. That should be fixed. I'll let you grant 
> the rights to your code by pasting the preamble...

Yes, I was sure that I made a point about putting that somewhere clearly
when I forked the project, but I don't see anything now.

> >
> > 4.
> >
> > Why change GENERIC_* variable names to MYSQLCPPAPI_* names?
> >
> Ah. Because if I include several packages, each with a _version.h
> file, I want to avoid symbol collision. Best way is to name the 
> variables after the package. Heaven forbid that I ever use your package 
> at the same time as someone else, who thinks GENERIC_MAJOR_VERSION is a 
> good name. Maybe it is, but only if the product is called GENERIC.

I was referring to the autotools files. I don't think there was any
_version.h file before you added it.

> > 5.
> >
> > Your use of variable names for the library name makes
> >
> > assumptions about future library names based on version
> >
> > names. Those decisions have not yet been made. For instance,
> >
> > gtk+2.2.0 has a 2.0 library name.
> >
> As to the second point, you have to wonder why, too. Is it a member of 
> the Gtk+ 2.0 "family" of releases, or is it appropriate for use with 
> Gnome-2? Their naming convention is non-obvious; they could benefit from 
> some documentation, perhaps in configure.in...

People don't need to care about the names of libraries on disk. They
just use pkg-config and tell it what they want.

> As to the first point, you've changed the name of the package to 
> mysqlcppapi-2.

I don't see how that is relevant. You may be confusing "API versions"
and "library names" and "library versions".

>  Go look at your "file download" page if you don't recall 
> that. Personally, I agree with the name change, insofar as the API was 
> changed through the removal of support of slist<T> for Rows.
> 
> Maybe you can add to the API and keep the old package name, but I don't 
> advise that for removing function calls. Plus the change to the newer 
> STL headers is a larger change than it appears to be.

None of which supports your assumptions about future API change, so
these build file changes will not be applied.

> > 6. I see no great need for configure scripts to double-check
> >
> > the results of pkg-config queries. Other libraries don't
> >
> > seem to need to do it. I'd prefer to keep things simple.
> >
> You still are confused on that. It's not a test to see if pkg-config is 
> lying, although it also does that. It's a test that other versions of 
> dependent libraries are not being dynanmically linked at runtime in by 
> mistake. E.g., pkg-config will give the correct insructions to 
> dynamically link against a library in, say, /usr/lib, but if you have 
> LD_LIBRARY_PATH set to /var/openBSD/emu/lib, it will try to dynamically 
> resolve symbols from there first, when the code is run. And _that_ is 
> the test.
> 
> As that particular test saved my bacon the other day, I'm predisposed to 
> including it. Removing it removes critical functionality. 

I'm not convinced. If you provide a patch that includes only that
feature then we can keep it sitting around in case we want to apply it
later.

> Simplification's purpose is to remove useless cruft; this is not that.
> 
> Tried to build Gnome2 with vicious_build_scripts the other day. It 
> builds the whole dist in a separate tree. Build doesn't work.

If often doesn't build due to source code breakage, but in general it
works for a lot of people. If you have a problem with it then I suggest
you talk to the author.

>  Why? 
> Because it uses binaries it just compiled in a bootstrap manner. Where 
> do these binaries look for their sharable libraries? In /usr/lib, etc., 
> everywhere except the separate tree where it's supposed to look. So what 
> happens? I run a configuration script that still had the test program in 
> it... it built, linked, and run. It dynamically binds to a Gnome 1.4 
> library instead of a 2.0 library. And the test script caught the error! 
> LD_LIBRARY_PATH needed to be set; it wasn't.
> 
> I should write bug reports for all those Gnome library packages, and 
> maybe those guys'll convince you they were wrong. But that takes time.

If the GNOME team believed in the need for this then they would provide
the same m4 macros for all of their libraries.

> > Please try to
> >
> > a) Fix problems rather than fix things which are not broken.
> 
> 
> The fact that the package wasn't complete is a problem. But it now has 
> an m4 script that I can include in my other packages. It's now usable.
> 
> I have 3 packages that use mysqlcppapi: if the configuration code's 
> wrong, I don't want to open three separate configure.in files -- I want 
> to fix one .m4 and have them all continue include it. I can't help you 
> wrt the other Gnome packagers: they must enjoy hunting down insideous 
> bugs introduced by copy/paste errors.
> 
> > b) Submit smaller, more focused patches so that they can be
> >
> > more easily approved.
> 
> That requires smaller, more focused bugs, I find. Patches should be 
> atomical: what is sent in all has to work together -- you can't send 2 
> or 3 smaller patches, because the intermediate versions in the 
> repository will not compile.

So you wait for them to be applied before generating a new patch. But in
this case, I don't believe that all of the changes were interdependent.

Note that, at this, point, the patch cannnot be applied. Please generate
a new patch based on my decisions above.

> 7. Things to consider:
> 
> We're creating maintenance issues by hardcoding the library version in 
> mysqlcppapi/Makefile.am
> 
> E.g.,
> 
> 20: > lib_LTLIBRARIES= libmysqlcppapi-1.9.la
> Half of me is remiss to make that "libmysqlcppapi-$(tuplet_version).la", 
> insofar as the code is made slightly less readable. But when you do want 
> to rename the library libmysqlcppapi-2.0.la, I'd like a single variable 
> to change, and have everything fall in-line after an autogen.sh..

Yes. I believe I did this because a previous version of automake or
autoconf didn't allow us to use variable names inside variable names.
But maybe it works now - we just need a _different_ variable for that
part of the name.


-- 
Murray Cumming
mu...@us...
www.murrayc.com