Re: keep on patchin'

Hi Jim,
  For your library check, would the following change do what you need?

+ check-lib: clean
+       $(MAKE) CFLAGS=-DITEMTABLE_DEBUG
+       $(top_builddir)/proc/test_Itemtables
+

If you do make check-lib it cleans everything runs make again with the flag
and then your test program. I'm actually thinking you could cut down what
was being made here too as you only need the library and the single test
program.

Not sure why you need the -i switch, I don't get this exp error you are
talking about. What's it giving you without -i ?

 - Craig


On Wed, 26 Aug 2020 at 05:21, Jim Warner <[email protected]> wrote:

> On 8/25/20 3:17 AM, Craig Small wrote:
> > I have included one example. Let me know what you think
>
> Hi Craig,
>
> That was a solution I wouldn't have thought of.  And since 6 separate
> programs would be required (to avoid duplicate Item_table errors) a
> complete verification would be performed rather than bailing on the
> first module in error.
>
> However, it would make a bit of a mess in the proc/ directory when the
> chances of **any** Item_table error is small.  And including a .c source
> file in such a manner would have to be kept as a closely held secret.
>
> Anyway, attached is a tarball with 4 patches for newlib.  The first two
> are silly cosmetic changes.  The third is a desirable change somewhat
> related to ITEMTABLE_DEBUG.
>
> The fourth patch is an alternative build-sys solution.  I have no idea
> how many automake conventions I may have violated in that patch but, it
> seems to do the trick on my system.  And someday we may choose to expand
> that EXTRA_DEBUG variable to also include the XTRA_PROCPS_DEBUG #define.
>
> To review, I'd like patches 0001-0003 for sure pushed to newlib.  But
> patch 0004 is yours to consider as an alternative to the original 6
> separate program approach.
>
> Regards,
>
> Jim
>
> p.s. It sure would be nice if we could omit the '-i' switch (due to the
> 'exp' error) from 'make check' and 'make distcheck'.
>