Apache OpenOffice (AOO) Bugzilla – Issue 30212
dmake doesn't recognize the begin of a new target when it doesn't start in first column
Last modified: 2013-08-07 15:35:14 UTC
I just found a strange dmake bug. I'm not sure if I found a special case, but to reproduce on WNT just insert some garbage into solenv/inc/startup/wnt/recipes.mk . This file should be read by .INCLUDE .NOINFER .IGNORE: $(INCFILENAME:d)$(OS)$/recipes.mk in line 234 of solenv/inc/startup/startup.mk. Try it, it is not. But when you remove the three spaces in front of .INCLUDE you will get your error. As expected.
I dug a bit deeper, and found a short testcase. It is not a problem with .INCLUDE only, but with all target definitions. Use the following as startup.mk: ---- startup.mk --------------- # This is the root DMAKE startup file. .NOTABS !:= yes # Rules for making *$O %$O : %.c ; $(CC) $(CFLAGS) -c $< .INCLUDE .NOINFER : recipes.mkk ---- startup.mk --------------- If .NOTABS is set dmake doesn't recognize the .INCLUDE line as a new target, but neither doesn't error on it as invalid recipe. ... Thinking about it, it propably just "thinks" it is a recipe for the target before. Instead of the .INCLUDE statement, you can also put some invalid chars there, as long as there is a space before you wont get an error. You can either remove the .NOTABS!:= yes, the space or add a macro definition before the <spaces>target definition to let dmake recognize it correctly.
have you ever noticed these lines at the end of "target.mk"? > ># workaround for strange dmake bug: ># if the previous block was a rule or a target, "\#" isn't recognized ># as an escaped "#". if it was an assignment, escaping works... >some_unique_variable_name:=1 > maybe this is related... my feeling is that ".NOTABS = yes" is no good idea. but removing it may affect each and every makefile.
No, we should absolutley keep .NOTABS = yes, but the problem sounds fixable. I haven't checked with the dmake manpage, but what we need is that a target definition (the the recipe lines) ends when a blank line is encountered. (I guess) at the moment a target definition is ended only by the detection of a new target/macro definition. But before such a patch is applied we should check *all* makefiles very carefully for target definitions that start with one or more whitespaces. I.e. grep for all occurences of lines beginning with \s+ following an empty line in all .+\..*mk files. :)
Argh! dmake exactly follows it's documentation. RECIPES The traditional format used by most versions of Make defines the recipe lines as arbitrary strings that may contain macro expansions. They follow a rule definition line and may be spaced apart by comment or blank lines. The list of recipe lines defining the recipe is terminated by a new target definition, a macro definition, or end-of- file. Each recipe line MUST begin with a <TAB> character which may optionally be followed with one or all of the ... With this in mind .NOTABS = yes really wasn't a good idea :( And when you look at the: ># if the previous block was a rule or a target, "\#" isn't recognized ># as an escaped "#". if it was an assignment, escaping works... comment, I think this is because of a line recognized as a recipe instead of a rule/target: ................... All comment text is discarded, a '#' may be placed into the makefile text by escaping it with '\' (ie. \# translates to # when it is parsed). An excep- tion to this occurs when a # is seen inside a recipe line that begins with a <tab> or is inside a group recipe. If
comments from hjs Tue Jun 15 07:56:31 > my feeling is that ".NOTABS = yes" is no good idea. but removing it may > affect each and every makefile. comments from vq Tue Jun 15 10:16:11 > No, we should absolutley keep .NOTABS = yes, but the problem sounds fixable. I changed my mind ;) We should switch to the "default" ".NOTABS = no" setting. It would be desirable to fix this becuse the use of spaces might hide rules and targets as mistaken recipe lines. The following perlscript checks for possible recipe lines that start with a space. The situation is not that bad ( I excluded the unused makefiles in dmake. ): Usage: $ find . -iregex '.*mk' -print | grep -v '/dmake/' | xargs -i ../findspaces.pl {} > mk_check.txt Number of makefiles: $ grep "Processing file:" mk_check.txt | wc -l 2200 Number of makefiles recipe lines that have to be checked: $ grep "Found in file: " mk_check.txt | wc -l 181 And lines to be checked/changed: $ grep "line " mk_check.txt | wc -l 1246 That is a boring task, but I would do that ;) A question remains, should this be done in the next comunity cws, or would an own cws for this task be sensible? I move the target to solenv, because this touches makefiles in general. P.S. The ".NOTABS = no" setting would make sure that these spaces don't come back.
Created attachment 16025 [details] Perl script to find illegal recipe lines
- a dedicated CWS for this might be a fine testcase for the OOo cws tooling ;-). but it's also no problem fo me to host a CWS for you if you send me a list of affected modules. - does dmake complain with ".NOTABS = no" when encountering blanks? and how?
Hi! > - a dedicated CWS for this might be a fine testcase for the OOo cws tooling ;-). If you need a "Versuchskaninchen" for this, I can do that. I already spotted some occurences of $^O = MSWin and think a test run would be usefull, before relesing it to the "public". But we should start with one module in a test or obsolete branch. ;) >- does dmake complain with ".NOTABS = no" when encountering blanks? and how? When not encountering a TAB it must be a macro/rule/target and is evaluated as such. If after the change a recipe line starts with a space one will most propably get an error because of the invalid syntax. > but it's also no problem fo me to host a CWS for you if you send me a list > of affected modules. The list follows, it's quite long, but I'd like to wait until ooo20040620 is integrated in HEAD. Maybe then the cws tooling is already usable. automation basctl basic binfilter bridges codemaker comphelper connectivity cppuhelper crashrep desktop dtrans external filter framework goodies i18npool idlc instsetoo jurt linguistic odk offapi officecfg package qadevOOo readlicense readlicense_oo ridljar rsc salhelper sc scaddins sch scripting sd sdk_oo setup2 sfx2 shell sj2 smoketest so3 solenv soltools stlport stoc svtools svx sw sysui toolkit tools ucb unotools unoxml unzip vcl vos
Nice to have, but later ...
Reset assignee on issues not touched by assignee in more than 1000 days.