PA Launcher: Possible Bug

I've diagnosed what it is due to that, and it's definitely a bug (or quirk if you prefer) in NSIS. Here's my train of thought tracing it; I may be wrong in one or two points but I believe that I'm right in the essence of it:

1. A definition is provided on the command line: Name=Application - My Own Application Portable
2. NSIS definitions are case insensitive. This means that ${NAME} is equivalent to ${Name}, and both provide the value Application - My Own Application Portable.
3. FileFunc.nsh is included. FileFunc.nsh includes Util.nsh.
4. TextFunc.nsh is included. It includes FileFunc.nsh which detects it has already been included. Then TextFunc.nsh includes Util.nsh.
5. Excerpt from Util.nsh (starting from line 10):
   

   !ifndef ___UTIL__NSH___
   !define ___UTIL__NSH___
   
   # see WinVer.nsh and *Func.nsh for usage examples
   !macro CallArtificialFunction NAME
     !ifndef __UNINSTALL__
       !define CallArtificialFunction_TYPE inst
     !else
       !define CallArtificialFunction_TYPE uninst
     !endif
     Call :.${NAME}${CallArtificialFunction_TYPE}
     !ifndef ${NAME}${CallArtificialFunction_TYPE}_DEFINED
       Goto ${NAME}${CallArtificialFunction_TYPE}_DONE
       !define ${NAME}${CallArtificialFunction_TYPE}_DEFINED
   

   __UTIL__NSH__ is defined. So the parser wanders forwards until it gets to an !else or an !endif. It finds the !else (wrong one) and goes on, parsing as it goes. It's missed the !macro, so at this point it doesn't realise it's inside a macro. Thus, instead of realising ${NAME} is a macro-scope definition... it looks for a global one. Which we have (otherwise it would just become a literal "${NAME}" and a warning would be showed at the end that it was not recognised and ignored). Uh oh...

6. The tokenizer gets to the !ifdef line, line 21. ${NAME} gets expanded, so it has six parameters, but the tokenizer doesn't worry about that: !ifdef has * parameters, as you can combine checks with it like !ifdef THIS & THAT & THEOTHER & .... When it gets to actually parsing it, then it would complain about a syntax error if this code path really happened.
7. It gets to the !define line. Now this becomes like this: !define Application - My Own Application Portable${CallArtificialFunction_TYPE}_DEFINED
8. Eek! Tokenizer says there are six parameters in the !define, but the most allowed for !define is five parameters. Invalid, throw an error.
9. What should happen instead is that it should go on past that and get to the !macroend on line 30 and realise it's got something a bit wrong and go back and sort out the !ifndef properly. The way NSIS handles its parsing of compiler lines is a bit weird in general.
10. Normally the "what should happen" would happen because that !define line wouldn't go wrong. Normally Name has fewer arguments, so the !define only has five or fewer parameters when parsed incorrectly.

In the Inkscape installer I had a bit of trouble when the Windows build provider tried to generate the installer for 0.48pre1 (I think it was that release), where a certain code path ended up with !if..!endif muddling, because it missed ones in the middle. So I had to change the nesting of a couple of !if, !ifdef things to the other way round so that when the BZR_REVISION wasn't set it wouldn't get messed up. It took me quite a while to work that one out but I got it in the end.

As you can hopefully see, it's not my fault, except in that I didn't take care to avoid the glitch in the NSIS compiler by using a unique !define name.

One solution is to use a different variable - if I used PortableAppName instead of Name the problem would go away entirely. But it's still a bug in NSIS which I should report to them.

I've already had to deal with a vaguely similar issue in PAL to do with the way the parsing works; in the segments, I can use ${SegmentInit}, which has been defined in ${SegmentFile} to !macro FileName.nsh_Init, but when it gets to the end of the macro, I originally tried using a !define for ${SegmentEnd} to provide the !macroend, but that was no good because as far as the parser was concerned the ${SegmentEnd} is part of the macro, with definitions not to be parsed until the macro is included... That's why PAL has the vaguely not-neat ${SegmentInit} .. !macroend.