Re: gnulib-tool.py: Fix removal of variables from GLMakefileTable.

[Collin Funk]

Hi Bruno,

On 3/28/24 4:05 PM, Bruno Haible wrote:
> Since the program uses a mix between OOP and functional style, it is
> reasonable to think about whether a certain data path is better implemented
> through OOP (with an object holding a private sub-object) or better done
> in a functional style (by passing function parameters).
> 
> When doing so, two considerations should be evaluated:
>   1) Is the sub-object really private?
>   2) Do the sub-objects need to be shared? I.e. is it OK to have multiple
>      instances? Or is it better to have one instance only?

Thanks for all of the feedback and explanations.

I agree with your points. Most of this was caused by a
misunderstanding that I had. For some reason I was under the
impression that the makefiletable would have to be returned.

I was not a fan of adding another value to the left side of this
assignment:

    emit, uses_subdirs = self.emitter.lib_Makefile_am(basename, ...)

This is not necessary since the '.pop()' function modifies the list
contained in the GLMakefileTable. In any case, we removed uses_subdirs
so I would have much less of a problem with it.

As far as the class relationships go, I sort of overlooked those
lines. They seem to be good indications that a mode, such as in
GLImport, might want to change Makefile variables independent of
GLEmiter. Therefore, keeping it as it is would be the correct
decision.

> That is, I would prefer to revert that part, and keep the GLMakefileTable
> as an explicit argument.

I've attached an updated patch.

Collin

0001-gnulib-tool.py-Fix-removal-of-variables-from-GLMakef.patch
Description: Text Data