headers
Matěj Týč | 1 Mar 2010 14:59
Picon
Gravatar

Re: gnulib module install

On 23 February 2010 00:34, Bruno Haible <bruno <at> clisp.org> wrote:
> Hello Matěj,
>
> (how do you pronounce your name? like Matyesh?)
This one is quite difficult for English speaking people :-)
I have found this one on the web and it is quite accurate:
Approx English pronunciation for Matej: M as in "me (M.IY)" ; AA as in
"odd (AA.D)" ; T as in "tea (T.IY)" ; EY as in "ate (EY.T)" ; Y as in
"yield (Y.IY.L.D)"

>> The script solution  you have proposed does the job, but I hate when the
>> autogen.sh file has more than, let's say, ten lines.
>
> Well, the autogen.sh script has more to do if you omit more files from
> version control. An autogen.sh script of 100 lines doesn't disturb me
> much, if it is straightforward.
>
>> In fact I am
>> particularly happy if the job preceding the execution of the ./configure
>> script can be done just with autoreconf -i invocation
>
> 10 years from now, fetching gnulib might be as easy as this. Until then,
> you can help making it easier.
>
>> If I use the code in an autogen.sh of my project, the person that comes
>> to the project after me will have a problem, because he/she will have to
>> understand and maintain that code.
>
> The build infrastructure of a project has a size that is essentially
> proportional to the size of the project. It is normal to spend, say, 10%
(Continue reading)

Permalink | Reply | 5 comments |
headers
Eric Blake | 1 Mar 2010 19:37
Gravatar

gnu-web-doc-update and versioned manuals

Having just released m4-1.4.14, I noticed that gnu-web-doc-update is
currently hardcoded to put the updated manual directly in $pkg/manual.
But it seems like it might be nicer to support versioned manuals: both m4
and autoconf copy the new manual into $pkg/manual/$pkg-$ver, then update
$pkg/manual/.symlinks to redirect $pkg/manual/xyz to
$pkg/manual/$pkg-$ver/xyz, so that the latest version of the manual
appears at the usual locations but older versions are still accessible
from their longer URL.  Any suggestions for a command-line interface that
let gnu-web-doc-update should support this mode of operation?

--

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net
Permalink | Reply | 1 comment |
headers
Jim Meyering | 1 Mar 2010 19:56
Gravatar

Re: gnu-web-doc-update and versioned manuals

Eric Blake wrote:
> Having just released m4-1.4.14, I noticed that gnu-web-doc-update is
> currently hardcoded to put the updated manual directly in $pkg/manual.
> But it seems like it might be nicer to support versioned manuals: both m4
> and autoconf copy the new manual into $pkg/manual/$pkg-$ver, then update
> $pkg/manual/.symlinks to redirect $pkg/manual/xyz to
> $pkg/manual/$pkg-$ver/xyz, so that the latest version of the manual
> appears at the usual locations but older versions are still accessible
> from their longer URL.  Any suggestions for a command-line interface that
> let gnu-web-doc-update should support this mode of operation?

Yes, that could be useful for any package with two or more
versions in wide use -- presuming differences in their documentation.

Maybe --dest-dir=$package-$version
Permalink | Reply | 0 comments |
headers
Sam Steingold | 1 Mar 2010 20:59
Picon

Re: gnulib-tool feature request

On 2/27/10, Simon Josefsson <simon <at> josefsson.org> wrote:
>  >>  > Since I use gnulib in several sub-modules, I need to avoid conflicts
>  >>  > between different gnulib imports.
>  >>  > thus I need to make all those _GL_* constants module-specific.
>  >>  > thus I need gnulib-tool to accept a --macro-prefix option and this patch:
>  >>
>  >> I believe the recommended way to avoid conflicts between different
>  >>  gnulib imports is to use a separate configure.ac for each gnulib import,
>  >
>  > of course I have a separate configure.in for each module!
>  > the setup works just fine, I just don't want to have to apply the
>  > patch to gnulib-too myself each time I pull from gnulib.
>
> Then I don't understand what purpose the patch serves?  Each
>  configure.in instance should have its own namespace?

The sub-modules have to share the gnulib directories
(so that they do not include several identical object files)
which results in header conflict: each gllib directory contains
its own (e.g.) unistd.h which is adapted to the specific submodule.
therefore if all these headers use the same _GL_UNISTD_H macros,
the wrong gllib header is used, the wrong functions are declared,
the wrong system headers are included and nothing works.

This has been discussed on this list in the thread
"uname: build problem on win32" in August 2009.
See
http://www.mail-archive.com/bug-gnulib <at> gnu.org/msg14805.html
http://www.mail-archive.com/bug-gnulib <at> gnu.org/msg14807.html
http://www.mail-archive.com/bug-gnulib <at> gnu.org/msg14808.html
(Continue reading)

Permalink | Reply | 14 comments |
headers
Simon Josefsson | 1 Mar 2010 21:36
Favicon
Gravatar

Re: gnulib-tool feature request

Sam Steingold <sds <at> gnu.org> writes:

> On 2/27/10, Simon Josefsson <simon <at> josefsson.org> wrote:
>>  >>  > Since I use gnulib in several sub-modules, I need to avoid conflicts
>>  >>  > between different gnulib imports.
>>  >>  > thus I need to make all those _GL_* constants module-specific.
>>  >>  > thus I need gnulib-tool to accept a --macro-prefix option and this patch:
>>  >>
>>  >> I believe the recommended way to avoid conflicts between different
>>  >>  gnulib imports is to use a separate configure.ac for each gnulib import,
>>  >
>>  > of course I have a separate configure.in for each module!
>>  > the setup works just fine, I just don't want to have to apply the
>>  > patch to gnulib-too myself each time I pull from gnulib.
>>
>> Then I don't understand what purpose the patch serves?  Each
>>  configure.in instance should have its own namespace?
>
> The sub-modules have to share the gnulib directories
> (so that they do not include several identical object files)

I don't follow here.  I use separate configure.ac (for example in
GnuTLS), with separate gnulib directories for each configure.ac.  So
sub-modules do not _have_ to share gnulib directories.  Can't you use a
separate gnulib directory for each configure.ac?  Then there are no
header file collisions.  Yes, some object files will be duplicated, but
that isn't harmful.

> which results in header conflict: each gllib directory contains
> its own (e.g.) unistd.h which is adapted to the specific submodule.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Sam Steingold | 1 Mar 2010 21:50
Picon

Re: gnulib-tool feature request

On 3/1/10, Simon Josefsson <simon <at> josefsson.org> wrote:
>  >>  >>  > Since I use gnulib in several sub-modules, I need to avoid conflicts
>  >>  >>  > between different gnulib imports.
>  >>  >>  > thus I need to make all those _GL_* constants module-specific.
>  >>  >>  > thus I need gnulib-tool to accept a --macro-prefix option and this patch:
>  >>  >>
>  >>  >> I believe the recommended way to avoid conflicts between different
>  >>  >>  gnulib imports is to use a separate configure.ac for each gnulib import,
>  >>  >
>  >>  > of course I have a separate configure.in for each module!
>  >>  > the setup works just fine, I just don't want to have to apply the
>  >>  > patch to gnulib-too myself each time I pull from gnulib.
>  >>
>  >> Then I don't understand what purpose the patch serves?  Each
>  >>  configure.in instance should have its own namespace?
>  >
>  > The sub-modules have to share the gnulib directories
>  > (so that they do not include several identical object files)
>
>
> I don't follow here.  I use separate configure.ac (for example in
>  GnuTLS), with separate gnulib directories for each configure.ac.  So
>  sub-modules do not _have_ to share gnulib directories.  Can't you use a
>  separate gnulib directory for each configure.ac?  Then there are no
>  header file collisions.

as I said above, I do have a separate configure.in, gllib, glm4 in each module.

>  Yes, some object files will be duplicated, but
>  that isn't harmful.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Simon Josefsson | 1 Mar 2010 21:58
Favicon
Gravatar

Re: gnulib-tool feature request

Sam Steingold <sds <at> gnu.org> writes:

> On 3/1/10, Simon Josefsson <simon <at> josefsson.org> wrote:
>>  >>  >>  > Since I use gnulib in several sub-modules, I need to avoid conflicts
>>  >>  >>  > between different gnulib imports.
>>  >>  >>  > thus I need to make all those _GL_* constants module-specific.
>>  >>  >>  > thus I need gnulib-tool to accept a --macro-prefix option and this patch:
>>  >>  >>
>>  >>  >> I believe the recommended way to avoid conflicts between different
>>  >>  >>  gnulib imports is to use a separate configure.ac for each gnulib import,
>>  >>  >
>>  >>  > of course I have a separate configure.in for each module!
>>  >>  > the setup works just fine, I just don't want to have to apply the
>>  >>  > patch to gnulib-too myself each time I pull from gnulib.
>>  >>
>>  >> Then I don't understand what purpose the patch serves?  Each
>>  >>  configure.in instance should have its own namespace?
>>  >
>>  > The sub-modules have to share the gnulib directories
>>  > (so that they do not include several identical object files)
>>
>>
>> I don't follow here.  I use separate configure.ac (for example in
>>  GnuTLS), with separate gnulib directories for each configure.ac.  So
>>  sub-modules do not _have_ to share gnulib directories.  Can't you use a
>>  separate gnulib directory for each configure.ac?  Then there are no
>>  header file collisions.
>
> as I said above, I do have a separate configure.in, gllib, glm4 in
> each module.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Bruno Haible | 1 Mar 2010 22:11

Re: gnulib without autoconf?

Hi,

Ben Walton asked:
> I'm wondering whether its feasible to use gnulib in a project that
> doesn't use autoconf/automake?

I'm adding this clarification to the documentation:

2010-03-01  Bruno Haible  <bruno <at> clisp.org>

	* doc/gnulib-tool.texi (Initial import): Clarify the requirements
	regarding Automake.

--- doc/gnulib-tool.texi.orig	Mon Mar  1 22:08:02 2010
+++ doc/gnulib-tool.texi	Mon Mar  1 22:07:01 2010
 <at>  <at>  -81,8 +81,14  <at>  <at> 
  <at> section Initial import
  <at> cindex initial import

-Gnulib assumes your project uses Autoconf and Automake.  Invoking
- <at> samp{gnulib-tool --import} will copy source files, create a
+Gnulib assumes that your project uses Autoconf.  When using Gnulib, you
+will need to have Autoconf and Automake among your build tools.  Note that
+while the use of Automake in your project's top level directory is an
+easy way to fulfil the Makefile conventions of the GNU coding standards,
+Gnulib does not require it.  But when you use Gnulib, Automake will be
+used at least in a subdirectory of your project.
+
+Invoking  <at> samp{gnulib-tool --import} will copy source files, create a
  <at> file{Makefile.am} to build them, generate a file  <at> file{gnulib-comp.m4} with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Steingold | 1 Mar 2010 22:11
Picon

Re: gnulib-tool feature request

On 3/1/10, Simon Josefsson <simon <at> josefsson.org> wrote:
> Sam Steingold <sds <at> gnu.org> writes:
>  > as I said above, I do have a separate configure.in, gllib, glm4 in
>  > each module.
>
> I am confused.  If they are separate, how could the gnulib generated
>  files conflict with each other?

I use "gnulib-tool --avoid" to put the common parts in one place.

--

-- 
Sam Steingold <http://sds.podval.org>
Permalink | Reply | 10 comments |
headers
Simon Josefsson | 1 Mar 2010 22:39
Favicon
Gravatar

Re: gnulib-tool feature request

Sam Steingold <sds <at> gnu.org> writes:

> On 3/1/10, Simon Josefsson <simon <at> josefsson.org> wrote:
>> Sam Steingold <sds <at> gnu.org> writes:
>>  > as I said above, I do have a separate configure.in, gllib, glm4 in
>>  > each module.
>>
>> I am confused.  If they are separate, how could the gnulib generated
>>  files conflict with each other?
>
> I use "gnulib-tool --avoid" to put the common parts in one place.

Then I believe you are a bit on your own to make sure the resulting
pieces work together, which could include applying local patches to
gnulib-tool.

I tend to prefer ease of maintenance over optimizing code size for
non-modern and/or non-GNU systems.  The amount of system-replacing
gnulib object code pulled in shouldn't be too large even on older GNU
systems.  Did you try to measure the bloat size?  Which modules with
object code do you need in every sub-module?

/Simon
Permalink | Reply | 9 comments |

Gmane