tech-toolchain archive

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

Re: Make and makefile bugs (PRs 49085, 49086, 49087)



On Mon, Aug 18, 2014 at 06:51:19PM +0200, Antoine LECA wrote:
> The point was, we are already in grey territory (that is, outside of
> POSIX compliance); since there is a known-to-be-better solution
> (patterns) for the long term, perhaps it would be a better idea to not
> loose too much time on awkward cases like .a.b suffixes?

Ok, my bad.  I should've said it earlier: changing it to parse so that
the user has a choice is a trivial change and would actually simplify
the code.

Now it needs to ignore a suffix which matches the whole target name on
the first pass through the suffixes (actually remember it to make
the second pass unnecessary), just in case a later, shorter suffix
would give us a double suffix rule.  If the user choice is allowed,
that would be unnecessary.

> Furthermore, I am not yet convinced (particularly after a quick review
> of the code, where I can spot a number of strrchr() calls) that it deals
> "correctly" with .a.b (or more likely, .tar.gz) suffixes in any cases of
> uses of implicit rules.

The only strrchr(str, '.') calls are in parse.c (related to include
files) and in var.c (related to :E and :R variable modifiers).
And having worked on the suff.c module now quite a bit, I'm quite 
certain the implicit rule part would work.

But yeah, those /other/ places do handle suffixes inconsistently, if
compared to the suff.c module.  That is, the transformation rule
processing will consider "foo.tar.gz" to have ".tar.gz" suffix if
properly configured, but those other places will treat it as having
".gz".

> Also, I only mentioned <slash> because Posix does (as does my own
> parsing code), and it was easier to copy-and-paste :-) Please drop it.

Sorry, I don't understand.  Please drop what?

But yeah, handling or non-handling of <slash> has no relevance here.
I just commented that slash-is-not-allowed is not enforced in any way
in our implementation. :)  If someone tries to do such a silly thing,
make won't stop them.  (Perhaps it should?)

-- 
Jarmo Jaakkola


Home | Main Index | Thread Index | Old Index