Re: GNU make 4.2.90 release candidate available

[Dennis Clarke]

On 8/27/19 1:46 PM, Paul Smith wrote:
> Sorry, I didn't mean you needed to explain all these options to me :).

I was being overly Canadian and trying to apologize for weird things in
my setup and then trying to use "rubber ducky" debugging to explain to
myself why I was doing this.

> In particular I was wondering about the CPPFLAGS, because attempting to
> add reserved preprocessor options to the compile line can cause
> problems in system header files.  Also, by adding a new include
> directory to search, there could be files in that include directory
> which overlap with/conflict with headers that are expected by make
> and/or the operating system.

I tossed out the CPPFLAGS entirely.

Also the entire directory structure /opt/bw is empty other than the
build stuff and the src stuff. Well it *was* empty as I re-built make
version 4.2.1 and installed it into /opt/bw/bin as gmake.  I does
pass the testsuite.

> In my work doing system/embedded/cross-compilation systems I've seen
> MANY cases where these sorts of options cause strange and unexpected
> behavior.

A good reason for me to toss them.  For now.


> Note, make is not multithreaded so options that manage pthread etc. are
> not relevant to it (but shouldn't hurt either).
>
> If the /opt/dw directory is empty then clearly that's not a problem.

Shouldn't be.


> Given that we're seeing a lot of strange and unexpected behavior I just
> thought it might be helpful to remove all the customizations and start
> with a "clean slate" to get a baseline.


   * agree *   which is why I went to /opt/bw or /opt/foo or whatever.

> If you're confident that's not necessary, that's fine too.
>
> >   > If it chooses the one that comes with GNU make, you will see the error
> >   > (!!) because our glob/fnmatch is too old. >
> >
> > How do we force the usage of the system version ?
>
> I'm not sure there's any way to do that... well, you can pre-seed the
> config cache but it's gross.  But, all the GNU/Linux ones I looked at
> seemed to be using the system libc anyway so I don't think it's an
> issue.

Well today has been better with both Debian stable x86_64 passing all
tests and now Debian sid on i686 32-bit as well.  I am using the patches
from Paul Eggert and trying again on Solaris 10 sparc.

Not sure if I am helping here or just spinning cycles but at the very
least I have an assortment of hardware and OS types on hand to do the
testing with.

Dennis