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.
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. Many thanks for this advice. 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]
