Sorry if my first response was pedantic; reply inline.
>>> usr/src/Makefile:
>>> - Won't this cause stand to build twice on sparc (once as a dependency
>>> of psm and once because it's listed in sparc_SUBDIRS)? The second time
>>> should be a nop, but still unnecessary, right?
>>
>> No. We were previously relying on the implicit behavior of dmake to
>> evaluate dependencies in the specified order, but we were listing psm in
>> both sparc_ and i386_ subdirs to get the order correct.
>
> Right. I understand why the previous approach was wrong.
>
>>
>> Specifying the dependency makes that explicit, and will work correctly
>> even if SUBDIRS are built in parallel. But the rule for the stand
>> target will only be executed once.
>
> Yes, I see why you need psm to depend on stand. Why do you also need
> stand (again) in sparc_SUBDIRS?
Ah. Strictly speaking, you don't. I guess usr/src/lib/Makefile was
sticking in my head as a good role model here, where the complete list
of subdirs is specified, and then their interdependencies called out
separately.
> Are you saying that psm is not strictly needed in sparc_SUBDIRS, but
> it's not wrong because dmake (and any other make variant someone uses)
> will keep track of the fact that it has already done a make in psm when
> it sees that dependency for the second time?
Per above question ("Why do you also need stand..."), I'm agreeing that
stand (not psm) is not strictly needed in sparc_SUBDIRS.
>>> usr/src/pkg/Makefile:
>>> - What's the advantage of having install depend on $(ALL_TARGETS)
>>> instead of all?
>>
>> In this case, none, really. In general, targets that don't correspond
>> to actual files will be rebuilt when they don't exist. So if you had
>>
>> all: dep1
>> fu
>>
>> installA: dep1
>> bar
>>
>> installB: all
>> whee
>>
>> and you did "make all," then a subsequent "make installA" would execute
>> only "bar," but a "make installB" would execute "fu" and "whee."
>>
>> That's a longwinded way to say "trying to practice good makefile
>> hygiene, even when it doesn't actually make a difference."
>>
>
> Yes, I realize it would make a difference if the all target had commands
> associated with it (fu in the example above). In this case there are no
> commands for the all target.
>
> I always thought using the target name (all, in this case) was the best
> practice in cases like this. But I'll defer to your Makefile experience
> if you think this represents better hygiene.
I don't know if we have best practices; I pity the diligent engineer
that attempts to derive them from our set of makefiles. I completely
acknowledge that there's no advantage in this case, and call it style or
personal preference.
Thank you for looking at the changes.
--Mark
_______________________________________________
tools-discuss mailing list
[email protected]
