On Feb 23, 2009, at 7:21 AM, Jim Graf wrote:
> I compile and install some 3rd
> party lib where ever I think it ought to be and then create a .pc
> file for
> that build/install.
Actually, pkg-config support is on the Wishlist already. It's quite
possible to generate this file at the end of the ./configure process,
containing the proper directories, and install it automatically.
Supporting it would indeed ease the 32/64-bit problem.
Thanks for posting your pkg-config files. I may use those as a base
for adding this to MySQL++....unless you submit it as a patch first. ;)
> A long winded way of my saying I don't think mysql++ should attempt to
> figure out if it is going to be compiled 32 or 64 bit or where to
> install
> itself.
I think I'm with you on the general policy ideas and their value, but
keep in mind that the core problem we're dealing with here is people
who build the library without options and then expect it to just
work. These users aren't telling us their policy, they're just
accepting Autoconf's default policy, which does the wrong thing in
some situations.
It will be important to keep this distinction in mind. I have no wish
to override users like you, Jim, who have a strong opinion on where
things go.
The motivation to try and fix this isn't any different from the
reasoning behind making autoconf search in likely locations for the C
API files if we don't get --with-mysql* flags.
We can't solve everything, of course. If MySQL++ did somehow figure
out that it should go in lib64 on a particular Linux, it'll be /usr/
local/lib64 by default, not /usr/lib64, which isn't in the default
ld.so.conf, in my experience. But, at least the files go into the
"correct" location in this instance.
Another trap: how do we tell that we're building a 32-bit library on a
64-bit aware system?
> Keep the third party
> lib simple and push the build/install complexity to the user.
The whole point of using third-party wrapper libraries like MySQL++ is
that they abstract away details you don't really want to cope with.
If the user doesn't specify install locations, they're effectively
saying that path names are another thing they don't want to cope
with. That brings the issue into MySQL++'s scope.
