kmod.mk - modules build framework [was: svn commit: r193818 - head/sys/modules/sound/sound]

Bjoern A. Zeeb bz at FreeBSD.org
Wed Jun 10 10:20:10 UTC 2009


On Wed, 10 Jun 2009, Bruce Evans wrote:

> On Tue, 9 Jun 2009, Bjoern A. Zeeb wrote:
>
>> On Tue, 9 Jun 2009, Bjoern A. Zeeb wrote:
>>> Log:
>>>  Depend on @ machine (_ILINKS) as we do with other modules so that @
>>>  is there for parallel (-jN) builds.  Ideally beforedepends in kmod.mk
>>>  should do the right thing but it seems it does not.
>> 
>> Anyone with lots of build framework know how may want to look at this.
>
> Failures only for parallel builds normally mean missing dependencies.
>
>>> -feeder_eq_gen.h:
>>> +feeder_eq_gen.h:	@ machine
>>> 	${AWK} -f @/tools/feeder_eq_mkfilter.awk -- ${FEEDER_EQ_PRESETS} > 
>>> ${.TARGET}
>
> Here there is still a missing dependency on the
> @/tools/feeder_eq_mkfilter.awk (fixed in the next commit).  This dependency
> is not very important, but since the utility has "@" in its pathname,
> running it certainly depends on "@".

And adding it again messes with @ not being there for parallel
builds:(

Or in other words:

===> sound (depend)
===> sound/sound (depend)
make: don't know how to make @/tools/sound/feeder_eq_mkfilter.awk. Stop
*** Error code 2
1 error
*** Error code 2
1 error
*** Error code 2



> This missing dependency seems to be a general bug.  There is an ordering
> requirement that beforedepend is before built before ${DEPENDFILE},
> but this apparently doesn't extend to ${DEPENDFILE}'s prerequisites,
> and I don't know of any general way to make it do so and it probably
> shouldn't do so in general (some of the prerequisites might be needed
> before beforedepend).

Well no; that should not be the case. I would say that would be a bug
as beforedepnd only adds the @ and machine symlinks to my memory from
reading the other day.


All after all that's why I said this needs someone with the devotion
to sort all this out, know what the right way to do things is, have
the time, ..

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.


More information about the svn-src-all mailing list