[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

[Harry Clauson]

Follow-up Comment #5, bug #64185 (project make):

In addition, section 7.2 "Syntax of Conditionals" states:

"Extra spaces are allowed and ignored at the beginning of the conditional
directive line, but a tab is not allowed. (If the line begins with a tab, it
will be considered part of a recipe for a rule.)"

This explains why it should, and does, work correctly without the $(warning
...) statement. But it does not appear to work correctly with the addition of
that statement.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

[Harry Clauson]

Follow-up Comment #4, bug #64185 (project make):

Maybe I'm missing something here but, as I reported this issue, the recipe
else is handled correctly (that is, it is not recognized as a make else within
the recipe).

The error is caused not by the else in the recipe, but when adding the
$(warning ...) statement immediately preceding the make else. That is what
appears to cause the parser to behave incorrectly, and I don't see any reason
for such a statement to affect parsing behavior at all.

It sounds like you're saying the parser will always be confused by an indented
recipe else statement, but this was not the case.

Thank you.




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #40942] Load directive breaks Makefiles

[Paul D. Smith]

Update of bug #40942 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63219] Introduce a close function for loadable plugins.

[Paul D. Smith]

Update of bug #63219 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
   Fixed Release:None => SCM
   Triage Status:None => Medium Effort  

___

Follow-up Comment #4:

I added an implementation but I changed the name to "unload" and reworked
parts of the implementation.

I also created a API/ABI version value but couldn't find a backward-compatible
way to implement it, that I liked.  So, it's a change in the API.  If anyone
has a good idea of a better way to do it please let me know.

It is possible, via preprocessor statements, to implement a loadable module
that will work with both old and new APIs.  But unfortunately modules written
for the old API won't work with the new one.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #64185] *** only one 'else' per conditional. Stop. due to else in recipe

[Paul D. Smith]

Update of bug #64185 (project make):

  Item Group: Bug => Enhancement

___

Follow-up Comment #3:

I agree that due to parsing limitations it's very difficult to manage this as
make's keywords are too common and its structure is not regular enough.

We could modify the parser so that "else" lines which start with the recipe
prefix are ignored, so "else" that appears inside a recipe wouldn't be in
effect.  The problem with this is that the recipe prefix could be changed and
since we're not actually parsing the code we would not notice:


if FOO
all:
else
.RECIPEPREFIX = >
else
X = y
endif


How do we understand that once the .RECIPEPREFIX is modified, the "else" that
starts with a TAB should not be assumed to be a recipe prefix anymore?

I guess we can just say that it's never OK to indent make processor statements
with a TAB.  If we assume that any "else" (for example) indented with a TAB is
never a make "else" then we shouldn't have this problem.

I think.  I'm not sure how much havoc this would cause for backward
compatibility.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/