Re: packages tests

[Collin Funk]

On 4/1/24 3:11 PM, Bruno Haible wrote:
> I also tried a few packages. Depending on the package, I use
>   - $ gnulib-tool --update
>     if the package has a gnulib-cache.m4 under version control,
>   - $ ./autogen.sh
>     if such a file exists
>   - $ ./bootstrap --no-git --gnulib-srcdir=$GNULIB_SRCDIR
>     if a 'bootstrap' script exists.

Thanks! Good to know.

> * Package 'barcode': The package wants the 'free' module, but it is nowadays
>   called 'free-posix'. While the shell implementation prints a warning,
>   the Python implementation prints a stack trace and aborts.
> 
>   I think that neither of these behaviours are desirable. The best behaviour
>   would be that it prints an error message (not warning message) and 
> continues,
>   and the exit code at the end is 1.
> 
>   An error message is desirable for modes other than 'import', 'add-import',
>   'remove-import', 'update', because these gnulib-tool invocations typically
>   occur in scripts and are followed by autoconf and automake invocations.
>   A warning message is desirable in the other modes.

That makes sense to me.

>   The problem happens here:
> 
>             # Update configuration dictionary.
>             self.config.update(self.cache)     # HERE the value is set to 
> 'autotools'
>             for key in config.keys():
>                 value = config[key]
>                 if not config.isdefault(key, value):    # HERE 'build-aux' is 
> not considered to be the default
>                     self.config.update_key(config, key) # HERE 'autotools' 
> gets overwritten with 'build-aux'
> 
>   Here I would revisit the entire 'auxdir' handling.

Yes. I'll have a look at that.

I think that is from the original import of gnulib-tool.py. Since most
projects just use 'build-aux', I am not surprised it wasn't caught
until now.

Collin