src/Makefile, universe, LINT, VIMAGE, ..

[Bjoern A. Zeeb]

On Mon, 26 Oct 2009, John Baldwin wrote:

Hi,

>> @@ -345,3 +333,18 @@
>>   	fi
>>   .endif
>>   .endif
>> +
>> +universe_kernels: universe_kernels_foo
>> +TARGET?=	${BUILD_ARCH}
>> +KERNCONFS!=	cd ${.CURDIR}/sys/${TARGET}/conf && \
>> +		find [A-Z0-9]*[A-Z0-9] -type f -maxdepth 0 \
>> +		! -name DEFAULTS ! -name NOTES
>> +KERNCONFS:=	${KERNCONFS}
>> +universe_kernels_foo:
>> +.for kernel in ${KERNCONFS}
>> +	@(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \
>> +	    ${MAKE} ${JFLAG} buildkernel TARGET=${TARGET} KERNCONF=${kernel} \
>> +	    > _.${TARGET}.${kernel} 2>&1 || \
>> +	    (echo "${TARGET} ${kernel} kernel failed," \
>> +	    "check _.${TARGET}.${kernel} for details"| ${MAKEFAIL}))
>> +.endfor
>
> Hmm, I'm not sure why you need a universe_kernels_foo target that
> universe_kernels depends on?

This is all about make and the variables after a target and within a
target. Whatever else I tried: make complained.  If you know the
rightbetter solution that works I'll be happy to simplify this and
update the patch.

It shouldn't be named _foo though;)


> Also, I would probably prefer to have
> universe_kernels come after universe_$target and before universe_epilogue.

I think that should be possible to sneak it in after the the .endfor.


>> Index: sys/conf/makeLINT.mk
>> ===================================================================
>> --- sys/conf/makeLINT.mk	(revision 198467)
>> +++ sys/conf/makeLINT.mk	(working copy)
>> @@ -5,7 +5,15 @@
>>
>>   clean:
>>   	rm -f LINT
>> +.if ${TARGET} == "amd64" || ${TARGET} == "i386"
>> +	rm -f LINT=VIMAGE
>> +.endif
>
> s/=/-/

Yeah, everyone notics that one; it should be fixed in the patch at the
URL originally referenced.

> BTW, I'm not sure why you would only enable VIMAGE for these two archs rather
> than doing it for all archs that have a LINT?

Because it'll usually simply not make any sense to build a VIMAGE
kernel for embedded platforms like arm, ...  Also make universe time
increases significantly with any platform; indeed amd64 is the worst
now (again).  We can talk about the proper set and I had thought of
sparc64 as well.  Obviously just building it everywhere simplifies
things.

/bz

-- 
Bjoern A. Zeeb         It will not break if you know what you are doing.