Jim Meyering wrote:
> > Would it help to have an option for gnulib-tool that avoids running
> > configure, knowing that it will be run afterwards anyway? Currently
> > gnulib-tool invokes configure and make for generating distributed
> > built files (i.e. running bison, gperf, or similar unusual to
Bruno Haible wrote:
...
> Would it help to have an option for gnulib-tool that avoids running
> configure, knowing that it will be run afterwards anyway? Currently
> gnulib-tool invokes configure and make for generating distributed
> built files (i.e. running bison, gperf, or similar unusual tools)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Simon Josefsson on 10/4/2009 5:24 AM:
> Right, but the solution assumes that people building my software from
> version controlled sources has installed the same version of gnulib that
> was used when my software was committed to the repos
Simon Josefsson wrote:
> Right, but the solution assumes that people building my software from
> version controlled sources has installed the same version of gnulib that
> was used when my software was committed to the repository. I don't
> think that is reliable in the long run, or rather, it is
Bruno Haible writes:
> Simon Josefsson wrote on 2009-08-31:
>> > Until then, you have to overwrite autopoint'ed files with copies brought in
>> > by gnulib-tool.
>>
>> Is this still the recommended practice for using autopoint and
>> gnulib-tool together?
>>
>> I ran into an issue where size_max
Simon Josefsson wrote on 2009-08-31:
> > Until then, you have to overwrite autopoint'ed files with copies brought in
> > by gnulib-tool.
>
> Is this still the recommended practice for using autopoint and
> gnulib-tool together?
>
> I ran into an issue where size_max.m4 imported by autopoint was ol
Bruno Haible writes:
>> Would this problem go away if gnulib's copy is updated?
>
> This problem will only go away when either the integration between
> gettextize and automake is improved (but this is stalled since apparently
> currently noone with automake skills seriously wants to work with me
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>>> Any suggestions?
>>
>> The config.rpath in gnulib is newer than the one from the latest gettext
>> release (0.16.1). Therefore I would move build-aux/config.rpath away so
>> that autopoint doesn't see it, an
Bruno Haible <[EMAIL PROTECTED]> writes:
>> Any suggestions?
>
> The config.rpath in gnulib is newer than the one from the latest gettext
> release (0.16.1). Therefore I would move build-aux/config.rpath away so
> that autopoint doesn't see it, and then move it back.
Ok, I have made the GNUmakefi
Hi Simon,
> Some modules, e.g. havelib, ship a config.rpath into build-aux.
> However, autopoint doesn't like this file and complains:
>
> [EMAIL PROTECTED]:~/src/gnutls$ autopoint
> autopoint: File build-aux/config.rpath has been locally modified.
> autopoint: *** Some files have been locally mo
Hi! Some modules, e.g. havelib, ship a config.rpath into build-aux.
However, autopoint doesn't like this file and complains:
[EMAIL PROTECTED]:~/src/gnutls$ autopoint
autopoint: File build-aux/config.rpath has been locally modified.
autopoint: *** Some files have been locally modified. Not overwr
11 matches
Mail list logo
