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

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?

you assigned this to the wrong dmose account. he uses dmose@mozilla.org

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?

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

Reassigning to XPCOM SDK / C SDK bug to Leif.

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.

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

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.

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?

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

r=dmose@netscape.com for cls' fix so that that can tide us over until leif gets copies of the nspr files checked in. Thanks Chris!

Giving this bug to dmose.

Marking Mozilla 1.0.

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

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

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