Re: [lmi] Best way to integrate PCRE

[Vadim Zeitlin]

On Thu, 30 Sep 2021 13:22:01 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 9/30/21 12:50 PM, Vadim Zeitlin wrote:
GC> [...big snip...] 
GC> >  So the first question for me is whether we want to fix wrong 
xml_libraries
GC> > definition. I think it would be preferable, but I certainly won't insist 
on
GC> > doing it if you don't think it's worth it.
GC> 
GC> Yes, we should do this, and I'm almost ready to commit a set of changes
GC> that will fix it.

 This answers all my questions, so all I have to say is "thank you" and
that I will rebase my branch on top of it (and enable running physical
closure check when building for MSW in the CI builds, as I've missed this
problem because it was disabled there due to me mistakenly deciding that it
was enough to check physical closure only for the Linux builds) when it is
pushed.

GC> >  The second question is whether we it is fine to use recursively-expanded
GC> > variables or if we want to avoid this. As explained above, I'd rather try
GC> > to avoid them but, again, if you think it's not worth it, using them is
GC> > probably the simplest solution to write (although I'd still argue that 
it's
GC> > not the simplest one to read and understand and debug later).
GC> 
GC> Where simply-expanded variables work, they're preferable.
GC> 
GC> Where they don't, we must consider what contortions would be required
GC> to make them work. I just posted this:
GC>   https://lists.nongnu.org/archive/html/lmi/2021-09/msg00010.html
GC> which is a case in point. To make that work with a simply-expanded
GC> target-specific variable in 'objects.make', we'd need to make a
GC> pretty big change somewhere. Perhaps the smallest such change would
GC> be to move the definition of $(xml_libraries) to a higher-level
GC> makefile--e.g., from 'workhorse.make' to 'GNUmakefile'. I'm not
GC> really motivated to do that. Linking $(xml_libraries) into every
GC> binary is really bad. It is significantly less bad to specify
GC> which binaries need it, even at the cost of specifying that with
GC> a recursively-expanded target-specific variable.

 I'm definitely glad we're not going to link everything with libxml2, I
always found this a bit ugly (admittedly, I'm guilty of making everything
link with libpcre2-8 in my patch, which is not better -- but then we
already do it with libdw and libunwind and I didn't want to diverge from
the existing practice). I just wasn't sure if you also wanted to
future-proof this by making it possible to link with it when building for
the non-current triplet, but I definitely don't think it's really crucial
and so I won't continue in my attempts to fix this.

 Just for the record, if we ever need to return to this problem later, I
think that other than using recursively-expanded variables, defining
functions (i.e. variables invokable with $(call)) might be a slightly
better way to handle this problem: instead of ensuring that the variables
are defined in the right order, we'd just call the flags function passing
it the appropriate triplet.

GC> >  Final question is whether I should make the changes -- based on your
GC> > answers to the questions above -- or if you will just make them in master
GC> > yourself and then I could rebase use-pcre branch on the latest master to
GC> > ensure that physical closure check works for all commits?
GC> 
GC> I plan to do it, after my dentist appointment this morning.

 Thanks again and please accept my traditional good luck wishes for your
appointment!
VZ

pgpUOyhb8BKWT.pgp
Description: PGP signature