[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: init.sh and C tests
From: |
Bruno Haible |
Subject: |
Re: init.sh and C tests |
Date: |
Sun, 23 May 2010 16:38:48 +0200 |
User-agent: |
KMail/1.9.9 |
Hi Jim,
> Currently I've been creating a tiny script like this for each
> program I want to wrap, git-adding it, and listing it in Files:, too.
> Taking test-areadlink-with-size as an example,
>
> #!/bin/sh
> . "${srcdir=.}/init.sh"; path_prepend_ .
> test-areadlink-with-size
> Exit $?
>
> ----------------------------------
> Obviously, that can be automated.
> I'm thinking of adding something like this for use
> in any module that uses init.sh as a trivial wrapper:
>
> GL_emit_init_sh_wrapper = \
> t=`echo $@|sed 's,.*/,,;s/\.sh$$//'`; \
> printf '%s\n' \
> '#!/bin/sh' \
> '. "$${srcdir=.}/init.sh"; path_prepend_ .' \
> "$$t"'; Exit $$?' > address@hidden && chmod a+x address@hidden && mv
> address@hidden $@
>
> Then, an individual module file could add these lines:
>
> CLEANFILES += test-areadlink-with-size.sh
> test-areadlink-with-size.sh:
> $(GL_emit_init_sh_wrapper)
> ...
> What do you think of adding the definition of GL_emit_init_sh_wrapper
> at the top of each gnulib.mk file?
Of course you can have a script for generating them somewhere on your disk,
or as a gnulib.mk rule. But I would add the files test-areadlink-with-size.sh
in git and not put them in CLEANFILES.
I would avoid to have generated source which is not present after
the user has run "configure". A few extra files in a tarball are
much better than added complexity during "make".
8 years ago, when I ported glibc to the FreeBSD kernel, I was greatly
confused by the fact that essential source files - the implementation
of functions like read(), open(), clone(), etc. - were generated on the
fly, parametrized by a table with many parameters. On top of that,
these source files were removed immediately after they were compiled.
That meant, when I grepped the entire source tree for the implementation
of read(), I did not find any.
In other words, removing actual source files from git and from tarballs,
combined with added complexity to generate them, makes it hard to fiddle with
a package that you are not familiar with.
Bruno
Re: gnulib tests leftovers, Ralf Wildenhues, 2010/05/23