Bug #102420 for makepp: Some ifdef-ed lines remain processed (looks like parsing error)

Sat Feb 28 03:44:06 2015 Marcin.Kasperski [...] mekk.waw.pl - Ticket created

Subject:

Some ifdef-ed lines remain processed (looks like parsing error)

Attempt to run makepp on attached makefile causes errors, in my case: exec UPDATED_VAR += abc failed--No such file or directory It is caused by the fact, that (as --dump-makefile confirms) interpretation of the following snippet leaves UPDATED_VAR += abc in the makefile. What is amazing: removing almost anything (for example comment or empty else) resolves the problem. ifdef SOMEVAR_1 ifdef SOMEVAR_2 # TODO: blah blah ifndef SOMEVAR_3 ifdef SOMEVAR_4 else endif endif UPDATED_VAR += abc endif endif To reproduce: makepp -f makepp_problems.mak PS Makefile is asbsurdish but I got it while tracing problem in actual complicated makefile...

Subject:

makepp_problems.mak

# makepp (tested on 2.0.98.3) raises errors here, # caused by the fact that UPDATED_VAR remains in the output. # # See also # makepp --dump-makefile=/tmp/makepp_problems.mak -f makepp_problems.mak # cat /tmp/makepp_problems.mak .PHONY: all all : @echo Hello ifdef SOMEVAR_1 ifdef SOMEVAR_2 # TODO: blah blah ifndef SOMEVAR_3 ifdef SOMEVAR_4 else endif endif UPDATED_VAR += abc endif endif

Sat Feb 28 04:01:23 2015 Marcin.Kasperski [...] mekk.waw.pl - Correspondence added

Some version notes: - makepp 1.50 (from processes this makefile correctly - I originally tested on makepp 2.0.98.3 as-installed-by Ubuntu 14.04 - makepp 2.0.98.2 (from metacpan) seems to have the same error - makepp 2.0 (from sourceforge) seems to have the same error

Sat Feb 28 04:01:24 2015 Marcin.Kasperski [...] mekk.waw.pl - Given to PFEIFFER

Sun Mar 08 07:34:02 2015 occitan [...] esperanto.org - Correspondence added

Cześć Marcin, Depending on how you tabify this, gmake will try to run ifndef SOMEVAR_3 as part of the rule for all. The point being, that the empty line gets ignored, if...s are processed before rules, and everything after a tab is still part of the current rule. Because tabs – visually indistinguishable – have long been a headache when writing makefiles, makepp from its early days made the rule syntax more user friendly: lines that are indented further than the ':' line are the rule actions. So tabs or spaces, makepp correctly recognizes even the two inner if...s. UPDATED_VAR by the above logic is the second action to add to the rule. Too bad that doing a better job at applying its logic leads to this regression. Besides removing the ugly tab/space distinction (which in this border case is actually useful) makepp 2.0 is now more compatible with gmake :-( To make matters worse there is some attempt at legacy compatibility, by treating following lines differently depending on having less than 8 spaces or not. I don't agree with this cludge, but have not dared remove it because this might break makepp-makefiles. So indenting echo further doesn't help, while indenting UPDATED_VAR less than 8 does :-o sorry – Daniel

Sun Mar 08 07:34:03 2015 The RT System itself - Status changed from 'new' to 'open'

Sun Mar 08 07:34:05 2015 occitan [...] esperanto.org - Status changed from 'open' to 'rejected'

Sun Mar 08 15:36:56 2015 Marcin.Kasperski [...] mekk.waw.pl - Correspondence added

The makefile I quoted above is a simple example which I distilled after facing mysterious problems while porting large set of makefiles from gnumake to makepp. In real case those various ifdef-s are present before first rule (except .PHONY...). Is there anything I could do to influence this behaviour (say, by changing some makepp variable during early setup)? At the moment it is a blocker for migration, we have various multilevel ifdef's and cancelling indentation would make them horribly unreadable... PS I still do not undertand why this line is kept while surrounding ifs are false, and why removing the comment or empty else fixes the behaviour.