Re: bmake bug with expanding pattern macro replacements

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 02 May 2020 14:19:19 +0200
    From:        (Joerg Schilling) <schily%schily.net@localhost>
    Message-ID:  <20200502121919.C02t7%schily%schily.net@localhost>

  | I never had the need to do this [...]

I didn't ask whether you had ever needed to do it, I asked how you
would if you did need to,   Earlier you claimed:

	Do you believe you need a better method since the standard
	method only works in 100% of the cases?

(from: Message-id: <20200427124442.ArfNW%schily%schily.net@localhost>)

and:
	The feature is well designed, but gmake does not implement it correctly.

(from: Message-id: <20200428114601.IBh31%schily%schily.net@localhost>)

If this feature is well designed, and works in 100% of the cases, it
must be able to work, somehow, to solve the request I posed, mustn't it?

How?

  | Regarding your proposal [...]

I made no proposal.   If I had it would be for this archaic mechanism
to be deleted completely.

What I did was used a notation that I assumed (and I think probably
correctly) would allow you to understand the requirement,  That was
all that was - I don't care what actual notation needs be used to
achieve the expected result, as long as there exists some notation
which does that.

Since 100% of cases work, and the feature is well designed, you will
have no problem explaining (demonstrating) how to do it, will you?

Most of the rest of your message I will ignore, as it seems to be
devoted to arguing against a proposal I never made.

  | > I don't know the procedures for exporting the NetBSD make into bmake
  | > so I cannot help with that.
  |
  | This is bad.

It is bad that I (personally) have no idea how bmake gets new releases
made?   That's unfortunate, as let me assure you there are huge numbers
of things about which I have no knowledge whatever.   Catastrophe!

Earlier (not in a message on this list) I told you who I believe you could
contact about this, they are probably reading all this and (wisely) staying
silent.

  | If I cannot test, it makes no sense for me to spend more effort 
  | in bmake,

Somehow, I think the world would carry on just fine.

  | SunPro make is no more proprietary than GNU make or BSD make and you should 
  | know that, since proprietary in not the contrary of opensource but marks 
  | something that is different from the rest.

This is not the place for debates on correct English usage, but
proprietary means "owned by someone" (as in "private").   It doesn't
mean "different".

Anyone is free to do just about whatever they like with bmake, and if
you're willing to live with the GPL, with gmake - neither is proprietary
code.  SunPro make might no be any more either (and I believe that smake
is not), but in 1986 it certainly was.  So was UNOS and everything related
to it (perhaps still is).

kre