Bug 65567

Summary: [PATCH] Build fix for alternate DB3/4 installations
Product: [Applications] kdevelop Reporter: Melvyn Sopacua <melvyn>
Component: generalAssignee: KDevelop Developers <kdevelop-devel>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: 3.0.0a7   
Target Milestone: ---   
Platform: Compiled Sources   
OS: FreeBSD   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Berkeley DB compatibility

Description Melvyn Sopacua 2003-10-05 22:08:00 UTC
Version:           3.0 alpha7 (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc version 2.95.4 20020320 [FreeBSD] 
OS:          FreeBSD

Background:
on FreeBSD one can have several installations of Berkeley DB libraries. In the base system, there's the ancient 1.85 version. Other versions installed by the portscollection have their library and header location renamed to avoid conflicts.

The patch attached shortly fixes build problems on FreeBSD. To build correctly the appropreate values for db-dir and db-name need to be given. Ports maintainers will easily be able to pick this up.

As a quick-fix I've added the inclusion of config.h on lib/catalog/gcatalog.h because several files seem to include it, before config.h is included leaving an undefined type for DB.

As a side note it fixes the install target on Bourne type shells.
Comment 1 Melvyn Sopacua 2003-10-05 22:09:38 UTC
Created attachment 2693 [details]
Berkeley DB compatibility
Comment 2 groot 2004-01-01 17:48:12 UTC
Patch looks ok, and I believe there's even one more version of db available now as a port. Unfortunately I'm not in a position to test or experiment. Melvyn, you may want to send a message to kde@freebsd, to see if there's someone there with a kdevelop that can be experimented with.
Comment 3 Harald Fernengel 2004-01-02 16:25:19 UTC
The patch looks good, but why did you put the check into configure.in.in instead of kdevelop.m4.in with the rest of the checks? I'd rather have the ugly parts in kdevelop.m4.in so that configure.in.in is readable.

Harry
Comment 4 Will Andrews 2004-01-04 07:21:58 UTC
I'm sure it doesn't make any difference as long as the same result is achieved.  So if you want to do it that way, I don't think the reporter would have any objections.
Comment 5 Melvyn Sopacua 2004-01-06 20:32:09 UTC
Subject: Re:  [PATCH] Build fix for alternate DB3/4 installations

On Sunday 04 January 2004 07:22, you wrote:

> ------- Additional Comments From will@csociety.org  2004-01-04 07:21
> ------- I'm sure it doesn't make any difference as long as the same result
> is achieved.  So if you want to do it that way, I don't think the reporter
> would have any objections.

IIRC I tried first in kdevelop.m4 but that didn't work. I haven't chased the 
cause, but it had something to do with the availablity of certain macro's.

If you can get it working, of course I have no objections.
Comment 6 Amilcar do Carmo Lucas 2004-07-19 23:31:38 UTC
This is fixed in HEAD