Re: rules, rules, and more (code policy) rules
Simon Josefsson <[EMAIL PROTECTED]> wrote: > I think CVS_LIST has some disadvantages: > > * Unrelated to the core problem. The core problem is "how to list all > C code or header files". Even if you use CVS_LIST, you'll have to > filter it further, excluding generated files the maintainer has no > control over, and include generated files the maintainer has control > over. > > * Coupled to a revision system. One cause of this is that it is > impossible to distribute the tests and run them without access to > the CVS version. `find . -name *.[chly]' work fine without CVS > access. This can be useful for beginners, or for automated testing. Not sure what you mean by `CVS access'. Those rules (and cvsu in particular) do not require access to a CVS repository. However, they do rely on the CVS/ directories that you get any time you check out a working copy. > In comparison, `find . -name *.[chly]' (or, of course, something > fancier, but you'll get the idea -- it should not depend on CVS), you > have: As I said, it's easy to extend to cover other version control systems. > * Easier to predict files will be tested automatically or not. ? > * Faster (?) IMHO, any speed difference is insignificant. > * Works without CVS access > > I don't see any major disadvantages with the find-approach. Anyone In coreutils, I'd have to add far more exclusions, especially for some of the generated test-related files. More below. > else? An exclusion/inclusion system is required with any approach, > and for most of my projects, the number of files to include/exclude is > probably equal. (Rather, I think the find-approach will cause less > manual interventions for my projects, I have several generated source > files that I control.) > >>> I'm >>> thinking of foo.h.in and generated source code files (libidn has a few >>> of these). You won't get that if you only test all files in CVS. >>> >>> I'll go with >>> >>> C_SOURCE_LIST=`find . -name *.[chly]' >> >> That approach bothered me when I had alternate versions of code >> sitting in my working directory not checked in. But I suppose it's >> worth revisiting. > > Explain? Don't you want to test those versions too? Presumably, > these tests are only used when you are looking to fix stylistic If I'm considering a version of a tool like fts.c and am not ready to check it in, should I have to add exclusions for it already? Should I check in those changes to .x-sc* files? Of course not. If I created a sample input file to help debug something, do I want to be annoyed by a `make distcheck' failure because I didn't remember to remove that file? Definitely not. Another problem is the length of the command line. With coreutils, cvsu output still fits within the `...`-imposed maximum, but `find . -type f' output is too large. These are some of the reasons I rejected the use of a blind `find . ...' command to generate the list of files to check. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: rules, rules, and more (code policy) rules
Simon Josefsson <[EMAIL PROTECTED]> wrote: >>> # Make tar archive easier to reproduce. >>> export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner >> >> Those options help minimize unnecessary differences between tar archives. ... > Still, I think the TAR stuff is different. You can't set TAR_OPTIONS > in gnulib.mk, because it is not portable. I see a couple of options: > > 1) Move the tar options stuff to automake proper. > 2) Make automake adhere to a TAR_OPTIONS make variable. > 3) Write a wrapper-script for 'tar' that is included, which >will set those variables if possible. What are you trying to accomplish? Making this minor optimization work also for developers who don't have GNU tar does not justify splitting things into separate files. Why do you want a TAR_OPTIONS variable? Can't you just define AMTAR to include whatever options you want? If portability is an issue, then do the same thing here that I did with gzip's --rsyncable option. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: rules, rules, and more (code policy) rules
Simon Josefsson <[EMAIL PROTECTED]> wrote: > I'm now using this (with a couple of modifications) in GNU SASL. > > One thing that struck me as very useful, is the ability to invoke > tests without having to autoreconf + configure. ... If I forget to run ./configure ..., I'd rather get a warning than have GNUmakefile run it for me. Providing the rules might be nice, as long as they're hooked to some nonstandard target. ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
gnulib-tool basics
First, regarding gnulib-tool --help. --update isn't mentioned under "Operation modes:", although it is one of the usages. I suggest mentioning that --import can also be used for updating, something like this (as I understand it from gnulib-tool.texi): --import import the given modules into the current package; if no modules are specified, update the current package. Second, I tried gnulib-tool --dry-run --update and got this: gnulib-tool: invalid options for 'update' mode Try 'gnulib-tool --help' for more information. If you really want to modify the gnulib configuration of your project, you need to use 'gnulib --import' - at your own risk! I don't want to modify the configuration ... Third, I tried gnulib-tool --dry-run --import and got this output: Module list with included dependencies: File list: lib/dummy.c m4/onceonly_2_57.m4 Create directory ./lib Create directory ./m4 cp: cannot create regular file `./lib/dummy.c.tmp': No such file or directory gnulib-tool: *** failed gnulib-tool: *** Stop. But my configure.ac says: gl_EARLY gl_SOURCE_BASE(gnulib/lib) gl_M4_BASE(gnulib/m4) gl_LIB(libgnulib) gl_MODULES(getopt) gl_INIT ... so I would have expected it to know to use gnulib/lib and gnulib/m4, not lib/ and /m4. It's been a while, but my memory is that it did read the configure.ac settings last time I tried it. It's not just a matter of --dry-run; I ran gnulib-tool --import without the --dry-run, and it did indeed create lib/ and m4/. Help? Thanks, k ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
libopts and gnulib?
Hi everyone,
Bruce Korb implemented a library for straightforward config file
parsing (among other things). We thought it would make sense to use it
for GNU Hello, as an example of how it can be done.
Of course, it involves a new Autoconf macro to test whether the library
is available. And of course again, I don't want that macro to live in
GNU Hello, since the goal is not Hello functionality, it's to be an
example. So I want it to be in a common place. Which I guess is
gnulib.
Does all that sound reasonable? If so, my question is how to do this --
I guess define a new module. I confess I am not clear on the exact
steps to do this. Should have paid better attention in school, I know ...
Following is the macro Bruce wrote; he named the file libopts.m4, since
that's the name of the library. http://directory.fsf.org/GNU/libopts.html
(I guess "; then" would be preferred to "then"?)
Thanks,
karl
+AC_DEFUN([ag_FIND_LIBOPTS],
+[if test "X${ac_cv_header_autoopts_options_h}" == Xno
+then
+ :
+else
+ f=`autoopts-config cflags` 2>/dev/null
+ test X"${f}" = X && f=`libopts-config cflags` 2>/dev/null
+ if test X"${f}" = X
+ then
+:
+ else
+AC_DEFINE([HAVE_LIBOPTS],[1],[define if we can find libopts])
+CFLAGS="${CFLAGS} ${f}"
+f=`autoopts-config ldflags` 2>/dev/null
+test X"${f}" = X && f=`libopts-config ldflags` 2>/dev/null
+LIBS="${LIBS} ${f}"
+ fi
+fi])
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: gnulib-tool basics
[EMAIL PROTECTED] (Karl Berry) writes: > ... so I would have expected it to know to use gnulib/lib and gnulib/m4, > not lib/ and /m4. It's been a while, but my memory is that it did read > the configure.ac settings last time I tried it. I don't think it does anymore. I had to change my build setup to pass the gnulib-tool settings as command-line options. -- "Let others praise ancient times; I am glad I was born in these." --Ovid (43 BC-18 AD) ___ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
Re: libopts and gnulib?
[EMAIL PROTECTED] (Karl Berry) writes:
> Does all that sound reasonable?
Yes, though to be honest I don't yet understand the need for libopts.
> I guess define a new module. I confess I am not clear on the exact
> steps to do this.
The most important step is to write a file that goes into the modules/
directory, which uses the same syntax as the other files. You also
need to modify MODULES.html.sh.
> (I guess "; then" would be preferred to "then"?)
Yes, that's the usual style. But shouldn't this be using
AC_CACHE_CHECK instead?
> + f=`autoopts-config cflags` 2>/dev/null
> + test X"${f}" = X && f=`libopts-config cflags` 2>/dev/null
Generally speaking, the gnulib style is to avoid messing with CFLAGS.
Can this stuff be put into config.h instead?
> +LIBS="${LIBS} ${f}"
Similarly, it's better not to set LIBS. Instead, I would set (say)
LIB_LIBOPTS, which the user can mention as needed, in their makefiles.
> +AC_DEFINE([HAVE_LIBOPTS],[1],[define if we can find libopts])
But 'autoopts-config cflags' doesn't tell you whether you can find
libopts. Only finding libopts is likely to do that. The macro should
be using AC_LINK_IFELSE (say) to make sure that libopts is a library
that can be linked to.
Debian, for example, distinguishes between the libopts9 package, and
the libopts9-dev package. So some of libopts might well be present,
while other parts are absent.
> +CFLAGS="${CFLAGS} ${f}"
> +f=`autoopts-config ldflags` 2>/dev/null
On my host, "autoopts-config ldflags" outputs "-Wl,-R/usr/lib
-L/usr/lib -lopts", which it seems to me is more likely to cause
trouble than to fix it. Perhaps this is a libopts bug, perhaps not,
but either way it's not a good sign.
> +test X"${f}" = X && f=`libopts-config ldflags` 2>/dev/null
There are two commands, autoopts-config and libopts-config?
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
