Re: [lmi] Best way to integrate PCRE

[Greg Chicares]

On 9/30/21 12:50 PM, Vadim Zeitlin wrote:
[...big snip...] 
>  So the first question for me is whether we want to fix wrong xml_libraries
> definition. I think it would be preferable, but I certainly won't insist on
> doing it if you don't think it's worth it.

Yes, we should do this, and I'm almost ready to commit a set of changes
that will fix it.

>  The second question is whether we it is fine to use recursively-expanded
> variables or if we want to avoid this. As explained above, I'd rather try
> to avoid them but, again, if you think it's not worth it, using them is
> probably the simplest solution to write (although I'd still argue that it's
> not the simplest one to read and understand and debug later).

Where simply-expanded variables work, they're preferable.

Where they don't, we must consider what contortions would be required
to make them work. I just posted this:
  https://lists.nongnu.org/archive/html/lmi/2021-09/msg00010.html
which is a case in point. To make that work with a simply-expanded
target-specific variable in 'objects.make', we'd need to make a
pretty big change somewhere. Perhaps the smallest such change would
be to move the definition of $(xml_libraries) to a higher-level
makefile--e.g., from 'workhorse.make' to 'GNUmakefile'. I'm not
really motivated to do that. Linking $(xml_libraries) into every
binary is really bad. It is significantly less bad to specify
which binaries need it, even at the cost of specifying that with
a recursively-expanded target-specific variable.

>  Final question is whether I should make the changes -- based on your
> answers to the questions above -- or if you will just make them in master
> yourself and then I could rebase use-pcre branch on the latest master to
> ensure that physical closure check works for all commits?

I plan to do it, after my dentist appointment this morning.