Opened 3 years ago

Last modified 6 months ago

#63575 new defect

stellarium @0.21.2 +RemoteControl+debug+python39: DEBUG being defined leads to: error: expected identifier

Reported by: cooljeanius (Eric Gallager) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.7.1
Keywords: Cc: michaelld (Michael Dickens)
Port: stellarium

Description

Upgrading stellarium from 0.21.1_0 +debug to 0.21.2_0 +RemoteControl+debug+python39 leads to this error:

In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_stellarium/stellarium/work/build/plugins/Scenery3d/src/Scenery3d-static_autogen/mocs_compilation.cpp:3:
In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_stellarium/stellarium/work/build/plugins/Scenery3d/src/Scenery3d-static_autogen/EWIEGA46WW/moc_S3DRenderer.cpp:10:
In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_stellarium/stellarium/work/build/plugins/Scenery3d/src/Scenery3d-static_autogen/EWIEGA46WW/../../../../../../stellarium-0.21.2/plugins/Scenery3d/src/S3DRenderer.hpp:37:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_stellarium/stellarium/work/stellarium-0.21.2/plugins/Scenery3d/src/ShaderManager.hpp:184:3: error: expected identifier
                DEBUG           = (1<<16),
                ^
<command line>:28:15: note: expanded from here
#define DEBUG 1
              ^

I'm guessing DEBUG is only defined for the +debug variant. I'm on Big Sur with Xcode 13, for reference.

Attachments (1)

stellarium_main.log (1.9 MB) - added by cooljeanius (Eric Gallager) 8 months ago.
main.log for stellarium

Download all attachments as: .zip

Change History (7)

comment:1 Changed 3 years ago by cooljeanius (Eric Gallager)

Update: I've worked around this for now by disabling the +debug variant, but I'd still like to be able to re-enable it again sometime soon...

comment:2 Changed 8 months ago by ryandesign (Ryan Carsten Schmidt)

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:

                DEBUG           = (1<<16),

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

                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.

comment:3 in reply to:  2 ; Changed 8 months ago by cooljeanius (Eric Gallager)

Replying to ryandesign:

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.

OK, I filed this: https://github.com/Stellarium/stellarium/issues/3670

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.

This will be the next thing I try if the previous option doesn't work.

Changed 8 months ago by cooljeanius (Eric Gallager)

Attachment: stellarium_main.log added

main.log for stellarium

comment:4 in reply to:  3 Changed 6 months ago by cooljeanius (Eric Gallager)

Replying to cooljeanius:

Replying to ryandesign:

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.

OK, I filed this: https://github.com/Stellarium/stellarium/issues/3670

Update on this: they closed it, saying that MacPorts shouldn't be defining DEBUG.

comment:6 Changed 6 months ago by cooljeanius (Eric Gallager)

Well, I guess we'll see what happens the next time the port gets an update...

Note: See TracTickets for help on using tickets.