Issue 80547

Summary: Assignments to empty macro names
Product: Build Tools Reporter: quetschke
Component: solenvAssignee: hjs <hans-joachim.lankenau>
Status: CLOSED FIXED QA Contact: issues@tools <issues>
Severity: Trivial    
Priority: P3 CC: issues
Version: current   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 69510    

Description quetschke 2007-08-09 20:37:43 UTC 
Hi ause,

after I "improved" the macro assignment check in issue 69510 dmake 4.11 is now
complaining about assignments to empty macro names that are expanded from
macros themself.

This triggers for example in sal/util/makefile.mk with:

$(PRJPCH)=


What's the master plan here? Is it desired to keep dmake ignoring such
constructions without throwing a warning?
Comment 1 quetschke 2007-09-16 18:23:18 UTC 
Ping? I actually found only one place in the source.

If we remove the single occurrence of

$(PRJPCH)=

in sal/util/makefile.mk we can go back to issue an error in issue 69510.

So was there a plan? ;)
Comment 2 hjs 2007-10-02 10:47:05 UTC 
removed that line in CWS ause085
Comment 3 rt 2007-12-18 12:16:40 UTC 
verified
Comment 4 hjs 2008-03-07 16:54:47 UTC 
.
Comment 5 zougloub 2008-03-27 17:48:17 UTC 
I am having trouble with building openoffice (I tried 2.3.1, 2.4.0), getting
Assignment without macro name errors.

Here are the extracts of build output :

2.4.0 rc5
 -> http://gentoo.zapto.org/p/?ZjJkYT
2.4.0
 -> http://gentoo.zapto.org/p/?OWZlOD

same error with 2.3.1, and I won't test others.

I am using openoffice's included dmake
Comment 6 hjs 2008-03-28 15:01:32 UTC 
the line number of startup.mk mentioned in both logs indicates that someting
goes wrong when importing your environment variables into dmake.
look for suspicious blanks or $.
also your build doesn't look like a vanilla OOo build. so you might be better
off with the gentoo people.