Re: [bug-gnulib] proposal for fdl module
Eric Blake wrote: 2006-07-10 Eric Blake [EMAIL PROTECTED] * gnulib-tool: Avoid space-tab. (--doc-base): Add new option, for where .texi files should live. Sometimes, this creates an empty doc directory. I'm fixing this: 2006-07-29 Bruno Haible [EMAIL PROTECTED] * gnulib-tool (func_import): Don't create the $docbase directory if there is no file to store there. *** gnulib-tool.bak 2006-07-29 00:53:03.0 +0200 --- gnulib-tool 2006-07-29 02:59:47.0 +0200 *** *** 1116,1127 echo Create directory $destdir/$m4base fi fi ! if test ! -d $destdir/$docbase; then ! if $doit; then ! echo Creating directory $destdir/$docbase ! mkdir $destdir/$docbase || func_fatal_error failed ! else ! echo Create directory $destdir/$docbase fi fi if test -n $inctests; then --- 1182,1196 echo Create directory $destdir/$m4base fi fi ! docfiles=`echo $files | sed -n -e 's,^doc/,,p'` ! if test -n $docfiles; then ! if test ! -d $destdir/$docbase; then ! if $doit; then ! echo Creating directory $destdir/$docbase ! mkdir $destdir/$docbase || func_fatal_error failed ! else ! echo Create directory $destdir/$docbase ! fi fi fi if test -n $inctests; then
Re: proposal for fdl module
Eric Blake [EMAIL PROTECTED] writes: In the m4 project, I wanted to update the documentation to include the FDL in an appendix. gnulib contains doc/fdl.texi, but did not have any easy way to import it over to m4. Would this patch be acceptable to allow documentation to be pulled in as separate modules? I tried to apply the patch, but it seems it was line-wrapped. Could you send it again? I think we should install it, I use fdl in most of my packages, and synching it from gnulib seems like a good thing. Thanks, Simon
Re: proposal for fdl module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 7/11/2006 2:49 AM: Eric Blake [EMAIL PROTECTED] writes: In the m4 project, I wanted to update the documentation to include the FDL in an appendix. gnulib contains doc/fdl.texi, but did not have any easy way to import it over to m4. Would this patch be acceptable to allow documentation to be pulled in as separate modules? I tried to apply the patch, but it seems it was line-wrapped. Could you send it again? I think we should install it, I use fdl in most of my packages, and synching it from gnulib seems like a good thing. I went ahead and applied it, instead. Besides, Gary Vaughan submitted a patch to m4 that wants doc/regexprops-generic.texi available as well as fdl.texi, so it looks like documentation modules will be useful. My only question is what license should I mark the fdl module as? For now, I went with public domain - fdl.texi contains a disclaimer that it can only be used without modification, but the text of the license is certainly not GPL'd, and you can use the FDL on public domain projects. Or maybe it is time to add another license category for documentation? - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEs6BV84KuGfSFAYARAl1/AJ4te8+wa16EK20ThPpkVrYzB2NkPACghhjg xRhW5rLDPWdnl0iVOazTcOU= =bZ8o -END PGP SIGNATURE-
Re: [bug-gnulib] proposal for fdl module
Eric Blake wrote: In the m4 project, I wanted to update the documentation to include the FDL in an appendix. gnulib contains doc/fdl.texi, but did not have any easy way to import it over to m4. Would this patch be acceptable to allow documentation to be pulled in as separate modules? It would also be beneficial to the getdate module, which references doc/getdate.texi, by adding handling for a doc directory. If this was doc targeted to end-users, this might make sense. But so far only getdate.texi is an end-user doc. All other doc in gnulib is targeted at programmers, and should therefore not be incorporated in the package that uses gnulib. 2006-07-10 Eric Blake [EMAIL PROTECTED] * gnulib-tool: Avoid space-tab. What's the point of this change? Also, please present unrelated patches in different mails, and commit them in different cvs commits. Otherwise it gets hard to track the history in CVS. (--doc-base): Add new option, for where .texi files should live. Before doing this, I think we should clarify the distinction between end-user and gnulib-user doc. I'm adding this to the README. *** README 4 Jan 2006 19:18:29 - 1.15 --- README 11 Jul 2006 11:55:11 - *** *** 59,64 --- 59,70 * If the module needs configure-time checks, write an autoconf macro for it in m4/module.m4. See m4/README for details. * Write a module description modules/module, based on modules/TEMPLATE. + * If the module contributes a section to the end-user documentation, + put this documentation in doc/module.texi and add it to the Files + section of modules/module. Most modules don't do this; they have only + documentation for the programmer (= gnulib user). Such documentation + usually goes into the lib/ source files. It may also go into doc/; + but don't add it to the module description in this case. * Add the module to the list in MODULES.html.sh. You can test that a module builds correctly with: Also, in the patch, I would mention --doc-base before --tests-base. (tests-base is used only when --with-tests is specified, whereas doc-base is used always.) * modules/fdl: New module, for grabbing fdl.texi. Automake is distributing COPYING and texinfo.tex. Why would you have fdl.texi distributed by gnulib-tool, not by automake? I would not like to see conflicts arise between automake and gnulib-tool. Bruno
Re: [bug-gnulib] proposal for fdl module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Adding automake] According to Bruno Haible on 7/11/2006 5:59 AM: If this was doc targeted to end-users, this might make sense. But so far only getdate.texi is an end-user doc. All other doc in gnulib is targeted at programmers, and should therefore not be incorporated in the package that uses gnulib. Actually, regexprops-generic.texi is also end-user doc, which CVS Head of M4 wants to incorporate. 2006-07-10 Eric Blake [EMAIL PROTECTED] * gnulib-tool: Avoid space-tab. What's the point of this change? Also, please present unrelated patches in different mails, and commit them in different cvs commits. Otherwise it gets hard to track the history in CVS. Sorry, I had already committed before I saw your mail. The point was that we might as well follow our own medicine - Makefile.maint discourages space-tab sequences, becase emacs whitespace mode converts them to plain tab. Using tab-space instead makes it obvious that both characters were intended, without having to fight editors trying to collapse them. (--doc-base): Add new option, for where .texi files should live. Before doing this, I think we should clarify the distinction between end-user and gnulib-user doc. I'm adding this to the README. *** README 4 Jan 2006 19:18:29 - 1.15 --- README 11 Jul 2006 11:55:11 - *** *** 59,64 --- 59,70 * If the module needs configure-time checks, write an autoconf macro for it in m4/module.m4. See m4/README for details. * Write a module description modules/module, based on modules/TEMPLATE. + * If the module contributes a section to the end-user documentation, + put this documentation in doc/module.texi and add it to the Files + section of modules/module. Most modules don't do this; they have only + documentation for the programmer (= gnulib user). Such documentation + usually goes into the lib/ source files. It may also go into doc/; + but don't add it to the module description in this case. * Add the module to the list in MODULES.html.sh. You can test that a module builds correctly with: Also, in the patch, I would mention --doc-base before --tests-base. (tests-base is used only when --with-tests is specified, whereas doc-base is used always.) Should I go ahead and update what I committed to make this change? * modules/fdl: New module, for grabbing fdl.texi. Automake is distributing COPYING and texinfo.tex. Why would you have fdl.texi distributed by gnulib-tool, not by automake? I would not like to see conflicts arise between automake and gnulib-tool. You had the earlier proposal of making automake be smart enough to install the latest upstream version of docs, rather than the version that was current when automake was released (but most likely out of date at the time that automake is used on a package). If that is done, then I could see making fdl.texi a responsibility of automake. But for now, I find it much more convenient to use gnulib, which is already an up-to-date repository, as the source of COPYING, texinfo.tex, etc., rather than relying on the out-of-date versions that automake would install. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEs6MY84KuGfSFAYARAtNUAKCR4ayeP57m8I+NjTvP5/D9qr2/7gCggpXB zw2gkhLRQPIIDPxfqgrvZrg= =88sa -END PGP SIGNATURE-
Re: proposal for fdl module
Eric Blake [EMAIL PROTECTED] writes: According to Simon Josefsson on 7/11/2006 2:49 AM: Eric Blake [EMAIL PROTECTED] writes: In the m4 project, I wanted to update the documentation to include the FDL in an appendix. gnulib contains doc/fdl.texi, but did not have any easy way to import it over to m4. Would this patch be acceptable to allow documentation to be pulled in as separate modules? I tried to apply the patch, but it seems it was line-wrapped. Could you send it again? I think we should install it, I use fdl in most of my packages, and synching it from gnulib seems like a good thing. I went ahead and applied it, instead. Besides, Gary Vaughan submitted a patch to m4 that wants doc/regexprops-generic.texi available as well as fdl.texi, so it looks like documentation modules will be useful. Great! My only question is what license should I mark the fdl module as? For now, I went with public domain - fdl.texi contains a disclaimer that it can only be used without modification, but the text of the license is certainly not GPL'd, and you can use the FDL on public domain projects. Or maybe it is time to add another license category for documentation? How about 'self-describing' as the License: field? It is a bit problematic to have the modules file License: field be normative in some cases (for LGPL modules) and non-normative, or even incorrect, for other modules (if you put the GFDL as 'public domain'), but I don't have a good solution. /Simon
Re: proposal for fdl module
Eric Blake [EMAIL PROTECTED] writes: * modules/fdl: New module, for grabbing fdl.texi. Automake is distributing COPYING and texinfo.tex. Why would you have fdl.texi distributed by gnulib-tool, not by automake? I would not like to see conflicts arise between automake and gnulib-tool. You had the earlier proposal of making automake be smart enough to install the latest upstream version of docs, rather than the version that was current when automake was released (but most likely out of date at the time that automake is used on a package). If that is done, then I could see making fdl.texi a responsibility of automake. But for now, I find it much more convenient to use gnulib, which is already an up-to-date repository, as the source of COPYING, texinfo.tex, etc., rather than relying on the out-of-date versions that automake would install. I agree. Also, automake doesn't install COPYING or fdl.texi in the source directory, does it? So I don't see where the conflict is. A lot of packages distribute COPYING and fdl.texi. /Simon
Re: proposal for fdl module
Bruno Haible bruno at clisp.org writes:
Also, in the patch, I would mention --doc-base before --tests-base.
(tests-base is used only when --with-tests is specified, whereas doc-base
is used always.)
Okay to apply this?
2006-07-11 Eric Blake [EMAIL PROTECTED]
* gnulib-tool: List --doc-base before --tests-base.
Index: gnulib-tool
===
RCS file: /sources/gnulib/gnulib/gnulib-tool,v
retrieving revision 1.115
diff -u -r1.115 gnulib-tool
--- gnulib-tool 11 Jul 2006 12:58:27 - 1.115
+++ gnulib-tool 11 Jul 2006 14:05:36 -
@@ -240,8 +240,8 @@
# - libname, supplied_libname from --lib
# - sourcebase from --source-base
# - m4base from --m4-base
-# - testsbase from --tests-base
# - docbase from --doc-base
+# - testsbase from --tests-base
# - auxdir from --aux-dir
# - incteststrue if --with-tests was given, blank otherwise
# - avoidlist list of modules to avoid, from --avoid
@@ -256,6 +256,7 @@
supplied_libname=
sourcebase=
m4base=
+ docbase=
testsbase=
auxdir=
inctests=
@@ -337,16 +338,6 @@
--m4-base=* )
m4base=`echo X$1 | sed -e 's/^X--m4-base=//'`
shift ;;
- --tests-base )
-shift
-if test $# = 0; then
- func_fatal_error missing argument for --tests-base
-fi
-testsbase=$1
-shift ;;
- --tests-base=* )
-testsbase=`echo X$1 | sed -e 's/^X--tests-base=//'`
-shift ;;
--doc-base )
shift
if test $# = 0; then
@@ -357,6 +348,16 @@
--doc-base=* )
docbase=`echo X$1 | sed -e 's/^X--doc-base=//'`
shift ;;
+ --tests-base )
+shift
+if test $# = 0; then
+ func_fatal_error missing argument for --tests-base
+fi
+testsbase=$1
+shift ;;
+ --tests-base=* )
+testsbase=`echo X$1 | sed -e 's/^X--tests-base=//'`
+shift ;;
--aux-dir )
shift
if test $# = 0; then
@@ -454,12 +455,12 @@
case $m4base in
*/ ) m4base=`echo $m4base | sed -e $sed_trimtrailingslashes` ;;
esac
- case $testsbase in
-*/ ) testsbase=`echo $testsbase | sed -e $sed_trimtrailingslashes` ;;
- esac
case $docbase in
*/ ) docbase=`echo $docbase | sed -e $sed_trimtrailingslashes` ;;
esac
+ case $testsbase in
+*/ ) testsbase=`echo $testsbase | sed -e $sed_trimtrailingslashes` ;;
+ esac
case $auxdir in
*/ ) auxdir=`echo $auxdir | sed -e $sed_trimtrailingslashes` ;;
esac
@@ -892,8 +893,8 @@
# - libname library name
# - sourcebase directory relative to destdir where to place source code
# - m4base directory relative to destdir where to place *.m4 macros
-# - testsbase directory relative to destdir where to place unit test code
# - docbase directory relative to destdir where to place doc files
+# - testsbase directory relative to destdir where to place unit test code
# - auxdir directory relative to destdir where to place build aux
files
# - incteststrue if --with-tests was given, blank otherwise
# - avoidlist list of modules to avoid, from --avoid
@@ -910,8 +911,8 @@
cached_avoidlist=
cached_sourcebase=
cached_m4base=
- cached_testsbase=
cached_docbase=
+ cached_testsbase=
cached_libname=
cached_lgpl=
cached_libtool=
@@ -934,12 +935,12 @@
/gl_M4_BASE(/ {
s,^.*gl_M4_BASE([[ ]*\([^])]*\).*$,cached_m4base=\1,p
}
- /gl_TESTS_BASE(/ {
-s,^.*gl_TESTS_BASE([[ ]*\([^])]*\).*$,cached_testsbase=\1,p
- }
/gl_DOC_BASE(/ {
s,^.*gl_DOC_BASE([[ ]*\([^])]*\).*$,cached_docbase=\1,p
}
+ /gl_TESTS_BASE(/ {
+s,^.*gl_TESTS_BASE([[ ]*\([^])]*\).*$,cached_testsbase=\1,p
+ }
/gl_LIB(/ {
s,^.*gl_LIB([[ ]*\([^])]*\).*$,cached_libname=\1,p
}
@@ -993,13 +994,6 @@
func_fatal_error missing --source-base option
fi
fi
- # The testsbase defaults to the cached one.
- if test -z $testsbase; then
-testsbase=$cached_testsbase
-if test -z $testsbase; then
- func_fatal_error missing --tests-base option
-fi
- fi
# The docbase defaults to the cached one.
if test -z $docbase; then
docbase=$cached_docbase
@@ -1007,6 +1001,13 @@
func_fatal_error missing --doc-base option
fi
fi
+ # The testsbase defaults to the cached one.
+ if test -z $testsbase; then
+testsbase=$cached_testsbase
+if test -z $testsbase; then
+ func_fatal_error missing --tests-base option
+fi
+ fi
# The libname defaults to the cached one.
if test -z $supplied_libname; then
libname=$cached_libname
@@ -1089,6 +1090,14 @@
echo Create directory $destdir/$m4base
fi
fi
+ if test ! -d $destdir/$docbase; then
+if $doit; then
+ echo Creating directory $destdir/$docbase
+ mkdir
Re: proposal for fdl module
Eric Blake wrote: Okay to apply this? 2006-07-11 Eric Blake [EMAIL PROTECTED] * gnulib-tool: List --doc-base before --tests-base. Yes, please. It's fine. Bruno
Re: proposal for fdl module
Eric Blake wrote: * gnulib-tool: Avoid space-tab. ... emacs whitespace mode converts them to plain tab. Using tab-space instead makes it obvious that both characters were intended, without having to fight editors trying to collapse them. Thanks for explaining. Bruno
Re: proposal for fdl module
Eric Blake writes: You had the earlier proposal of making automake be smart enough to install the latest upstream version of docs, rather than the version that was current when automake was released (but most likely out of date at the time that automake is used on a package). If that is done, then I could see making fdl.texi a responsibility of automake. But for now, I find it much more convenient to use gnulib, which is already an up-to-date repository, as the source of COPYING, texinfo.tex, etc., rather than relying on the out-of-date versions that automake would install. much more convenient, certainly, because automake doesn't yet have the repository of up-to-date infrastructure files. But is that a good reason? Simon Josefsson writes: So I don't see where the conflict is. We do not yet have a conflict. But we nearly have it: 1) If fdl.texi gets distributed by automake as well, we get a conflict: automake -a and gnulib-tool --update would install different copies of the file. Quite confusing for the user to have the same file installed by different tools in different versions. 2) Similarly for texinfo.tex: If it gets added to a gnulib module, we get another conflict between automake -a and gnulib-tool --update. 3) Integration issues: The set of tools need to fit nicely together, if people shall get a feeling of a GNU Build System. People don't get this feeling if - texinfo.tex is installed in build-aux/, whereas fdl.texi is installed in $docbase, - the automake doc says that automake distributes Programs automake might require but doesn't distribute fdl.texi, whereas they have to look in the portability library for where to get the doc license which is unrelated to portability and unrelated to library. Bruno
Re: proposal for fdl module
2) Similarly for texinfo.tex: It would be better for packages using gnulib to get texinfo.tex from gnulib. It's (nearly always) newer. Of course, not all automake-using packages use gnulib. So then getting texinfo.tex from automake is useful (I guess). So, does automake refrain from installing texinfo.tex if the file already exists and is newer? If so, then it seems there can be peaceful coexistence. If not, not. Furthermore, the same is true for config.sub, config.guess, depcomp, install-sh, and tons of other files. Sorry if I'm missing the obvious here.
Re: proposal for fdl module
Eric Blake [EMAIL PROTECTED] writes: In the m4 project, I wanted to update the documentation to include the FDL in an appendix. gnulib contains doc/fdl.texi, but did not have any easy way to import it over to m4. Would this patch be acceptable to allow documentation to be pulled in as separate modules? It would also be beneficial to the getdate module, which references doc/getdate.texi, by adding handling for a doc directory. I like this, but note that getdate.texi is already part of the getdate module. It seems more appropriate to have getdate.texi there. /Simon
