[Top][All Lists]

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

Re: Checking application of dependencies from make rules without recipes

From: SF Markus Elfring
Subject: Re: Checking application of dependencies from make rules without recipes
Date: Mon, 19 Jun 2017 09:39:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

>> Does such a feedback indicate that would like to look also into the
>> corresponding development repository?
> No.  At least I don't have time to review an entire development environment.

Such a choice is also fine.

> If you post the set of rules responsible for creating those files
> in the previous makefile configuration we can probably tell
> you why they behave differently, if you don't understand it.

But I find that such general feedback indicates also one of the usual
challenges for handling advanced (free) software support.

Another code example might help to achieve a bit more progress
in the desired clarification of implementation details. But it could
have been reduced too much with the consequence to look at other
(unwanted) side effects.

> I didn't recognize any other requests for clarification among your comments.

This is a pity.

I hoped somehow that your trained eyes might spot more issues
from software design patterns around the mentioned details.

>> How much can make scripts help to manage (optional) programming
>> interface descriptions?
> Are you asking, how can a makefile represent a prerequisite which
> may be built, but is not required to be built and it's not an error
> if it cannot be built?


> I can only assume you are referring to this pattern rule:
>> %.cmo: %.ml %.cmi
>>         $(o_compilation) '$<' > $@


And the original suffix rule:

        $(OCAMLC_CMD) -c $<

> and you're saying that if the .cmi file cannot be created,
> that make should not consider this an error.

There are cases where this can and should happen.
I guess that this aspect affects an organisational issue.

> It is generally not possible to represent this behavior in makefile syntax.

I find this information only partly appropriate.

> The best you can do is remove the %.cmi from the pattern rule

This suggestion is only one possibility.

> and declare explicit prerequisite rules for those targets that you'd like to
> have a .cmi file prerequisite.

You referenced my approach for the conversion of a specific suffix rule
to a similar pattern rule.
The Coccinelle software can be successfully built by the published make scripts
with the effect of special limitations (and the usual remaining update 
I am trying to adjust some details there.

But I reached a point after some tweaks where I began to stumble on
unexpected error messages because of the published dependency specifications.
I wondered about them for a while. It took also another while until the handling
of optional software data was identified as a corresponding big factor
for the discussed use case.

It is a recurring topic to clarify circumstances under which something can be
really optional (or not).

The development status is evolving as usual also for the mentioned concrete 
Now I imagine that there is a need to decide on this design detail once more
in an automatic way. I am looking for further solutions besides the approaches
which I applied for a few subdirectories in one of my own development 

How do you think about to extend information sources like the manual section
“Generating prerequisites automatically”?


reply via email to

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