Re: [tools-dev] building moz m117

[Volker Quetschke]

[EMAIL PROTECTED] wrote:

Well, I have to say that this advice worked! Thank you very
much.  As I type this, compiling is still running, well
past where it ended before.

Wait a second! Why is it necessary? It works well for me and
propably also for Pavel, as he is still providing milestone
snapshots.

What I did:  I opened the file in textpad and removed all
blank lines. I noted that some blank lines had tabs in
them. When I saved that file and restarted dmake, it
breezed past that area and is still compiling.

Something is *MEGA*fishy here.

Jack, are you using cygwin textmounts?

If yes, I'm surprised that you got that far.

Many thanks for this advice.

Well, this might solve this problem for you, but I'm still
wondering why only you are having these problems.

Volker

Best regards,
Jack

On Tue, 19 Jul 2005 14:37:52 +0200
 Hans-Joachim Lankenau <[EMAIL PROTECTED]>
wrote:

hi!

right, there were several issues in the past with empty
lines inside rule/target definition. IIRC, sometimes
related to lineend conventions. also new (not yet in the
MWS) versions seem to be able to handle this correct.

this error exactly looks like.

anyway, i would suggest removing the empty lines inside
the targets of "moz/extractfiles.mk".

note that a new checkout of "solenv" won't help at all.

tschau...

ause

Joerg Barfurth wrote:

Hi Jack,

[EMAIL PROTECTED] wrote:

Well, that ought to teach me to comment stuff out. Now,

it

crashes in the very next block of code with this error:

/cygdrive/c/downloads/openOffice/src680_m117/moz
dmake:  extractfiles.mk:  line 240:  Error -- Expecting
macro or rule defn, foun
d neither

Looking at that error and your previous one gives an

idea of the

problem. It probably was caused by cvs (maybe the

version you are using

or some option ?).

The code it's crashing in now is this:

# copy files in COMPONENT_RUNTIMELIST
   +$(foreach,file,$(COMPONENT_RUNTIMELIST) $(COPY)
$(MOZ_BIN_DIR)$/components$/$(DLLPRE)$(file)$(DLLPOST)

\

  $(RUNTIME_DIR)$/components$/$(DLLPRE)$(file)$(DLLPOST)
&&)

\
   echo >& $(NULLDEV)

The contents of this is irrelevant. This code is

supposed to be part of

a rule definition (the

$(MISC)$/build$/so_moz_runtime_files one).

Apparently dmake does not reckognize that this piece of

code (and

earlier the @echo in the non-Solaris case) is still part

of that rule,

due to the blank-looking lines that separate the blocks.

IIRC these lines must not be empty, but should contain a

'tab' character

at the beginning that signals to dmake that they are

still part of the

rule. Either cvs or an oversmart text editor apparently

has stripped

this tab in the line before '# copy files in

RES_FILELIST' (possibly in

more).

Now, I have to wonder if it's not unzipping the files

in

the /moz/zipped directory.

In short, something is not right, and commenting out

the

effects of testing for solaris didn't fix anything.

More research. Maybe this new "bug" will trigger some

more

ideas.

Maybe a fresh checkout of solenv is the most promising

idea to fix this.

HTH, Joerg

---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
If you like my work consider:  http://www.scytek.de/donations.html
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D

signature.asc
Description: OpenPGP digital signature