Re: order-only prerequisites don't behave as I'd have expected after reading the documentation

[Stefano Lattarini]

Hi Paul, thanks for the quick answer.

On 06/12/2012 07:14 AM, Paul Smith wrote:
> On Mon, 2012-06-11 at 18:40 +0200, Stefano Lattarini wrote:
>> The GNU make 3.82 manual reads:
>>
>> Normally, this is exactly what you want: if a target's prerequisite
>> is updated, then the target should also be updated.
>>
>> Occasionally, however, you have a situation where you want to impose
>> a specific ordering on the rules to be invoked without forcing the
>> target to be updated if one of those rules is executed.
>>
>> But if I write a makefile like this:
>>
>> ALL = a b c d
>> default:
>>  echo Specify a target: $(ALL); exit 1
>> .PHONY: $(ALL)
>> $(ALL):
>> @echo $@
>> a: | b
>> b: | c
>> c: | d
>>
>> then I get:
>>
>> $ make a # Not what I expected, but what actually happened.
>> d
>> c
>> b
>> a
>>
>> which is not what I'd have expected reading the documentation above; what
>> I would have expected was that "a" alone would be run:
>>
>> $ make a # What I expected, but did not happen.
>> a
> 
> No, that's not how order-only prerequisites work.  An order-only
> prerequisite is treated identically to a normal prerequisite except for
> exactly one thing: when make checks to see if a target needs to be
> remade, the time-last-modified values for any order-only prerequisites
> are not considered.
>
Ah, all is clear now.  Then I think we are dealing with a documentation
bug here; in particular:

  - the name "order-only prerequisites" is IMHO poorly chosen, and don't
really correspond to their actual semantics; a more appropriate might
be "weak prerequisites" or "existence-only prerequisites";

  - the explanation given in the manual is imprecise and confusing; since
the explanation you've given here is OTOH very clear and concise, I
suggest you report it in the manual;

  - it might make sense to state explicitly that order-only prereqs
which are phony behaves in all ways like standard prerequisites.

> However, they are still considered prerequisites in that they are still
> built, themselves, if necessary, before the target.  Since your targets
> are all phony (and none of them update their target file either) they
> will all always be remade every time.  You can't see how order-only
> prerequisites work using this makefile.
> 

Thanks,
  Stefano

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: order-only prerequisites don't behave as I'd have expected after reading the documentation

[Stefano Lattarini]

On 06/12/2012 02:06 AM, Philip Guenther wrote:
> On Mon, Jun 11, 2012 at 12:53 PM, Stefano Lattarini
>  wrote:
> ...
>> I was hoping to be able to the order-only prerequisites to enforce ordering
>> between .PHONY targets.  At this point, I guess I should state the problem
>> I am trying to solve rather than just the attempts I've made at solving it.
>>
>>   Is there an easy, scalable way to specify in a GNUmakefile that, whenever
>>   two given targets T1 and T2 (either phony or not) are to be updated, T1's
>>   recipe must be executed before T2's, all without declaring any dependency
>>   of T2 on T1?  So that for example, assuming T1 and T2 are both phony:
>>
>> $ make T1 # Only run T1's recipe
>> $ make T1 # Only run T2's recipe
> 
> (I think you meant "make T2" there...)
>
Yes, sorry.

> 
>> $ make T2 T1 # Run T1's recipe, then T2's recipe
>> $ make -j8 T2 T1 # Again, run T1's recipe, then T2's recipe
> 
> I think I would use a test on $(MAKECMDGOALS) to make T1 a
> prerequisite of T2 if and only if T1 is a goal, say...
> 
>  ifneq ($(filter T1,${MAKECMDGOALS}),)
>  T2: T1
>  endif
>
Not good enough; the "order dependency" I want between T1 and T2 should
have to work also when they are updated as dependencies of other targets:

$ cat Makefile
all: T1 T2
...
$ make all # Ought to work executing T1 before T2.

Regards,
  Stefano


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #36641] Crash when using ridiculously large target names

[anonymous]

URL:
  

 Summary: Crash when using ridiculously large target names
 Project: make
Submitted by: None
Submitted on: Tue 12 Jun 2012 05:16:49 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.82
Operating System: Any
   Fixed Release: None
   Triage Status: None

___

Details:

If the stem len is bigger than PATH_MAX, it results in a buffer over run:

455a456
> unsigned int stemlen_copy;
494,495c495,497
<   strncpy (stem_str, stem, stemlen);
<   stem_str[stemlen] = '\0';
---
>   stemlen_copy = stemlen > sizeof(stem_str) ? sizeof(stem_str) :
stemlen;
>   strncpy (stem_str, stem, stemlen_copy);
>   stem_str[stemlen_copy] = '\0';





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: order-only prerequisites don't behave as I'd have expected after reading the documentation

[Philip Guenther]

On Tue, Jun 12, 2012 at 12:59 AM, Stefano Lattarini
 wrote:
> On 06/12/2012 02:06 AM, Philip Guenther wrote:
>> On Mon, Jun 11, 2012 at 12:53 PM, Stefano Lattarini
>>  wrote:
>> ...
>>> I was hoping to be able to the order-only prerequisites to enforce ordering
>>> between .PHONY targets.  At this point, I guess I should state the problem
>>> I am trying to solve rather than just the attempts I've made at solving it.
>>>
>>>   Is there an easy, scalable way to specify in a GNUmakefile that, whenever
>>>   two given targets T1 and T2 (either phony or not) are to be updated, T1's
>>>   recipe must be executed before T2's, all without declaring any dependency
>>>   of T2 on T1?  So that for example, assuming T1 and T2 are both phony:
>>>
>>>     $ make T1 # Only run T1's recipe
>>>     $ make T2 # Only run T2's recipe
>>>     $ make T2 T1 # Run T1's recipe, then T2's recipe
>>>     $ make -j8 T2 T1 # Again, run T1's recipe, then T2's recipe
>>
>> I think I would use a test on $(MAKECMDGOALS) to make T1 a
>> prerequisite of T2 if and only if T1 is a goal, say...
>>
>>      ifneq ($(filter T1,${MAKECMDGOALS}),)
>>      T2: T1
>>      endif
>>
> Not good enough; the "order dependency" I want between T1 and T2 should
> have to work also when they are updated as dependencies of other targets:
>
>    $ cat Makefile
>    all: T1 T2
>    ...
>    $ make all # Ought to work executing T1 before T2.

Given the design of make, with its lazy DAG building, what you are
asking for cannot be done automatically by make, as when it hits T2 as
a prerequisite it cannot know whether a not-yet-considered target will
end up having T1 as a prerequisite.

My gut reaction is that something in this setup is over-simplifying
things or misleading make.  If T1 needs to be done before T2 _ever_,
then why not _always_ have it as a prerequisite of T2?  Is the
.PHONYness of T1 a hack to get around some other limitation and using
some sort of timestamp file would let T1 be not-.PHONY and always be a
dependency of T2?

Whatever.  Insufficient data.  Workaround: use the MAKECMDGOALS test
previously cited but list all the targets that depend on T1 as well in
the $(filter) clause.


Philip Guenther

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #36641] Crash when using ridiculously large target names

[Rob Walker]

On 6/12/12 10:16 AM, anonymous wrote:
> URL:
>   
>
>  Summary: Crash when using ridiculously large target names
>  Project: make
> Submitted by: None
> Submitted on: Tue 12 Jun 2012 05:16:49 PM UTC
> Severity: 3 - Normal
>   Item Group: Bug
>   Status: None
>  Privacy: Public
>  Assigned to: None
>  Open/Closed: Open
>  Discussion Lock: Any
>Component Version: 3.82
> Operating System: Any
>Fixed Release: None
>Triage Status: None
>
> ___
>
> Details:
>
> If the stem len is bigger than PATH_MAX, it results in a buffer over run:
>
> 455a456
>> unsigned int stemlen_copy;
> 494,495c495,497
> <   strncpy (stem_str, stem, stemlen);
> <   stem_str[stemlen] = '\0';
> ---
>>   stemlen_copy = stemlen > sizeof(stem_str) ? sizeof(stem_str) :
> stemlen;
>>   strncpy (stem_str, stem, stemlen_copy);
>>   stem_str[stemlen_copy] = '\0';

The proposed patch has yet another buffer overrun, off by one.

-Rob


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make