34159 - building dbm separately

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Fred Roeber]

I have patches which will allow dbm to be built separately (as NSS will need)
and as part of the entire mozilla build.

I have a context diff, and a tar file of additional files (basically,
build+config stuff for dbm).  I have tested these diffs+files on unix and NT. 
To do a full mozilla build with these changes, nothing special or different
needs to be done.  To build just dbm on unix, merely check out mozilla/dbm, and
./configure as usual.  To build just dbm on NT, check out mozilla/dbm, set
INCS=-I<NSPR dist> and go nmake /f makefile.win .

Comment 1

[Fred Roeber]

Attachment: proposed changes (NOTE: multidirectory diff; patch may barf)

Comment 2

[Fred Roeber]

Attachment: tar.gz of new files

Comment 3

[Fred Roeber]

The diff and tar do NOT include new versions of "configure" itself.  You'll need
to run autoconf in both mozilla/ and mozilla/dbm/ .

Comment 4

[cls]

Leaf, are we going to need to setup another trigger to automatically run
autoconf when dbm/configure.in changes? Or are we going to just require people
to check in their modified configure?

Comment 5

[Daniel (Leaf) Nunes]

do we have an nspr configure.in? I can pretty easily add this to the list of
configure files that get autogenerated.

Comment 6

[cls]

Yes, we have a nsprpub/configure.in as well.  It's only used by
--enable-nspr-autoconf of course.

I almost hate to ask this but in the drive to make certain modules compile
"independently" from Mozilla, are we going to end up duplicating rules.mk and
friends across each module?

Comment 7

[Daniel (Leaf) Nunes]

I don't think duplication is strictly necessary... isn't the config system now
fairly general? Can't one be used for all? That's the idea i've always had in my
head... otherwise, everyone who wants to make a new module thingee needs to come
up with their own build system.

Comment 8

[cls]

Right, that's the issue.  Should every standalone module include it's own set of
rules needed to build that module (ala NSPR & js)?  If so, should these modules
use their own build rules or Mozilla's global ruleset when they build inside
mozilla?  Currently, NSPR does it's own thing.  js has js/config that needs to
be pulled to build standalone.  

I was also thinking that the standalone modules could still use the standard
mozilla config files to build.  Each standalone module would have to pull
mozilla/build & mozilla/config along with the modules' source & dependencies. 
We'd still have to make a mozilla/dbm/configure but it would set it's topsrcdir
to mozilla/ .  So even when building standalone, it would still be using the
same basic config as the rest of Mozilla.

Comment 9

[Daniel (Leaf) Nunes]

That seems like less maintenance. I'm sure there will be modules that want their
own config, though. I don't see why a module can't decide which way to go.

Comment 10

[cls]

Ok, so getting back to dbm specifics.... is it really necessary for dbm to have
it's own build heirarchy?  For use with NSS, I mean.

Comment 11

[Fred Roeber]

I tried hard to get dbm to use ../config and ../build and just couldn't do it. 
One thing I ran into is a bug in autoconf itself where it doesn't like you
specifying source directories with ".." in them when it's trying to do a
configure in a different directory: it builds relative links by counting
directories and prepending ".." but it counts the specified ".." as a regular
dir and backs over it too, ending up pointing two directories too high.

I'd still like to have a configure/build system that doesn't require those
directories to be duplicated, but it's going to be a bit of work.

Comment 12

[Robert Relyea]

To answer cls's question: Yes. We need to be able to pull and build just the 
components nss needs. Also -- I don't mind if someone wants to go off and find a 
better way to make modules build independently, but right now not being able to 
build dbm is holding up nss development. Other than the 'sanity' issue of having 
a separate config directory, is there any reason we can't get this checked in? I 
need these changes to keep working.

Comment 13

[cls]

Sorry about the delay.  I just checked in a new build option to the toplevel
configure that should allow you to build dbm separately from mozilla.  You need
to pass '--enable-modules=dbm' to configure to only build dbm.  Unfortunately,
it still requires pulling the entire tree but we're working on that.

Comment 14

[Chris Yeh]

mass re-assign of all bugs where i was listed as the qa contact

Comment 15

[cls]

It is now possible to build dbm standalone using the main configure.in (so to
get the same defines, cflags, etc as a normal build).

cvs -z3 co mozilla/client.mk
cd mozilla
gmake -f client.mk pull_all BUILD_MODULES=dbm
./configure --enable-modules=dbm
gmake

Comment 16

[Robert Relyea]

I can't seem to build it on my AIX machine... confgure fails.

It still has dependencies on GTK and IDL. [may only be an update to the build 
instructions... I figured out how to turn X and GTK off, but it doesn't look 
like it's possible to turn off IDL.

bob

Comment 17

[Ian McGreer]

relyea - I was able to turn off IDL by adding "--disable-libIDLtest" to the
configure command.

However, noticed that the same changes (building standalone modules) need to be
made to the windows makefile.

Comment 18

[cls]

Setting milestones to Future.

Comment 19

[John Mark Vandenberg]

I am not sure if this is the right spot ... but when building mozilla, nss is 
looking for a .a , whereas the dbm module is building a .so .

Comment 20

[cls]

This is not the right place and I do not see that behavior in the standard
mozilla builds.  Please open a new bug and include your build options.

Comment 21

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 22

[Asa Dotzler [:asa]]

don't move bugs that are in the 1.0 dependency tree. sorry.

Comment 23

[hacker formerly known as [e-mail]]

Marking fixed as we can use the gmake build system for win32 & mac (OSX) now.