configure deps not set correctly since LDAP move to hg

RESOLVED FIXED in Thunderbird 3.3a2

Status

defect
--
critical
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: tonymec, Assigned: Callek)

Tracking

Trunk
Thunderbird 3.3a2
x86
Linux
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Posted file log of failed build
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
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
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.
Assignee: nobody → bugspam.Callek
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Now that LDAP is on Mercurial, I can't build SeaMonkey anymore → configure deps not set correctly since LDAP move to hg
Posted patch fixSplinter Review
this should do it.
Attachment #494556 - Flags: review?(kairo)
Comment on attachment 494556 [details] [diff] [review]
fix

D'Oh!
Attachment #494556 - Flags: review?(kairo) → review+
http://hg.mozilla.org/comm-central/rev/3c698d5b775d
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
(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
Status: RESOLVED → REOPENED
Flags: in-testsuite-
Resolution: FIXED → ---
(In reply to comment #9)

Arf, reopened by "Mid-air collision" :-|
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a2
You need to log in before you can comment on or make changes to this bug.