-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
help2man fails to generate megaglest_editor.6 #50
Comments
We should either add --help output to these tools (preferred) or not run help2man (to automatically generate man pages) on those (only). |
@akien-mga: 3.11.0 had a bug in the map editor which crashes it on startup on some systems, depending on the wxwidget version which was used. Maybe thats why you got no output for --help? |
Well I've just tried and it's true that megaglest_editor crashes on my system with wxWidgets 2.8.12. I'll try to build against wxWidgets 3.0 and see if that fixes the issue. For the --help output, I don't have particular wishes, I'm just reporting that the default buildsystem seems to fine it incompatible with the generation of a manpage via help2man.
|
The bug is still valid with megaglest 3.11.1. I confirm that |
Ok, the funny thing is that this bug happens only when I try to build a megaglest RPM. If I build without the RPM spec file but using the exact same CMake and make arguments, I get no issue with help2man... I don't know why it would behave differently when run through a RPM spec file, maybe the shell environments differs and something funny happens? My guess would be that something delays the generation/copy of the linked executable, but make still goes on and gives the hand to the manpage generation too early. I've confirmed that trying to run help2man on a non-existing target gives the same error as in my initial post:
A workaround could be to add some delay between the linking step and the step which generates the man page. Do you know how I could achieve that? |
I've dug in some more, and it seems help2man fails even if I call it myself in the RPM spec file, so this whole issue is about an RPM issue. IMO you can close it as invalid. |
Actually the
The fact that one target is working and the other two don't makes me wonder if there would be a difference in the way those --help methods are coded (maybe for the editor and g3dviewer it's handled somehow by wxgtk?) that could explain why some seem to send their output to stderr when in a RPM build environment... |
So this seems to be a bug in some software we depend on. We might still try to work around it. |
This patch is applied |
Building MegaGlest 3.11.0 (but this was already valid previously judging by Mageia's patch to disable manpage generation since 3.9.0), the generation of megaglest_editor.6 fails with:
Mageia's patch also disabled the generation of the g3d_viewer man page, so I suppose it must also fail in a similar way.
The text was updated successfully, but these errors were encountered: