[cmake-developers] Integration of manpage installation

2011-06-07 Thread 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.

-- 
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-06-07 Thread Eric Noulard
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

2011-06-07 Thread Werner Mahr
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

2011-06-07 Thread Michael Wild
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

2011-06-07 Thread Brad King
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

2011-06-07 Thread Werner Mahr
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

2011-06-07 Thread Michael Wild
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

2011-06-07 Thread Werner Mahr
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

2011-06-07 Thread Michael Wild
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-06-08 Thread Eric Noulard
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