[MacPorts] #63575: stellarium @0.21.2 +RemoteControl+debug+python39: DEBUG being defined leads to: error: expected identifier

[MacPorts]

#63575: stellarium @0.21.2 +RemoteControl+debug+python39: DEBUG being defined leads
to: error: expected identifier
--------------------------+--------------------
  Reporter:  cooljeanius  |      Owner:  (none)
      Type:  defect       |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:  2.7.1
Resolution:               |   Keywords:
      Port:  stellarium   |
--------------------------+--------------------

Comment (by ryandesign):

 Well, the debug variant defined in the cmake 1.1 portgroup sets `DEBUG`
 (to no value, which means it's set to `1`). Presumably the cmake 1.1
 portgroup does this because it was believed that most projects would use a
 `DEBUG` define to indicate whether or not to enable debugging code, but
 I'm not sure if that's really a standard. Stellarium expects `DEBUG` not
 to be defined to anything because it uses it for other purposes:

 {{{#!cpp
                 DEBUG           = (1<<16),
 }}}

 After expanding that code to translate `DEBUG` to its defined value `1` it
 becomes:

 {{{#!cpp
                 1               = (1<<16),
 }}}

 which is of course nonsense. So you could file a bug report with
 Stellarium and ask them to rename `DEBUG` to something else on the theory
 that it is not unusual for people to expect to be able to define `DEBUG`,
 or you could add code to the stellarium Portfile that undefines `DEBUG`
 again when the debug variant is used, and then also add anything that
 stellarium might need to tell it to build debugging code. You could also
 possibly campaign for the removal of the code in the cmake 1.1 portgroup
 that defines `DEBUG` on the basis that it is nonstandard and causes
 breakage, though then probably code to define `DEBUG` would have to be
 added to all other ports that use the cmake 1.1 portgroup so that their
 behavior wouldn't change.

 The cmake 1.0 and 1.1 portgroups also define `NDEBUG` when the debug
 variant is not set. This is at least a standard in that it tells C and C++
 to turn the `assert` function into a no-op. I could not find consensus on
 whether it is a good idea to use `NDEBUG` for other unrelated debugging
 code.

-- 
Ticket URL: <https://trac.macports.org/ticket/63575#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS