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

Bjoern A. Zeeb bz at FreeBSD.org
Wed Jun 10 11:30:12 UTC 2009


On Wed, 10 Jun 2009, Ariff Abdullah wrote:

> On Wed, 10 Jun 2009 10:24:46 +0000 (UTC)
> "Bjoern A. Zeeb" <bz at FreeBSD.org> wrote:
>> On Wed, 10 Jun 2009, Bjoern A. Zeeb wrote:
>>
>>> 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
>>
>> I forgot to mention that the way we currently seem to handle this
>> is:
>>
>> http://people.freebsd.org/~bz/20090610-02-sound-Makefile.diff
>>
>
> More or less like:
>
> http://people.freebsd.org/~ariff/sound_Makefile.diff

just seen it on current at .


> Please test it.

Mine worked for me and that's consistent with what we do in
sys/modules/svr4/Makefile and sys/modules/linux/Makefile .

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


More information about the svn-src-head mailing list