lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Best way to integrate PCRE


From: Greg Chicares
Subject: Re: [lmi] Best way to integrate PCRE
Date: Fri, 17 Sep 2021 22:14:17 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 9/11/21 1:27 PM, Vadim Zeitlin wrote:
[...]
> On Wed, 8 Sep 2021 23:16:05 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:

[...always override $LMI_TRIPLET for 'make check_concinnity', i.e.:

- make $coefficiency check_concinnity 2>&1 |less -S -N
+ make LMI_TRIPLET=x86_64-pc-linux-gnu $coefficiency check_concinnity 2>&1 
|less -S -N

so that an ELF binary is always used regardless of the global $LMI_TRIPLET,
because this is only a development tool and we develop on GNU/Linux only...]

>  I don't mind the solution below,

["below" now also means "as paraphrased above"]

> of course, but I'm perfectly fine with
> this one too and I think it is simpler because it doesn't require modifying
> hooks/pre-commit and nychthemeral_test.sh that would need to be updated to
> set LMI_TRIPLET=x86_64-pc-linux-gnu otherwise.
> 
>  So for now I've implemented this by simply setting LMI_TRIPLET in
> custom_tools target itself.

That's cleverer and more tasteful than my suggestion.

> The only thing I've changed compared to above
> is that I'm using host_xxx variables rather than arch-independent ones
> because this better describes them. I hope the use of "host" and "target"
> terms is acceptable, as they're standard in the context of discussing
> cross-compiling, but they could be changed if you prefer something else, of
> course.

Okay. We already use 'host' elsewhere, e.g., in 'install_wx.sh':

config_options="
[...]
  --build=$build_type
  --host=$LMI_TRIPLET

>  I.e. the rule now looks like this:
> 
> ---------------------------------- >8 --------------------------------------
> custom_tools:
>       @$(MAKE) LMI_TRIPLET=$(host_triplet) test_coding_rules
>       @$(INSTALL) -c -m 0775 $(TEST_CODING_RULES) $(host_localbindir)
> ---------------------------------- >8 --------------------------------------
> 
> with the host_xxx variables having the expected values.

Sounds good. Then we'd just set
  host_triplet := x86_64-pc-linux-gnu
once and only once, perhaps a line or two above the 'custom_tools' target.

> GC> Can we conclude now that we'd both be satisfied if I replaced my
> GC> habitual command:
> GC>   make $coefficiency check_concinnity 2>&1 |less -S -N
> GC> with this:
> GC>   make LMI_TRIPLET=x86_64-pc-linux-gnu $coefficiency check_concinnity 
> 2>&1 |less -S -N
> GC> instead? If that works, then perhaps it's ideal, as it would seem
> GC> to require no other change anywhere (except, I guess, in the
> GC> hooks that invoke that command).
[...that's the idea I paraphrased above...]
> 
>  To confirm once again, I would, of course, be satisfied by this, but it
> just seems to impose an unnecessary extra burden on you, when it doesn't
> seem to cost anything to add this override to the makefile itself.

Yes, your way seems better, thanks.

> GC> > if it's simpler for you, perhaps I could
> GC> > submit the patch in the current state, with concinnity test not working
> GC> > under MSW?
> GC> 
> GC> That sounds okay. But now I'll have only forty hours to test it,
> GC> which probably won't be enough because I need to prepare for my
> GC> next distraction.
> 
>  I hope this distraction is already in the past by now, but I'll check for
> your acknowledgement that you have enough time to review this patch before
> finally submitting it.

I'm fully recovered now, and passed today's follow-up examination
with flying colors. But I'm taking next week as vacation to
recuperate from the recovery, and to process the last of our
collective's tomato crop. Kosi, kosa, poka rosa. If you want to
submit it now, I'll take a look. Tolstoy could spend all day in
the fields with his scythe and then come home and write those
books, so there's no reason I can't do this.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]