Issue 80547 - Assignments to empty macro names
Summary: Assignments to empty macro names
Status: CLOSED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: solenv (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: hjs
QA Contact: issues@tools
URL:
Keywords:
Depends on:
Blocks: 69510
  Show dependency tree
 
Reported: 2007-08-09 20:37 UTC by quetschke
Modified: 2013-08-07 15:34 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
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.