Support writing man pages in MarkDown
PATCH 1/1 Support writing man pages in MarkDown
The pages are converted during the build into *roff mdoc using the pandoc tool.
--- .travis.yml | 1 + CMakeLists.txt | 4 +++ buildlib/Findpandoc.cmake | 21 +++++++++++++ buildlib/cbuild | 3 ++ buildlib/rdma_functions.cmake | 33 -------------------- buildlib/rdma_man.cmake | 70 +++++++++++++++++++++++++++++++++++++++++++ debian/control | 1 + 7 files changed, 100 insertions(+), 33 deletions(-) create mode 100644 buildlib/Findpandoc.cmake create mode 100644 buildlib/rdma_man.cmake
This is a very big series, I am only sending the first patch to the mailing list. The whole series is on github here:
https://github.com/linux-rdma/rdma-core/pull/274
Overall, I'd like to see the man pages be more editable and viewable when in patch format. Longer term I'd like to see them all rendered to HTML and hosted on the web as libfabric and systemd are doing successfully. While some of this can be done with the classic roff format, it feels very painful.
Markdown was selected because we are already using it successfully for other documentation, and libfabric has already demonstrated using it for man pages. github will natively render the markdown documentation internally for instance:
Although some places are using features specific to the 'pandoc' flavour of markdown, github still renders them in a readable format.
The next most popular choice is docbook XML, which I suspect would not be well liked (and it is very baroque as well, just in a more modern way)
The actual conversion of the man pages was done largely by script, with some manual fixes and post-inspection. There doesn't seem to be a useful mdoc to markdown conversion script, so I built a quick and dirty one that works on our .3 man page style.
The converter is here:
https://github.com/jgunthorpe/rdma-plumbing/blob/migration-tooling/buildlib/man2md.py
I'm no mdoc expert, but it sure looks to me like there are many markup problems in our man pages, even if they happen to render mostly properly.
Overall the conversion to markdown is very good in terms of resulting 'man ibv_foo' display with a few notable variances:
- The 'synopsis' is shifted right by 8 spaces and isn't bolded in quite the same way
- I ran all the C code through clang-format and asked it fit it to the standard 80 col terminal. Some of the results are 'interesting' to say the least. Others are much better than before.
- Some of the hypenation choices are a little different
pandoc is fairly widely available in the distros with the notable problem that centos 6 and 7 can only get it from EPEL.
Since this may be a problem, I am thinking about following the libfabric approach and either including the precompiled man pages in the source tree, or just providing a framework for downstream to add-on precompiled files (with a cbuild command to make them) Looking for feedback on what path is best..
.travis.yml +1 -0
@@ -32,6 +32,7 @@ addons: - libudev-dev - make - ninja-build + - pandoc - pkg-config - python - valgrind
CMakeLists.txt +4 -0
@@ -135,6 +135,7 @@ include(RDMA_BuildType) include(RDMA_DoFixup) include(publish_headers) include(rdma_functions) +include(rdma_man) if (NOT DEFINED ENABLE_STATIC) set(ENABLE_STATIC "OFF" CACHE BOOL "Produce static linking libraries as well as shared libraries.")
@@ -282,6 +283,9 @@ endif() # Look for Python FIND_PACKAGE (PythonInterp) +# Look for pandoc +FIND_PACKAGE(pandoc REQUIRED) + #------------------------- # Find libraries # pthread
buildlib/Findpandoc.cmake new file +21 -0
@@ -0,0 +1,21 @@ +# COPYRIGHT (c) 2017 Mellanox Technologies Ltd +# Licensed under BSD (MIT variant) or GPLv2. See COPYING. +find_program(PANDOC_EXECUTABLE NAMES pandoc) + +if(PANDOC_EXECUTABLE) + execute_process(COMMAND "${PANDOC_EXECUTABLE}" -v + OUTPUT_VARIABLE _VERSION + RESULT_VARIABLE _VERSION_RESULT + ERROR_QUIET) + + if(NOT _PYTHON_VERSION_RESULT) + string(REGEX REPLACE "^pandoc ([^\n]+)\n.*" "\\1" PANDOC_VERSION_STRING "${_VERSION}") + endif() + unset(_VERSION_RESULT) + unset(_VERSION) +endif() + +include(FindPackageHandleStandardArgs) +find_package_handle_standard_args(pandoc REQUIRED_VARS PANDOC_EXECUTABLE PANDOC_VERSION_STRING VERSION_VAR PANDOC_VERSION_STRING) + +mark_as_advanced(PANDOC_EXECUTABLE)
buildlib/cbuild +3 -0
@@ -98,6 +98,7 @@ class centos6(YumEnvironment): 'libnl3-devel', 'libudev-devel', 'make', + 'pandoc', 'pkgconfig', 'python', 'rpm-build',
@@ -164,6 +165,7 @@ class trusty(APTEnvironment): 'libudev-dev', 'make', 'ninja-build', + 'pandoc', 'pkg-config', 'python', 'valgrind',
@@ -309,6 +311,7 @@ class leap(ZypperEnvironment): 'udev', 'make', 'ninja', + 'pandoc', 'pkg-config', 'python3', 'rpm-build',
buildlib/rdma_functions.cmake +0 -33
@@ -229,39 +229,6 @@ function(rdma_test_executable EXEC) set_target_properties(${EXEC} PROPERTIES RUNTIME_OUTPUT_DIRECTORY "${BUILD_BIN}") endfunction() -# Install man pages. This deduces the section from the trailing integer in the -# filename -function(rdma_man_pages) - foreach(I ${ARGN}) - if ("${I}" MATCHES "\\.in$") - string(REGEX REPLACE "^.+[.](.+)\\.in$" "\\1" MAN_SECT "${I}") - string(REGEX REPLACE "^(.+)\\.in$" "\\1" BASE_NAME "${I}") - get_filename_component(BASE_NAME "${BASE_NAME}" NAME) - rdma_subst_install(FILES "${I}" - DESTINATION "${CMAKE_INSTALL_MANDIR}/man${MAN_SECT}/" - RENAME "${BASE_NAME}") - else() - string(REGEX REPLACE "^.+[.](.+)$" "\\1" MAN_SECT "${I}") - install(FILES "${I}" DESTINATION "${CMAKE_INSTALL_MANDIR}/man${MAN_SECT}/") - endif() - endforeach() -endfunction() - -# Create an alias for a man page, using a symlink. -# Input is a list of pairs of names (MAN_PAGE ALIAS) -# NOTE: The section must currently be the same for both. -function(rdma_alias_man_pages) - list(LENGTH ARGN LEN) - math(EXPR LEN ${LEN}-1) - foreach(I RANGE 0 ${LEN} 2) - list(GET ARGN ${I} FROM) - math(EXPR I ${I}+1) - list(GET ARGN ${I} TO) - string(REGEX REPLACE "^.+[.](.+)$" "\\1" MAN_SECT ${FROM}) - rdma_install_symlink("${FROM}" "${CMAKE_INSTALL_MANDIR}/man${MAN_SECT}/${TO}") - endforeach() -endfunction() - # Finalize the setup of the static libraries by copying the meta information # from the shared and setting up the libtool .la files. function(rdma_finalize_libs)
buildlib/rdma_man.cmake new file +70 -0
70 lines not on this page · raw message
debian/control +1 -0
@@ -13,6 +13,7 @@ Build-Depends: cmake (>= 2.8.11), libsystemd-dev, libudev-dev, ninja-build, + pandoc, pkg-config, python, valgrind [!alpha !armel !hppa !m68k !powerpcspe !sh4 !sparc64 !x32]
Signature · 6 lines
2.15.1 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171212225936.GA29558-uk2M96/[email protected]
Quoted 5 lines
Since this may be a problem, I am thinking about following the libfabric approach and either including the precompiled man pages in the source tree, or just providing a framework for downstream to add- on precompiled files (with a cbuild command to make them) Looking for feedback on what path is best..
FWIW, one of the reasons libfabric went with pre-compiled man pages was to include a date for the last edit. A service automatically updates the date when updating the page.
There's probably some way to get that in the markdown directly.
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 1828884A29C6694DAF28B7E6B8A82373AB1C234C-P5GAC/[email protected]
Quoted 9 lines · Sean
Quoted 5 lines
Since this may be a problem, I am thinking about following the libfabric approach and either including the precompiled man pages in the source tree, or just providing a framework for downstream to add- on precompiled files (with a cbuild command to make them) Looking for feedback on what path is best..
FWIW, one of the reasons libfabric went with pre-compiled man pages was to include a date for the last edit. A service automatically updates the date when updating the page.
This isn't going to be so useful here since all the markdown pages were created today..
What I did was to copy the date from the original man page over to the markdown header:
date: 2015-01-29
So the date visible in the man page doesn't change from what it was before (which in turn is a kind of meaningless value these days since we never bothered to keep it up to date in most cases)
Other projects don't bother with the date, for instance systemd just drops in in the package version number in that space, which actually seems more usefull to me.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 19 lines · Jason Gunthorpe
The pages are converted during the build into *roff mdoc using the pandoc tool.
--- .travis.yml | 1 + CMakeLists.txt | 4 +++ buildlib/Findpandoc.cmake | 21 +++++++++++++ buildlib/cbuild | 3 ++ buildlib/rdma_functions.cmake | 33 -------------------- buildlib/rdma_man.cmake | 70 +++++++++++++++++++++++++++++++++++++++++++ debian/control | 1 + 7 files changed, 100 insertions(+), 33 deletions(-)create mode 100644 buildlib/Findpandoc.cmake
create mode 100644 buildlib/rdma_man.cmakeThis is a very big series, I am only sending the first patch to the mailing list. The whole series is on github here:
Quoted 8 lines
https://github.com/linux-rdma/rdma-core/pull/274
Overall, I'd like to see the man pages be more editable and viewable when in patch format. Longer term I'd like to see them all rendered to HTML and hosted on the web as libfabric and systemd are doing successfully. While some of this can be done with the classic roff format, it feels very painful.
This makes sense to me.
Quoted 5 lines
Markdown was selected because we are already using it successfully for other documentation, and libfabric has already demonstrated using it for man pages. github will natively render the markdown documentation internally for instance:
Makes sense as well.
Quoted 20 lines
Although some places are using features specific to the 'pandoc' flavour of markdown, github still renders them in a readable format.
The next most popular choice is docbook XML, which I suspect would not be well liked (and it is very baroque as well, just in a more modern way)
The actual conversion of the man pages was done largely by script, with some manual fixes and post-inspection. There doesn't seem to be a useful mdoc to markdown conversion script, so I built a quick and dirty one that works on our .3 man page style.
The converter is here:
https://github.com/jgunthorpe/rdma-plumbing/blob/migration-tooling/buildlib/man2md.py
I'm no mdoc expert, but it sure looks to me like there are many markup problems in our man pages, even if they happen to render mostly properly.
Quoted 9 lines
Quoted 1 line
Overall the conversion to markdown is very good in terms of resulting
'man
ibv_foo' display with a few notable variances:
- The 'synopsis' is shifted right by 8 spaces and isn't bolded in quite the same way
- I ran all the C code through clang-format and asked it fit it to the standard 80 col terminal. Some of the results are 'interesting' to say the least. Others are much better than before.
- Some of the hypenation choices are a little different
Looked at few generated man pages, there are places that it looks *ugly* comparing to the original ones. Especially talking on the 'C' structures that were wrapped around the 80 column. (see ibv_query_device). There are cases that even in the same man page there are lines larger than 80 while others are not. We can't just drop the 'C' structures as in many places few fields may include some meaningful information, need to go per man page and consider how we would really like to see it once moving to the new format.
Quoted 3 lines
pandoc is fairly widely available in the distros with the notable problem that centos 6 and 7 can only get it from EPEL.
There might be even a worse case scenario where pandoc may not exist as a package to be installed, for example how about SLES OS ?
Quoted 6 lines
Since this may be a problem, I am thinking about following the libfabric approach and either including the precompiled man pages in the source tree, or just providing a framework for downstream to add-on precompiled files (with a cbuild command to make them) Looking for feedback on what path is best..
An approach to have an option via the cbuild to generate them on demand makes sense to me. It should use the docker/containers mechanism to enable that. Upon regular compile/build the already generated man pages will be taken from the tree, upon a man page change the cbuild environment should be used and both the man and the .md files will be pushed into the tree.
However, need to consider below notes:
1) Need to have a clear documentation to describe the required steps to do that. Man pages may be changed by many people and as such, the process to generate them must be fully clear and easy to use.
2) As the tree will hold both the 'md' files and the man pages, someone might forget to use the pandoc and upload only a change in a man page, this should be prevented by Travis or other checker script.
3) How about cases that the a man page will be generated by pandoc but someone will do manual changes to have it nicer/cleaner ? This might end-up having man page which doesn't fit to its source that may bring an issue on the next generation by someone else. --
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 455f0faf-516b-fa8d-c0d2-d2cee9194e5b-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org
Quoted 9 lines
Quoted 1 line
Am Sonntag, den 24.12.2017, 14:03 +0200 schrieb Yishai Hadas:
Quoted 3 lines · Jason Gunthorpe
Quoted 1 line
pandoc is fairly widely available in the distros with the notable
problem that centos 6 and 7 can only get it from EPEL.
There might be even a worse case scenario where pandoc may not exist as
a package to be installed, for example how about SLES OS ?
The release tarball could contain pre-built man page. So in case the OS does provide pandoc to regenerate the man pages, the pre-built can be used.
Quoted 7 lines
Quoted 7 lines
Since this may be a problem, I am thinking about following the libfabric approach and either including the precompiled man pages in
the source tree, or just providing a framework for downstream to add-on precompiled files (with a cbuild command to make them) Looking for feedback on what path is best..
Please do not place generated files in the git repository.
Signature · 18 lines
Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: [email protected] URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Benjamin Drung
Quoted 6 lines
Quoted 1 line
Am Sonntag, den 24.12.2017, 14:03 +0200 schrieb Yishai Hadas:
Quoted 3 lines · Jason Gunthorpe
Quoted 1 line
pandoc is fairly widely available in the distros with the notable
problem that centos 6 and 7 can only get it from EPEL.
Quoted 7 lines
Quoted 3 lines
There might be even a worse case scenario where pandoc may not exist as
a package to be installed, for example how about SLES OS ?The release tarball could contain pre-built man page. So in case the OS does provide pandoc to regenerate the man pages, the pre-built can be used.
Why should OS be dependent on pandoc? IMHO all releases should contain pre-built man pages and they should be used without need to regenerate them at all.
Quoted 30 lines
Quoted 8 lines
Quoted 8 lines
Since this may be a problem, I am thinking about following the libfabric approach and either including the precompiled man pages in
the source tree, or just providing a framework for downstream to add-on precompiled files (with a cbuild command to make them) Looking for feedback on what path is best..Please do not place generated files in the git repository.
--
Benjamin Drung
System Developer
Debian & Ubuntu DeveloperProfitBricks GmbH
Greifswalder Str. 207
D - 10405 BerlinEmail: [email protected]
URL: https://www.profitbricks.deSitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171227111348.GB3494-U/[email protected]
Am Mittwoch, den 27.12.2017, 13:13 +0200 schrieb Leon Romanovsky:
Quoted 21 lines · Benjamin Drung
Quoted 14 lines
Quoted 6 lines
Quoted 1 line
Am Sonntag, den 24.12.2017, 14:03 +0200 schrieb Yishai Hadas:
Quoted 3 lines · Jason Gunthorpe
Quoted 2 lines
pandoc is fairly widely available in the distros with the notable
Quoted 7 lines
Quoted 2 lines
problem that centos 6 and 7 can only get it from EPEL.
There might be even a worse case scenario where pandoc may not exist
as
a package to be installed, for example how about SLES OS ?Quoted 5 lines
The release tarball could contain pre-built man page. So in case the OS
does provide pandoc to regenerate the man pages, the pre-built can be
used.
Quoted 5 lines
Why should OS be dependent on pandoc? IMHO all releases should contain
pre-built man pages and they should be used without need to regenerate
them at all.
Debian's rule is to build everything from source where the source is in the preferred format for modification. So we will drop the pre-build man pages and build them from source - even if that would not be needed. This is useful in case we have to modify it (e.g. fix typos).
Signature · 14 lines
Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: [email protected] URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 28 lines · Benjamin Drung
Am Mittwoch, den 27.12.2017, 13:13 +0200 schrieb Leon Romanovsky:
Quoted 21 lines · Benjamin Drung
Quoted 14 lines
Quoted 6 lines
Quoted 1 line
Am Sonntag, den 24.12.2017, 14:03 +0200 schrieb Yishai Hadas:
Quoted 3 lines · Jason Gunthorpe
Quoted 2 lines
pandoc is fairly widely available in the distros with the notable
Quoted 7 lines
Quoted 2 lines
problem that centos 6 and 7 can only get it from EPEL.
There might be even a worse case scenario where pandoc may not exist
as
a package to be installed, for example how about SLES OS ?Quoted 5 lines
The release tarball could contain pre-built man page. So in case the OS
does provide pandoc to regenerate the man pages, the pre-built can be
used.Quoted 5 lines
Why should OS be dependent on pandoc? IMHO all releases should contain
pre-built man pages and they should be used without need to regenerate
them at all.
Quoted 4 lines
Debian's rule is to build everything from source where the source is in the preferred format for modification. So we will drop the pre-build man pages and build them from source - even if that would not be needed. This is useful in case we have to modify it (e.g. fix typos).
Thanks for the explanation.
Quoted 16 lines
--
Benjamin Drung
System Developer
Debian & Ubuntu DeveloperProfitBricks GmbH
Greifswalder Str. 207
D - 10405 BerlinEmail: [email protected]
URL: https://www.profitbricks.deSitz der Gesellschaft: Berlin
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg
A message that is not in the archive (sent off-list or not yet received): 20171227122056.GD3494-U/[email protected]
Am Mittwoch, den 27.12.2017, 14:20 +0200 schrieb Leon Romanovsky:
Quoted 41 lines · Benjamin Drung
Quoted 32 lines
Am Mittwoch, den 27.12.2017, 13:13 +0200 schrieb Leon Romanovsky:
Quoted 25 lines · Benjamin Drung
Quoted 16 lines
Quoted 7 lines
Quoted 2 lines
Am Sonntag, den 24.12.2017, 14:03 +0200 schrieb Yishai Hadas:
Quoted 3 lines · Jason Gunthorpe
Quoted 2 lines
pandoc is fairly widely available in the distros with the notable
Quoted 8 lines
Quoted 2 lines
problem that centos 6 and 7 can only get it from EPEL.
There might be even a worse case scenario where pandoc may not
exist
as
a package to be installed, for example how about SLES OS ?Quoted 7 lines
The release tarball could contain pre-built man page. So in case
the OS
does provide pandoc to regenerate the man pages, the pre-built can
be
used.Quoted 5 lines
Why should OS be dependent on pandoc? IMHO all releases should contain
pre-built man pages and they should be used without need to regenerate
them at all.Quoted 7 lines
Debian's rule is to build everything from source where the source is in
the preferred format for modification. So we will drop the pre- build
man pages and build them from source - even if that would not be needed. This is useful in case we have to modify it (e.g. fix typos).
Quoted 1 line
Thanks for the explanation.
FYI: Debian has a wiki page dedicated for upstream developers:
https://wiki.debian.org/UpstreamGuide
Signature · 14 lines
Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: [email protected] URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg
Quoted 6 lines · Benjamin Drung
Quoted 6 lines
Quoted 1 line
Am Sonntag, den 24.12.2017, 14:03 +0200 schrieb Yishai Hadas:
Quoted 3 lines · Jason Gunthorpe
Quoted 1 line
pandoc is fairly widely available in the distros with the notable
problem that centos 6 and 7 can only get it from EPEL.
Quoted 7 lines
Quoted 3 lines
There might be even a worse case scenario where pandoc may not exist as
a package to be installed, for example how about SLES OS ?The release tarball could contain pre-built man page. So in case the OS does provide pandoc to regenerate the man pages, the pre-built can be used.
Yes, this is my basic thinking. If pandoc is installed then the pre-built can be ignored, otherwise they are used so the build can succeed.
I was thinking of a scheme like
buildlib/man-cache/<sha1 of .md file>
So if the .md files are changed for any reason then the build will fail.
Quoted 1 line
Please do not place generated files in the git repository.
Realistically, I don't know if this is possible... Too many developers are using quite old distros these days, and they still have to be able to build..
I guess we just turn off man page generation in ./build.sh ?
But, how will 'cubild pkg centos6' work?
The release .tar.gz files are created by travis (buildilb/github-release) so it would not be too hard to have it also build the cache.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 20171227174444.GC31310-VPRAkNaXOzVWk0Htik3J/[email protected]
Am Mittwoch, den 27.12.2017, 10:44 -0700 schrieb Jason Gunthorpe:
Quoted 25 lines · Benjamin Drung
Quoted 14 lines
Quoted 6 lines
Quoted 1 line
Am Sonntag, den 24.12.2017, 14:03 +0200 schrieb Yishai Hadas:
Quoted 3 lines · Jason Gunthorpe
Quoted 2 lines
pandoc is fairly widely available in the distros with the notable
Quoted 7 lines
Quoted 2 lines
problem that centos 6 and 7 can only get it from EPEL.
There might be even a worse case scenario where pandoc may not exist
as
a package to be installed, for example how about SLES OS ?Quoted 5 lines
The release tarball could contain pre-built man page. So in case the OS
does provide pandoc to regenerate the man pages, the pre-built can be
used.Yes, this is my basic thinking. If pandoc is installed then the pre-built can be ignored, otherwise they are used so the build can succeed.
Quoted 5 lines
I was thinking of a scheme like
buildlib/man-cache/<sha1 of .md file>So if the .md files are changed for any reason then the build will fail.
None of the projects that I know build a cache using checksums. The projects are just fine with not failing when the source changed, but the man pages are not updated.
Quoted 8 lines
Quoted 1 line
Please do not place generated files in the git repository.
Realistically, I don't know if this is possible... Too many developers
are using quite old distros these days, and they still have to be able to build..I guess we just turn off man page generation in ./build.sh ?
A configuration option would be good that allows one to either enable or disable (re)generating the man pages. By default, cmake would check if pandoc is available and set the value based on that.
Quoted 5 lines
But, how will 'cubild pkg centos6' work?
The release .tar.gz files are created by travis (buildilb/github-release) so it would not be too hard to have it also build the cache.
Yes, let travis build the man pages for the release tarballs.
Signature · 18 lines
Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Email: [email protected] URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html