Skip to content
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

releases don't include manpages #24

Closed
brooksdavis opened this issue Feb 11, 2015 · 6 comments
Closed

releases don't include manpages #24

brooksdavis opened this issue Feb 11, 2015 · 6 comments

Comments

@brooksdavis
Copy link
Contributor

Release tarballs have makefiles that reference manpages and they exist in the repository, but the manpages themselves are in the tarballs so the release don't build without patching.

@philshafer
Copy link

Got it. Will fix. Thanks…

On Feb 11, 2015, at 10:04 AM, Brooks Davis notifications@github.com wrote:

Release tarballs have makefiles that reference manpages and they exist in the repository, but the manpages themselves are in the tarballs so the release don't build without patching.


Reply to this email directly or view it on GitHub #24.

philshafer pushed a commit that referenced this issue Feb 19, 2015
@philshafer
Copy link

Just an update: I’ve 1/2 fixed this, in that I now make versioned manual pages on github, but making the man pages point at the specific version means using .in files for the man page sources. I need to finish that 1/2.

Thanks,
Phil

On Feb 11, 2015, at 1:04 PM, Brooks Davis notifications@github.com wrote:

Release tarballs have makefiles that reference manpages and they exist in the repository, but the manpages themselves are in the tarballs so the release don't build without patching.


Reply to this email directly or view it on GitHub #24.

@philshafer
Copy link

Ooops. Upgrade here was for another issue. This issue is fixed in develop.

@philshafer
Copy link

So I’m now publishing version content on github.io, like:

http://juniper.github.io/libxo/0.3.2/libxo-manual.html http://juniper.github.io/libxo/0.3.2/libxo-manual.html

The latest-and-greatest remains available at the original URL.

But the remaining half I still don’t have a good answer to. To make the URL above, I’d need to have autoconf generate libxo.3 from libxo.3.in (etc.) and that would be annoying. I could make a simple file containing only the version number, like:

.ds Vr 0.3.2

and have all the man pages “.so” that file. This would still be less annoying.

By annoying I mean that testing man page formatting would no longer be “nroff -man $src/libxo/libxo.3 | more”. I’d have to install them before I could see the output. Perhaps this is a low standard of “annoying”, but it’s annoying none the less….

Any suggestions?

Thanks,
Phil

On Mar 16, 2015, at 10:35 AM, Phil Shafer phil@juise.org wrote:

Just an update: I’ve 1/2 fixed this, in that I now make versioned manual pages on github, but making the man pages point at the specific version means using .in files for the man page sources. I need to finish that 1/2.

@brooksdavis
Copy link
Contributor Author

Thanks for getting the manpages into the release. They are now in the port.

I'm not sure the mandoc utility supports .so so that may not be an option. It seems like .in files wouldn't be that horrible so long as they render properly (modulo the URL) before processing. Otherwise I might be tempted to have a separate script that updates the version in the manpages and commit the change to the branch before release.

@philshafer
Copy link

On Apr 27, 2015, at 4:52 PM, Brooks Davis notifications@github.com wrote:

I'm not sure the mandoc utility supports .so so that may not be an option.

Right. I knew freebsd moved to mandoc but wasn’t thinking that would affect this. Hmm… Looks like there are enough man pages already using .so that it must be supported:

find /usr/share/man/man3 -type f | xargs grep "^.so" | wc -l
430

Then again, that was under macosx.

It seems like .in files wouldn't be that horrible so long as they render properly (modulo the URL) before processing. Otherwise I might be tempted to have a separate script that updates the version in the manpages and commit the change to the branch before release.

Or I could add an install-hook that does something like “sed s/VERSION/${LIBXO_VERSION}/“.

Thanks,
Phil

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants