122149 - standalone checkout complains about newborn files disappearing

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

The first problem is that BUILD_MODULES=xpconnect pull_all doesn't get
configure, Makefile.in or allmakefiles.sh (which the build very much wants).

But even if I get those by hand, it dies trying to go into LDAP in the export phase:

gmake -C directory/c-sdk/ldap export
gmake[3]: Entering directory `/src/mozilla/xpcom/mozilla/directory/c-sdk/ldap'
gmake[3]: *** No rule to make target `export'.  Stop.

It is to cry.

Comment 1

[hacker formerly known as [e-mail]]

A few weeks ago, I saw the problem with the build pulling, then removing all of
the toplevel mozilla/* files but it seems to have gone away now.  Of course,
I've upgraded to RH7.2 (from 6.2) since then.   What version of the cvs client
are you using?  I thought we fixed the ldap problem once before. I'll have to
check it again.

Comment 2

[hacker formerly known as [e-mail]]

Attachment: Skip certain toplevel targets when building standalone

My bad.  I killed standalone builds when I added some targets to
mozilla/Makefile.in to fix other build problems.

Comment 3

[hacker formerly known as [e-mail]]

*** Bug 122229 has been marked as a duplicate of this bug. ***

Comment 4

[Axel Hecht]

Comment on attachment 66709 [details] [diff] [review]
Skip certain toplevel targets when building standalone

this fixes transformiix standalone, should fix xpconnect just as well

Comment 5

[hacker formerly known as [e-mail]]

I checked in the patch to solve the Makefile build problem.  xpconnect still
dies with the following error:

./../../../../js/src/xpconnect/loader/mozJSComponentLoader.cpp: In member 
   function `JSObject* mozJSComponentLoader::GlobalForLocation(const char*, 
   nsIFile*)':
../../../../../js/src/xpconnect/loader/mozJSComponentLoader.cpp:1166:
`NS_GetURLSpecFromFile'
   undeclared (first use this function)
../../../../../js/src/xpconnect/loader/mozJSComponentLoader.cpp:1166: (Each 
   undeclared identifier is reported only once for each function it appears 
   in.)

I'm not sure what to do about the cvs pull problem.  I wasn't able to reproduce
it on other boxes when I first saw the problem so I thought that it was just me.
 We may need to get Dawn or someone to look at the server when the problem
occurs to see if anything funny is going on.

Shaver, can you paste the error that you are seeing?

Comment 6

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

cvs server: warning: new-born mozilla/allmakefiles.sh has disappeared
cvs server: warning: new-born mozilla/aclocal.m4 has disappeared
cvs server: warning: new-born mozilla/configure has disappeared
cvs server: warning: new-born mozilla/configure.in has disappeared
cvs server: warning: new-born mozilla/Makefile.in has disappeared

Concurrent Versions System (CVS) 1.11.1p1 (client/server)

(That compilation error is what I was looking to fix when I got waylaid by CVS
and our build system.)

Comment 7

[Dawn Endico]

I looked up that error message and found this:
http://mail.gnu.org/pipermail/info-cvs/2001-April/013978.html

I'm not sure it helps us here though. I don't see anything in the
repository that looks terrbly unusual. None of those files are in
the Attic. The closest is mozilla/Attic/Makefile,v, deleted in
1999

Comment 8

[hacker formerly known as [e-mail]]

Over to shaver, to fix the actual xpconnect build problem.  I can't do anything
about the cvs pull problem.  It really sounds like a server issue.

Comment 9

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

If it's a server issue, let's reassign it to someone in server-land.  I already
have a bug on the underlying BUILD_MODULES=xpconnect source bustage.

Comment 10

[hacker formerly known as [e-mail]]

Over to mozilla.org->Server Ops

Comment 11

[Risto Kotalampi]

Mass changing IC's ticket to reflect current situation.

mozilla.org, AOL employees:

If you want IC to look at issues reported in bugzilla, please open a Helpdesk
ticket and ask it to be routed to AOL R1 Server Operations. We currently have no
way to handle comprehensive problem resolution through bugzilla. This is not a
change in the way we are supporting mozilla.org - we are still supporting you on
the level as before. IC's support is based on Helpdesk ticket system - not
bugzilla which only few hard-core people are looking at. 

Also, projects are handled elsewhere - not in bugzilla. If you have projects you
need us to deliver please feel free to contact me directly.

Summa summarum: tickets -> Helpdesk
Project initiations -> [e-mail]

Comment 12

[hacker formerly known as [e-mail]]

Pike & I discovered a workaround for this problem. 

Comment 13

[hacker formerly known as [e-mail]]

Attachment: v1.0

Apparently, the order that the files are pulled in matters.  Individual files
can be pulled after directories but they must be pulled as part of the same
'cvs co' command.  If separate commands are used and the individual files are
pulled after a subdirectory is pulled, then we hit that 'new-born file has
disappeared' message.

Comment 14

[hacker formerly known as [e-mail]]

Patch has been checked in.