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)
Change History (7)
comment:1 Changed 3 years ago by cooljeanius (Eric Gallager)
comment:2 follow-up: 3 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 follow-up: 4 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 defineDEBUG
.
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 defineDEBUG
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 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 defineDEBUG
.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:5 Changed 6 months ago by kencu (Ken)
looks like they fixed it…
https://github.com/Stellarium/stellarium/commit/4f56d74b59622799dbe5fa7d85cddd329347560e
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...
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...