Hello,
I can't help myself, but I am not satisfied with the current choice of
methods how to install a gnulib module (with respect to version control
systmes)?
AFAIK from the manual, there are two possible ways:
- Either one commits everyhing to the repository (I don't like that
since it implies existence of redundant information in the repo)
- Or one imports modules, but includes just gnulib-cache.m4 (as
described in the maual), and everybody who checks out the repo has to
have gnulib-tool installed in order to be able to build the source.
What I don't like about the second solution is the necessity of having
gnulib-tool available.
As you surely are aware of, installation of gnulib, unlike installation
of any other tool/library, is not supposed to be carried away by the
package manager as and should be performed manually from the gnulib git.
You surely can imagine that the difficulty of the build process would
increase because of this.
What I think is that some modules (like "havelib" and
"lib-symbol-visibility") can exist happily as m4 files with macro
definitions. They could be placed in the macro directory and then used
in configure.ac and Makefile.am's without any mysterious additional
stuff performed by gnulib-tool and it would be simple and clean.
Now I get quite a lot of files created and modified when I import an
IMHO a very simple module, and I don't know what is going on. Plus there
is that choice of either making the repository "dirty" or to complicate
the autoreconf process.
I am somehow aware that I can do what I want by "relying only on the
meta-information stored in the ‘modules/*’ files" and copying required
m4 files manually. But then I will really be on my own, although I think
that gnulib-tool should at least be able to notify me about updates when
asked to do so.
Do you think that this can be helped somehow?
Matej
