62920 - --enable-nspr-autoconf busted by LDAP C SDK buildsystem

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[David Krause]

I've been seeing this for several days now with the latest mozilla cvs source.
Whenever I do a gmake -f client.mk distclean it fails with the following.  Does
the ldap code not play nice with object directories?

gmake[2]: Leaving directory `/usr/local/src/mozilla/mozilla/obj-opt/mailnews'
gmake[2]: Entering directory
`/usr/local/src/mozilla/mozilla/obj-opt/directory/c-sdk/ldap'
build/autoconf.mk:55: ../../../nsprpub/config/autoconf.mk: No such file or directory
/usr/local/src/mozilla/mozilla/directory/c-sdk/ldap/../../../nsprpub/config/config.mk:121:
../../../config/module.df: No such file or directory
/usr/local/src/mozilla/mozilla/directory/c-sdk/ldap/../../../nsprpub/config/config.mk:123:
../../../config/arch.mk: No such file or directory
/usr/local/src/mozilla/mozilla/directory/c-sdk/ldap/../../../nsprpub/config/config.mk:147:
../../../config/.mk: No such file or directory
gmake[2]: *** No rule to make target `../../../config/.mk'.  Stop.
gmake[2]: Leaving directory
`/usr/local/src/mozilla/mozilla/obj-opt/directory/c-sdk/ldap'
gmake[1]: *** [distclean] Error 2
gmake[1]: Leaving directory `/usr/local/src/mozilla/mozilla/obj-opt'
gmake: *** [distclean] Error 2

Comment 1

[cls]

dmose, playing well with objtrees is a universal build requirement.  Can you fix
this or do we need to switch it over to using autoconf?

Comment 2

[Dawn Endico]

you assigned this to the wrong dmose account. he uses [e-mail]

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

The code is already autoconfified, and generally supports objtrees (I build in
one), so this is just a bug, I think.

David, are you using --enable-nspr-autoconf with your toplevel configure?

Comment 4

[David Krause]

dmose, I get the error when using --enable-nspr-autoconf in my .mozconfig.  If I
don't use that option then it works fine.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Reassigning to XPCOM SDK / C SDK bug to Leif.

Comment 6

[cls]

Ok. I hit this as well.  The problem is that ldap relies upon nspr's config
system and on a distclean nspr's autoconf.mk is removed before we hit this
point.  ldap should *not* depend upon another module's build system.

Comment 7

[André Dahlqvist]

I see this even without using --enable-nspr-autoconf in my .mozconfig file. Is
there an easy workaround?

Comment 8

[cls]

Workaround: build in a separate objdir and remove the entire objdir instead of
bothering with a distclean.

NSPR autoconf is the default now so people will always hit this if they do a
distclean.

Comment 9

[cls]

Attachment: One more hack for the non-existant ldap build system

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

The real fix for this happpens when we move to the LDAP C SDK 5.0 (probably post
0.9.1).  However, as a temporary hack, we could extend the idea behind cls'
patch even further, and simply check in a copy of nspr/{build,config} locally
into directory/c-sdk/ldap/build on the LDAPCSDK_40_BRANCH and make at least the
autoconf build system point to that.  That would also fix the fact that building
with a system copy of NSPR is currently broken.  Thoughts?

Comment 11

[cls]

Attachment: Updated distclean hack that works in both srcdir & objdir and actually removes the generated files

Comment 12

[Leif Hedstrom]

Well, if the consensus is to "copy" those NSPR files into the C-SDK (v4.0) build
directory, I can look into that.

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

r=[e-mail] for cls' fix so that that can tide us over until leif gets
copies of the nspr files checked in.  Thanks Chris!

Comment 14

[Jussi-Pekka Mantere]

Giving this bug to dmose.

Comment 15

[Jussi-Pekka Mantere]

Marking Mozilla 1.0.

Comment 16

[Dan Mosedale (:dmosedale, :dmose)]

This should actually be fixed as part of the move to a newer version of the LDAP
C SDK.

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

I suspect this is fixed, now that we've switched to the 5.0 C SDK.  Can anyone
confirm?

Comment 18

[hacker formerly known as [e-mail]]

Yes, |make -f client.mk distclean| has worked for awhile now.