gvemodules-xforms @0.2: error: unexpected type name 'HPtNCoord': expected expression

[ryandesign (Ryan Carsten Schmidt)]

​gvemodules-xforms does not build:

In file included from graffiti.c:29:
In file included from ./graffiti.h:23:
In file included from /opt/local/include/geomview/3d.h:34:
/opt/local/include/geomview/hpointn.h:540:20: error: unexpected type name 'HPtNCoord': expected expression
  VARARRAY(vspace, HPtNCoord, dim);
                   ^
/opt/local/include/geomview/hpointn.h:540:12: error: use of undeclared identifier 'vspace'
  VARARRAY(vspace, HPtNCoord, dim);
           ^
/opt/local/include/geomview/hpointn.h:551:9: error: use of undeclared identifier 'vspace'
    v = vspace;
        ^
/opt/local/include/geomview/hpointn.h:613:20: error: unexpected type name 'HPtNCoord': expected expression
  VARARRAY(vspace, HPtNCoord, dim);
                   ^
/opt/local/include/geomview/hpointn.h:613:12: error: use of undeclared identifier 'vspace'
  VARARRAY(vspace, HPtNCoord, dim);
           ^
/opt/local/include/geomview/hpointn.h:624:9: error: use of undeclared identifier 'vspace'
    v = vspace;
        ^
mv -f .deps/panel.Tpo .deps/panel.Po
6 errors generated.
make[3]: *** [graffiti.o] Error 1

[ryandesign (Ryan Carsten Schmidt)]

Same for gvemod-ndview... Please check all ports that use geomview; they may all be affected:

• gvemod-cplxview
• gvemod-crayola
• gvemod-labeler
• gvemod-ndview
• gvemod-xforms-example
• gvemodules-xforms
• maniview
• orrery

[raphael-st (Raphael Straub)]

In 7c38d59e4602aba07e877ad03a348bea7ea2f7fd/macports-ports (master):

gvemod-cplxview: Update to 0.3

See #57441

[raphael-st (Raphael Straub)]

In 2ec68a0648dbb72345e6f42a9f5e2409cc49cd54/macports-ports (master):

gvemod-crayola: Update to 0.4

See #57441

[raphael-st (Raphael Straub)]

In 2a40873c7631a05503158839161191f2b9aa2c1c/macports-ports (master):

gvemod-ndview: Update to 0.4

See #57441

[raphael-st (Raphael Straub)]

In 5ebd2affad05869cd4560db06b46c32d66cae249/macports-ports (master):

gvemod-xforms-example: Update to 0.4

See #57441

[raphael-st (Raphael Straub)]

In 0fe733f5ce5b3c2d4f419ce87c5aea58ce0a9f43/macports-ports (master):

gvemodules-xforms: Update to 0.5

See #57441

[raphael-st (Raphael Straub)]

In 54c90afe802b5fcff82894b908d43cb1ab553ffd/macports-ports (master):

orrery: Update to 0.9.7

See #57441

[ryandesign (Ryan Carsten Schmidt)]

👍👍👍 Thanks!

[raphael-st (Raphael Straub)]

gvemod-crayola builds but still has a problem because there is a binary (src/Crayola) in the distfiles archive that obviously has overwritten the original Tcl file that is needed for the build.

gvemod-labeler does not build:

:info:build In file included from labeler.c:36:
:info:build In file included from /opt/local/include/tk.h:96:
:info:build /opt/local/include/X11_tk/Xlib.h:28:9: warning: 'XlibSpecificationRelease' macro redefined [-Wmacro-redefined]
:info:build #define XlibSpecificationRelease 5
:info:build         ^
:info:build /opt/local/include/X11/Xlib.h:36:9: note: previous definition is here
:info:build #define XlibSpecificationRelease 6
:info:build         ^
:info:build In file included from labeler.c:36:
:info:build In file included from /opt/local/include/tk.h:96:
:info:build /opt/local/include/X11_tk/Xlib.h:62:13: error: cannot combine with previous 'int' declaration specifier
:info:build typedef int Status;
:info:build             ^
:info:build /opt/local/include/X11/Xlib.h:83:16: note: expanded from macro 'Status'
:info:build #define Status int
:info:build                ^

This seems to be a conflict between Tk and X11 headers.

[ryandesign (Ryan Carsten Schmidt)]

Replying to raphael-st:

gvemod-labeler does not build:

:info:build In file included from labeler.c:36:
:info:build In file included from /opt/local/include/tk.h:96:
:info:build /opt/local/include/X11_tk/Xlib.h:28:9: warning: 'XlibSpecificationRelease' macro redefined [-Wmacro-redefined]
:info:build #define XlibSpecificationRelease 5
:info:build         ^
:info:build /opt/local/include/X11/Xlib.h:36:9: note: previous definition is here
:info:build #define XlibSpecificationRelease 6
:info:build         ^
:info:build In file included from labeler.c:36:
:info:build In file included from /opt/local/include/tk.h:96:
:info:build /opt/local/include/X11_tk/Xlib.h:62:13: error: cannot combine with previous 'int' declaration specifier
:info:build typedef int Status;
:info:build             ^
:info:build /opt/local/include/X11/Xlib.h:83:16: note: expanded from macro 'Status'
:info:build #define Status int
:info:build                ^

This seems to be a conflict between Tk and X11 headers.

Marcus, this would be caused by your change. Should we revert that or do you have another idea?

[raphael-st (Raphael Straub)]

In 7cb64bb8c94e37225db4e9d41f00c172f5ea440f/macports-ports (master):

gvemod-crayola: Use the Tcl script from version 0.2

In the distfiles archive of version 0.4 the resulting binary has
overwritten the Tcl script because of a case-insensitive file system.
As the Tcl script did not change between 0.2 and 0.4 the script from
the 0.2 archive is used.

See #57441#comment:10

[raphael-st (Raphael Straub)]

In 8b072d54d090a524f1f41cd077d2d77bc03d53fd/macports-ports (master):

gvemod-labeler: Update to 0.4

In the distfiles archive of version 0.4 the resulting binary has
overwritten the Tcl script because of a case-insensitive file system.
As the Tcl script did not change between 0.2 and 0.4 the script from
the 0.2 archive is used.

Fixes #57441

[ryandesign (Ryan Carsten Schmidt)]

Replying to raphael-st:

gvemod-crayola builds but still has a problem because there is a binary (src/Crayola) in the distfiles archive that obviously has overwritten the original Tcl file that is needed for the build.

From what I can tell, this situation is amazing. Their build system relies on a case-sensitive filesystem because they have a script Crayola and they produce a binary crayola in the same directory. ​You warned them that this was a problem on case-insensitive filesystems in a post on their mailing list over ten years ago, and they apparently haven't done anything about it, and then they actually used macOS with a case-insensitive filesystem to mispackage their latest release. I was going to suggest finding the correct version of the file in their repository, but ​they have their code in CVS at SourceForge which is not browsable on the web, so I checked out the code using the command line. Maybe I don't know how to use CVS correctly, but it doesn't look like the CVS repositories actually contain the code; there is no src directory in there, for example. SourceForge disabled write access to CVS repositories last year, at which time the developers took ​a backup of their repositories as tarballs and put them on their web server. Those backups don't appear to contain the code either. They have ​a GitHub presence, and they ​discussed moving development there and updating those repositories with the latest code; they don't appear to have done that since ​that code is not up to date.

Since you've spoken with them on their mailing list before, maybe you can talk with them again about maybe resolving some of these issues?

Replying to raphael-st:

As the Tcl script did not change between 0.2 and 0.4 the script from the 0.2 archive is used.

How did you confirm that? Did you find the full 0.4 code somewhere?

[raphael-st (Raphael Straub)]

Replying to ryandesign:

Replying to raphael-st:

This seems to be a conflict between Tk and X11 headers.

Marcus, this would be caused by your change. Should we revert that or do you have another idea?

gvemod-labeler builds fine with the default x11 variant of the tk port, so this variant is now required.

[raphael-st (Raphael Straub)]

Replying to ryandesign:

Replying to raphael-st:

gvemod-crayola builds but still has a problem because there is a binary (src/Crayola) in the distfiles archive that obviously has overwritten the original Tcl file that is needed for the build.

From what I can tell, this situation is amazing. Their build system relies on a case-sensitive filesystem because they have a script Crayola and they produce a binary crayola in the same directory. ​You warned them that this was a problem on case-insensitive filesystems in a post on their mailing list over ten years ago, and they apparently haven't done anything about it, and then they actually used macOS with a case-insensitive filesystem to mispackage their latest release. I was going to suggest finding the correct version of the file in their repository, but ​they have their code in CVS at SourceForge which is not browsable on the web, so I checked out the code using the command line. Maybe I don't know how to use CVS correctly, but it doesn't look like the CVS repositories actually contain the code; there is no src directory in there, for example. SourceForge disabled write access to CVS repositories last year, at which time the developers took ​a backup of their repositories as tarballs and put them on their web server. Those backups don't appear to contain the code either. They have ​a GitHub presence, and they ​discussed moving development there and updating those repositories with the latest code; they don't appear to have done that since ​that code is not up to date.

Yes, your analysis is correct. I also tried to get the latest code via CVS and did not succeed.

Since you've spoken with them on their mailing list before, maybe you can talk with them again about maybe resolving some of these issues?

Maybe, but I think as long as the code on GitHub is not current, there is little chance that anybody releases new versions of the affected modules.

Replying to raphael-st:

As the Tcl script did not change between 0.2 and 0.4 the script from the 0.2 archive is used.

How did you confirm that? Did you find the full 0.4 code somewhere?

I thought that the GitHub version is the current version but you are right, this seems to be an older version. At least the modules work for me as expected now and I don't think that there were any substantial changes in these short Tcl scripts.