593727 - directory/xpcom/datasource/nsLDAPDataSource.manifest is missing

Status: RESOLVED DUPLICATE of bug 577887

(MailNews Core :: LDAP Integration, defect)

Description

[JF Mertens]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/533.17.8 (KHTML, like Gecko) Version/5.0.1 Safari/533.17.8
Build Identifier: seamonkey-2.1a3

build aborts with


make[4]: Leaving directory `/sw64/bld/seamonkey-2.0.6.9-1/comm-central/directory/xpcom/base'
make[4]: Entering directory `/sw64/bld/seamonkey-2.0.6.9-1/comm-central/directory/xpcom/datasource'
make[4]: *** No rule to make target `nsLDAPDataSource.manifest', needed by `libs'.  Stop.
make[4]: Leaving directory `/sw64/bld/seamonkey-2.0.99-1/commcentral/directory/xpcom/datasource'
make[3]: *** [libs] Error 2


Reproducible: Always

Steps to Reproduce:
1. build seamonkey--2.1a3 (problem did not happen with any prior version, although they too had no such file) [and --disable-javaxpcom, since that got broken too]
2. When re-trying manually, after the abort, to re-launch make in that dir after having removed that .manifest target from the Makefile (since all previous builds built very happily without it), make fails with

../../../config/rules.mk:1710: *** .js component without matching .manifest.  Stop.

Jean-Francois Mertens
3.
Actual Results:  
build aborts

Expected Results:  
build compltes

Comment 1

[Robert Kaiser]

(In reply to comment #0)
> `/sw64/bld/seamonkey-2.0.6.9-1/comm-central/directory/xpcom/base'

Erm, this doesn't sound like 2.1a3 to me...

> 1. build seamonkey--2.1a3 (problem did not happen with any prior version,
> although they too had no such file) [and --disable-javaxpcom, since that got
> broken too]

javaxpcom does not exist any more, there should be no need to disable it.

Where does the source you are building come from? How do you retrieve it?



Mark, do you have any idea on this?

Comment 2

[JF Mertens]

source :
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/releases/2.1a3/source/seamonkey-2.1a3.source.tar.bz2

MD5: 42ea74033403d408b116d849f65b2797

and javaxpcom still does exist too: if building a usually with --enable-javaxpcom
I get into the bug at https://bugzilla.mozilla.org/show_bug.cgi?id=577426

JF

Comment 3

[Mark Banner (:standard8)]

(In reply to comment #1)
> Mark, do you have any idea on this?

--enable-ldap-experimental is exactly what it says - experimental. This obviously hasn't been updated recently.

JF: Do you actually require the experimental ldap for something? Why are you enabling it?

Comment 4

[Justin Wood (:Callek)]

Justin@DELLXPS400-1 ~/Sources/Mozilla/comm-central
$ hg status
? directory\xpcom\datasource\nsLDAPDataSource.manifest

So I do have this in my tree for a while, but since this is _experimental_ I never bothered to try and get it reviewed/checked in.

I don't even build [or try to build] ldap experimental and it has been suggested we just kill it, I am interested in the answer on if there is a need to use it.

Comment 5

[JF Mertens]

I wrote this as de facto maintainer of fink's seamonkey pkg _ so I have no idea whatsoever what
features end-users actually use.
By tradition , since mozilla times, this has been a gnome build, fully enabled.
And I like the users not to have surprises from one build to the next _ i.e., to keep as much as
possible the same set of "enable", "disable", "with" , etc..

As to the "experimental" aspect _ I would have thought that when something has been there for so many years ( ~6 ? more ?), and without trouble, it is no more experimental _ even the configure-parameter keeps that name for historical reasons...

Jean-Francois

PS: is it so difficult to make a manifest file? No script in the build-dir that would do it ?

Comment 6

[JF Mertens]

... even if the configure-parameter ..

Comment 7

[Mark Banner (:standard8)]

(In reply to comment #5)
> As to the "experimental" aspect _ I would have thought that when something has
> been there for so many years ( ~6 ? more ?), and without trouble, it is no more
> experimental _ even the configure-parameter keeps that name for historical
> reasons...

An experimental option that hasn't been enabled by default, is not enabled in the vast majority of configurations, does not mean that it actually works or provides any benefit even though no-one has reported any trouble.

My suspicion is that it can be removed, but I'm going to check with someone later.

Comment 8

[Justin Wood (:Callek)]

resolving as a dupe, lets use that bug if we determine we want/need this too.