Trying to build SeaMonkey, I get a message saying that <objdir>/ldap/sdks/c-sdk/config/autoconf.mk is missing, and the "make build" phase aborts. Retrying doesn't help (I got this yesterday and I'm still getting it today). I'll attach the build log. My mozconfig is as follows, it used to work when LDAP was on CVS: # Configuration file for SeaMonkey # # let make "guess" an objdir name mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@ # # We're building the Suite, but with Lightning built-in mk_add_options MOZ_CO_PROJECT=suite ac_add_options --enable-application=suite ac_add_options --enable-calendar # # maximum number of simultaneous parallel makes # commented out (AFAICT parallel make is slower than linear) # mk_add_options MOZ_MAKE_FLAGS=-j2 # # build with debugging symbols export MOZ_DEBUG_SYMBOLS=1 export CFLAGS="-gdwarf-2" export CXXFLAGS="-gdwarf-2" ac_add_options --enable-debug-symbols=-gdwarf-2 ac_add_options --disable-install-strip # debug build ac_add_options --disable-optimize --enable-debug # # enable OOPP ac_add_options --enable-libxul --enable-ipc # # tests ac_add_options --disable-tests --disable-codesighs # # branding ac_add_options --disable-official-branding ac_add_options --with-branding=suite/branding/nightly # # own-built binary, no autoupdates ac_add_options --disable-update-channel # # ac_add_options --enable-chrome-format=jar ac_add_options --enable-chrome-format=flat # ac_add_options --enable-chrome-format=symlink # ac_add_options --enable-chrome-format=omni # # and finally, a modeline for my favourite editor # vim: et I'm using (wrapped by the bash "time" builtin) the following build script; its current directory is set to my clone of comm-central. It also used to work before LDAP switched to Mercurial: #!/bin/bash export AJM_OBJDIR=obj-i686-pc-linux-gnu date && \ echo 'python client.py checkout' && \ python client.py checkout && \ date && \ echo 'make -f client.mk build' && \ make -f client.mk build && \ test -n "$AJM_OBJDIR" -a -d $AJM_OBJDIR && \ date && \ echo "make -C $AJM_OBJDIR package" && \ make -C $AJM_OBJDIR package echo 'Exit status' $?

did you =re= pull via client.py... the first client.py pull would have updated you to the latest comm-central code (which expects the new location) though missed the fact that we need to clone ldap from the new place. which sounds like it may be your issue. Failing that please try a clobber. if either of those fixes this RESO/WFM please.

(In reply to comment #1) > did you =re= pull via client.py... Between yesterday and today, I ran the script in comment #0 (which starts with client.py) a total of three times. The first time it "cloned" the ldap-sdks Mercurial repository and "added 6 changesets with 934 changes to 895 files (+1 heads)" with the result that 889 files were "updated", then (still in the first build run) it "updated" the repo to the tag LDAPCSDK_6_0_6D_MOZILLA_RTM (removing .hgtags and getting c-sdk/configure and c-sdk/configure.in); the second and third times there were "no changes found" except for mozilla-central; the attached log is from the third time. Related with bug 614978 ? > > the first client.py pull would have updated you to the latest comm-central code > (which expects the new location) though missed the fact that we need to clone > ldap from the new place. which sounds like it may be your issue. > > Failing that please try a clobber. if either of those fixes this RESO/WFM > please. what do you mean by "try a clobber"? Remove the objdir and all its contents, then try rebuilding? Delete the ldap repository on my HD and try again? Or something else?

Oops: four times. The first time (before the three described above) it pulled ldap from CVS and did a configure run in several directories, then missed the Makefile.in for ldap. The "three runs" described above (the first of which cloned the ldap Hg repo) came after that.

After "touching" the mozconfig to force a reconfigure (I think this is one way of "clobbering"), several ldap modules have been recompiled, and ATM the make is busy somewhere in mozilla-central => WFM as per comment #1

Tony, actually I am reopening this. a thought came to me today on why this failed for you, and it is a legitimate bug. I'll have a patch shortly.

this should do it.

Comment on attachment 494556 [details] [diff] [review] fix D'Oh!

(In reply to comment #6) Good catch. We may want to fix the following occurences to, while there and fwiw: http://mxr.mozilla.org/comm-central/search?string=directory%2F&case=1&find=%2Fldap%2Fsdks%2F.*%5C.mk Found 5 matching lines in 3 files

(In reply to comment #9) Arf, reopened by "Mid-air collision" :-|

(In reply to comment #9) > http://mxr.mozilla.org/comm-central/search?string=directory%2F&case=1&find=%2Fldap%2Fsdks%2F.*%5C.mk > Found 5 matching lines in 3 files I filed bug 616065.