| Newsgroups |
gmane.comp.openoffice.devel.tools |
| Message-ID |
<[email protected]> |
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]
>