33568 - Checking out a new source tree with client.mk is not working anymore

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[Axel Hecht]

When one tries to use client.mk to pull a new tree, there are quite a 
few errors.
It should work, as it still mentionend in
http://www.mozilla.org/build/unix-details.html
First I had to set CVSROOT, but that's ok with me, it could be stated in the
page though.
Then I get some serious errors:
picard{ah} make -f client.mk 
cvs checkout: in directory mozilla:
cvs checkout: cannot open CVS/Entries for reading: No such file or directory
cvs [checkout aborted]: cannot open CVS/Entries.Static: No such file or
directory
/bin/sh: mozilla/build/autoconf/mozconfig2client-mk: not found
client.mk:119: /tmp/test/mozilla/.mozconfig.mk: No such file or directory
make: *** No rule to make target `/tmp/test/mozilla/.mozconfig.mk'.  Stop.

So this makes sense. I guess, the mozconfig scripts should be used. So three
solutions come up to me, create a bootstrap cvs module, that checks out
all needed scripts, or check out the needed scripts in client.mk, or just 
remove that option from the webpage.

Axel

Comment 1

[Pascal Hofstee]

I am not getting ANY errors at all .. but simply 3 lines showing that it's
checkout the 3 cvs-sections NSPR, Security, and SeaMonkeyAll
it just doesn't seem to actually fetch anything.

all the files Axel's "build" seems to be complaining about are all present after
i have issued gmake -f client.mk
that includes all the mozilla/build/autoconf scripts

Leaving out the "if test -f $$failed; then false; else true; fi;" part of the
"cvs_co" definition in the real_checkout target of client.mk

makes the cvs checkouts working again.

Comment 2

[Pascal Hofstee]

Attachment: Patch to fix cvs checkout bustage of client.mk

Comment 3

[Axel Hecht]

picard{ah} make -f client.mk
checkout start: Tue Mar 28 17:46:18 MET DST 2000
I retried with the patch, and there are two things:
Firstly, I busted because I just copied client.mk, as opposed to checking one 
out. This gives a running system on solaris, but not on FreeBSD as daeron 
reported.
Applying the patch by daeron, I get the following errors:

cvs -q -z 3 co -P mozilla/client.mk
M mozilla/client.mk
make[1]: Entering directory `/tmp/test'
cvs -q -z 3 co -P -r NSPRPUB_CLIENT_BRANCH mozilla/nsprpub
/bin/sh: cvs  -q -z 3 co -P -r NSPRPUB_CLIENT_BRANCH mozilla/nsprpub: not found
make[1]: *** [real_checkout] Error 1
make[1]: Leaving directory `/tmp/test'
make: *** [checkout] Error 2

Changing platform to FreeBSD

Axel

Comment 4

[cls]

Wrt checkout errors, make sure that you are using CVS version 1.10 or greater. 

Comment 5

[Pascal Hofstee]

101 shadowmere ~ % cvs --version

Concurrent Versions System (CVS) 1.10.7 (client/server)

and without my suggested patch ... i am simply seeing these checkout errors

Comment 6

[cls]

client.mk is slamm's baby.  Slamm, what was the purpose of the eval?

Comment 7

[Pascal Hofstee]

It's been quite a while now and this bug stuill is not resolved ... can we
please get answer here .... the current source still contains the extra eval
which just simply breaks on FreeBSD ...

Comment 8

[Gervase Markham [:gerv]]

Confirming - [e-mail], this will raise the profile 
of this bug for you. Does this prevent you building on FreeBSD?

Gerv

Comment 9

[Pascal Hofstee]

Well ... after Manually removing the superfluous "eval" it will build just fine
...

Comment 10

[Axel Hecht]

Hey,
I thought about this for another second, the error I get looks like 'eval' would
check my (own) path, and without 'eval' just my system path is looked up.
Steve, did I get this right?
I did not find any docs on eval in the make.info, does this depend on your 
shell? How about $(shell ), would that work?

Axel

Comment 11

[markush]

This looks like bug 35211 (dupe?).

Comment 12

[Steve Lamm]

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

Comment 13

[Steve Lamm]

Rats. I am not sure how I missed this bug for so long. Anyway, I checked in the
patch.

Comment 14

[Steve Lamm]

Ok, now I remember why I added the eval. Without it, you cannot pull by date. I
checked in the patch, but tinderbox promptly went red. I had to back it out.

Comment 15

[Steve Lamm]

Attachment: Use shell function instead of eval

Comment 16

[Steve Lamm]

Thanks to "Portable Shell Programming" by Bruce Blinn, I have found a better
alternative. I can use a shell function. The tricky part was figuring out that I
needed to use "$@" to quote the shell function arguments. Here is an excerpt
from the book,

$*   is equivalent to $1 $2 ...
$@   is equivalent to $1 $2 ...
"$*" is equivalent to "$1 $2 ..."
"$@" is equivalent to "$1" "$2" ...

The last one is what I needed.

Would someone like to review this patch?

Comment 17

[Steve Lamm]

Hmm, come to think of it, I could still use eval instead of a function. The book
says some platforms may not support shell functions properly. All I really need
to do is get ride of the nested eval statements. The "$$@" can replace the 'eval
"$$*"'

Comment 18

[Steve Lamm]

Scratch that last plan. It did not work. So, I would still like a review of the
second attachment.

Comment 19

[Pascal Hofstee]

Ok ... Looks like the current code that is in CVS solves the fetch-problems on
my FreeBSD-system

Comment 20

[Steve Lamm]

Great. I'll make this fixed then. Axel can verify.