Simon Josefsson wrote:
> btw, is the strdup dependency from striconveha really needed?)
You don't need to bother, because the 'strdup' module is marked "obsolete", and
unless you explicitly pass --with-obsolete, you won't get obsolete modules [1].
Bruno
[1] http://www.gnu.org/software/gnulib/man
Simon Josefsson wrote:
> I didn't know why a
> certain module was pulled in, and it wasn't immediately clear from the
> modules I requested. A different way to resolve this problem could be
> with a 'gnulib-tool --why strdup' command that could print:
>
> uniconv/u8-strconv-from-locale
> unic
Bruno Haible writes:
> Eric Blake wrote:
>> the list is sorted alphabetically,
>> with no bearing on dependency chains other than that explicitly
>> requested modules appear with less indentation.
>
> Yes, that's how it's done.
Oops. Thanks for explaining, I was reading too much into the output
Eric Blake wrote:
> the list is sorted alphabetically,
> with no bearing on dependency chains other than that explicitly
> requested modules appear with less indentation.
Yes, that's how it's done.
> Maybe listing the dependency of each module would be nicer than the
> current alphabetic list
Li
On 03/22/2011 01:08 PM, Simon Josefsson wrote:
> The output below is printed when I run 'gnulib-tool --add-import'. Look
> carefully at it. For example it gives the impression that 'gperf' and
> 'iconv' are dependencies of 'git-version-gen' which seems bogus.
I don't get that impression. Rather
For a project that has this gnulib-cache.m4 content:
gl_MODULES([
git-version-gen
lib-symbol-versions
maintainer-makefile
uniconv/u8-strconv-from-locale
unictype/bidicategory-of
unictype/category-M
unictype/category-test
unictype/joiningtype-of
uninorm/nfc
uninorm/u32-normalize
