Re: [cmake-developers] Integration of manpage installation
2011/6/7 Michael Wild them...@gmail.com: 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(app, sources) SET_TARGET_PROPERTIES (app PROPERTIES MAN_SOURCES docs/man/) is much easier to write. Expected behaviour is to install above mentioned sheme docs/man/app* 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
[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 wer...@vollstreckernet.de: 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 appname.section or appname.lang.section to appname compress to appname.gz (maybe configurable) install to $mandir/section/appname[.gz] or $mandir/section/lang/appname[.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 appname.section or appname.lang.section to
appname
compress to appname.gz (maybe configurable)
install to $mandir/section/appname[.gz] or
$mandir/section/lang/appname[.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 appname.section or appname.lang.section to
appname
install to $mandir/section/appname[.gz] or
$mandir/section/lang/appname[.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 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(app, sources)
SET_TARGET_PROPERTIES (app PROPERTIES MAN_SOURCES docs/man/)
is much easier to write. Expected behaviour is to install above
mentioned sheme docs/man/app* 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
