[cmake-developers] Integration of manpage installation
Hi, after reading some stuff about integration of KDE-stuff into cmake, I want to know your oppinion about manpages. At least on unix-based systems it's an essential function of a build-environment to allow installation of the docs. My suggestion is, to add a new property like man-source-dir or somehow like that, and all pages in that dir are installed to the right place if they start with the name of the corresponding executable. I would like to discuss that before I start digging into the code, to avoid to finish something that you like to have solved in a different place. -- MfG usw. Werner Mahr ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integration of manpage installation
2011/6/7 Werner Mahr : > Hi, > > after reading some stuff about integration of KDE-stuff into cmake, I > want to know your oppinion about manpages. At least on unix-based > systems it's an essential function of a build-environment to allow > installation of the docs. > > My suggestion is, to add a new property like man-source-dir or somehow > like that, and all pages in that dir are installed to the right place if > they start with the name of the corresponding executable. > > I would like to discuss that before I start digging into the code, to > avoid to finish something that you like to have solved in a different > place. Have a look at the new (in 2.8.4) GnuInstallDirs.cmake module: http://www.cmake.org/Bug/view.php?id=3976 -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integration of manpage installation
Eric Noulard wrote: >> My suggestion is, to add a new property like man-source-dir or >> somehow like that, and all pages in that dir are installed to the >> right place if they start with the name of the corresponding >> executable. > Have a look at the new (in 2.8.4) GnuInstallDirs.cmake module: > > http://www.cmake.org/Bug/view.php?id=3976 This Bug is about Vars for the installation-dirs, I'm thinking about installation-process. Usually manpages are named in sources like "cmake.1" and are installed $mandir/1/cmake or most often $mandir/1/cmake.gz So I want to implement functionality to allow the dwevs to just give the place of manpage-sources and let cmake do all the steps: Rename from . or .. to compress to .gz (maybe configurable) install to $mandir//[.gz] or $mandir///[.gz] If $mandir is given directly or configured in a var like your link describes doesn't matter in this case. I don't know about other systems like Linux, so maybe the process is different for other plattforms, but at least in Linux-systems it would be a great help. As I started porting amule to cmake I got stuck at exactly that point. Google just pointed out hits where the poster got told to look how others did it, but there's no generic solution. I would prefer to provide such a generic solution instead of reinventing the wheel for such a common task over and over again. -- MfG usw. Werner Mahr ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integration of manpage installation
On 06/07/2011 03:47 PM, Werner Mahr wrote: > Eric Noulard wrote: > >>> My suggestion is, to add a new property like man-source-dir or >>> somehow like that, and all pages in that dir are installed to the >>> right place if they start with the name of the corresponding >>> executable. > >> Have a look at the new (in 2.8.4) GnuInstallDirs.cmake module: >> >> http://www.cmake.org/Bug/view.php?id=3976 > > This Bug is about Vars for the installation-dirs, I'm thinking about > installation-process. > > Usually manpages are named in sources like "cmake.1" and are installed > $mandir/1/cmake > > or most often > > $mandir/1/cmake.gz > > So I want to implement functionality to allow the dwevs to just give the > place of manpage-sources and let cmake do all the steps: > > Rename from . or .. to > > > compress to .gz (maybe configurable) > > install to $mandir//[.gz] or > $mandir///[.gz] > > If $mandir is given directly or configured in a var like your link > describes doesn't matter in this case. I don't know about other systems > like Linux, so maybe the process is different for other plattforms, but > at least in Linux-systems it would be a great help. > > As I started porting amule to cmake I got stuck at exactly that point. > Google just pointed out hits where the poster got told to look how > others did it, but there's no generic solution. I would prefer to > provide such a generic solution instead of reinventing the wheel for > such a common task over and over again. > install(FILES cmake.1 DESTINATION ${CMAKE_INSTALL_FULL_MANDIR}/man1 COMPONENT doc) If you want gzipping, either leave it to the package generation system (e.g. dh_installman on Debian and cohorts) or add a custom command to do so. Michael ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integration of manpage installation
On 06/07/2011 10:31 AM, Michael Wild wrote: > install(FILES cmake.1 > DESTINATION ${CMAKE_INSTALL_FULL_MANDIR}/man1 COMPONENT doc) Actually that should be CMAKE_INSTALL_MANDIR. The documentation of GnuInstallDirs specifies that the variables without _FULL_ are meant for passing to install command DESTINATION arguments. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integration of manpage installation
Michael Wild wrote: >> Rename from . or .. to >> >> install to $mandir//[.gz] or >> $mandir///[.gz] > install(FILES cmake.1 > DESTINATION ${CMAKE_INSTALL_FULL_MANDIR}/man1 COMPONENT doc) > > If you want gzipping, either leave it to the package generation system > (e.g. dh_installman on Debian and cohorts) or add a custom command to > do so. Gzipping isn't the problem, the problem are these two steps above. With this command no transformation is done. amule.1 goes to $mandir/man1/amule.1 instead of $mandir/man1/amule.1 amule.de.1 goes to $mandir/man1/amule.de.1 $mandir/de/man1/amule.1 Even worse locale.7 would go to $mandir/man1/locale.7 where it definitely not belongs. -- MfG usw. Werner Mahr ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integration of manpage installation
On 06/07/2011 05:59 PM, Werner Mahr wrote: > Michael Wild wrote: > >>> Rename from . or .. to >>> > >>> install to $mandir//[.gz] or >>> $mandir///[.gz] > >> install(FILES cmake.1 >> DESTINATION ${CMAKE_INSTALL_FULL_MANDIR}/man1 COMPONENT doc) >> >> If you want gzipping, either leave it to the package generation system >> (e.g. dh_installman on Debian and cohorts) or add a custom command to >> do so. > > Gzipping isn't the problem, the problem are these two steps above. With > this command no transformation is done. > > amule.1 goes to $mandir/man1/amule.1 instead of $mandir/man1/amule.1 > amule.de.1 goes to $mandir/man1/amule.de.1 $mandir/de/man1/amule.1 > > Even worse > locale.7 would go to $mandir/man1/locale.7 where it definitely not > belongs. > foreach(m amule.1 amule.de.1 locale.7) get_filename_component(b ${m} NAME_WE) get_filename_component(e ${m} EXT) if(e MATCHES "(([a-zA-Z_-]+)\\.)?([0-9])") set(l "${CMAKE_MATCH_2}") set(s "${CMAKE_MATCH_3}") else() message(SEND_ERROR "Failed to parse language and section from manpage name '${m}'") endif() install(FILES ${m} DESTINATION "${CMAKE_INSTALL_MANDIR}/${l}/man${s}" COMPONENT doc RENAME ${b}.${s}) endforeach() Michael ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integration of manpage installation
Michael Wild wrote: > foreach(m amule.1 amule.de.1 locale.7) > get_filename_component(b ${m} NAME_WE) > get_filename_component(e ${m} EXT) > if(e MATCHES "(([a-zA-Z_-]+)\\.)?([0-9])") > set(l "${CMAKE_MATCH_2}") > set(s "${CMAKE_MATCH_3}") > else() > message(SEND_ERROR > "Failed to parse language and section from manpage name '${m}'") > endif() > install(FILES ${m} > DESTINATION "${CMAKE_INSTALL_MANDIR}/${l}/man${s}" COMPONENT doc > RENAME ${b}.${s}) > endforeach() Unfortunately not: CMake Error at docs/man/cmake_install.cmake:38 (FILE): file called with network path DESTINATION. This does not make sense when using DESTDIR. Specify local absolute path or remove DESTDIR environment variable. DESTINATION= //man1 Call Stack (most recent call first): cmake_install.cmake:39 (INCLUDE) Plus there are files out there like: svgalib.faq.de.7 which would raise the error in the code. I don't think that writing stuff like this in many different projects is a good idea, that's why I proposed to include it native in cmake. ADD_EXECUTABLE(, ) SET_TARGET_PROPERTIES ( PROPERTIES MAN_SOURCES "docs/man/") is much easier to write. Expected behaviour is to install above mentioned sheme docs/man/* to the right places. >From my point as a dev participating in more than one prjoect it would be a pita to try to understand how they implemented their manpage- installation, plus it would slim down many projects lot. -- MfG usw. Werner Mahr ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integration of manpage installation
On 06/07/2011 07:40 PM, Werner Mahr wrote: > Michael Wild wrote: > >> foreach(m amule.1 amule.de.1 locale.7) >> get_filename_component(b ${m} NAME_WE) >> get_filename_component(e ${m} EXT) >> if(e MATCHES "(([a-zA-Z_-]+)\\.)?([0-9])") >> set(l "${CMAKE_MATCH_2}") >> set(s "${CMAKE_MATCH_3}") >> else() >> message(SEND_ERROR >> "Failed to parse language and section from manpage name '${m}'") >> endif() >> install(FILES ${m} >> DESTINATION "${CMAKE_INSTALL_MANDIR}/${l}/man${s}" COMPONENT doc >> RENAME ${b}.${s}) >> endforeach() > > Unfortunately not: > > CMake Error at docs/man/cmake_install.cmake:38 (FILE): > file called with network path DESTINATION. This does not make sense > when > using DESTDIR. Specify local absolute path or remove DESTDIR > environment > variable. > > DESTINATION= > > //man1 > Call Stack (most recent call first): > cmake_install.cmake:39 (INCLUDE) That is a different, unrelated problem. > > Plus there are files out there like: > > svgalib.faq.de.7 > > which would raise the error in the code. Well, then that can be fixed. > I don't think that writing > stuff like this in many different projects is a good idea, that's why I > proposed to include it native in cmake. > > ADD_EXECUTABLE(, ) > SET_TARGET_PROPERTIES ( PROPERTIES MAN_SOURCES "docs/man/") > > is much easier to write. Expected behaviour is to install above > mentioned sheme docs/man/* to the right places. > > From my point as a dev participating in more than one prjoect it would > be a pita to try to understand how they implemented their manpage- > installation, plus it would slim down many projects lot. > IMHO, sounds an awful lot like DWIM to me, but others might disagree. I don't think that CMake could satisfy everybody by using such a scheme. Just my 2c... Michael ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integration of manpage installation
2011/6/7 Michael Wild : > On 06/07/2011 07:40 PM, Werner Mahr wrote: >> Michael Wild wrote: [...] >> I don't think that writing >> stuff like this in many different projects is a good idea, that's why I >> proposed to include it native in cmake. >> >> ADD_EXECUTABLE(, ) >> SET_TARGET_PROPERTIES ( PROPERTIES MAN_SOURCES "docs/man/") >> >> is much easier to write. Expected behaviour is to install above >> mentioned sheme docs/man/* to the right places. >> >> From my point as a dev participating in more than one prjoect it would >> be a pita to try to understand how they implemented their manpage- >> installation, plus it would slim down many projects lot. >> > > IMHO, sounds an awful lot like DWIM to me, but others might disagree. I > don't think that CMake could satisfy everybody by using such a scheme. > Just my 2c... Agreed. When the tool you use is too smart you end-up scratching your head forever when the smart behavior breaks. Be sure that the smart feature you handle WILL be broken by some unexpected usage and one will have to handle the bug reports it generates. I think, CMake should have solid not-too-basic cross-platform features set then if you want something smart, then write a CMake module which may eventually go upstream. In the end if the smart behavior breaks then you know where to look at. Moreover MAN pages are a Unix things and CMake has to work on Windows too. I would rather avoid platform-specific things in CMake builtin, currently there is not so much such things (besides WIN32 and MAC_OSBUNDLE) and I find it should stay that way if possible. My 2.5 c :-] -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers