On 04/16/2010 09:51, Alexander Leidinger wrote: > Quoting Navdeep Parhar <nparhar_at_gmail.com> (from Wed, 14 Apr 2010 > 11:35:40 -0700): > >> Have you or anyone else ever used buildkernel successfully with >> "makeoptions WITH_CTF=yes" in the conf file? Something as simple as >> this does not work for me: > > Copy&paste patch, tabs probbly mangled: > ---snip--- > Index: Makefile.inc1 > =================================================================== > --- Makefile.inc1 (revision 206700) > +++ Makefile.inc1 (working copy) > _at__at_ -314,7 +314,7 _at__at_ > .endif > > # kernel stage > -KMAKEENV= ${WMAKEENV} > +KMAKEENV= ${WMAKEENV:NNO_CTF=1} > KMAKE= ${KMAKEENV} ${MAKE} KERNEL=${INSTKERNNAME} > > # > _at__at_ -780,7 +780,7 _at__at_ > _at_echo > "--------------------------------------------------------------" > cd ${KRNLOBJDIR}/${_kernel}; \ > MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \ > - ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \ > + ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS \ > -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile > # XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case. > .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && > exists(${KERNSRCDIR}/modules) > ---snip--- > > This lets the buildkernel generate ctf info in the object files (the > build is not finished yet, so I still have to verify that the final > kernel contains them too, but I do not see a reason ATM why this should > not be the case). > > If your build environment is faster (here: about an hour for the > buildkernel), can you please help testing? A buildworld with and without > WITH_CTF in src.conf, and for buildkernel the same (with and without > WITH_CTF in src.conf, and for each with and without makeoptions > WITH_CTF=yes in the kernel). The expected outcome is no CTF when no > WITH_CTF is in src.conf (except for the buildkernel with the > makeoptions), and always with CTF when WITH_CTF is in src.conf > (alternatively only CTF if makeoptions is used, but this would be > surprising for me). > > And then... NO_CTF=yes defined in src.conf and WITH_CTF too... for the > world this should not produce CTF data, but for the kernel I'm not sure > what will or should happen for the makeoptions case... > > Bye, > Alexander. > This sounds like a case of too many knobs to control whether ctfconvert will be used on any resulting object code. Couldn't this be better handled by defaulting WITH_CTF:=NO instead of having it act Boolean and set NO_CTF to 0 or 1 but rather check if we are building world or kernel by other means if the user has WITH_CTF defined somewhere else?. Or just check whether WITH_CTF is defined and enable the proper sections of the build for kernel. As I see in sys.mk: stable/7 example and not touched on HEAD. # Turn CTF conversion off by default for now. This default could be # changed later if DTrace becomes popular. .if !defined(WITH_CTF) NO_CTF = 1 .endif # C Type Format data is required for DTrace CTFFLAGS ?= -L VERSION .if !defined(NO_CTF) CTFCONVERT ?= ctfconvert CTFMERGE ?= ctfmerge .if defined(CFLAGS) && (${CFLAGS:M-g} != "") CTFFLAGS += -g .else CFLAGS += -g .endif .endif ### END OF PIECE ### Could be simplified: .if defined(WITH_CTF) CTFFLAGS ?= -L VERSION CTFCONVERT ?= ctfconvert CTFMERGE ?= ctfmerge CTFCONVERT ?= ctfconvert CTFMERGE ?= ctfmerge .if defined(CFLAGS) && (${CFLAGS:M-g} != "") CTFFLAGS += -g .else CFLAGS += -g .endif And this would leave little confusion about what is actually happening and ensure that adding something like (makeoptions -DWITH_CTF) actually work. I do not see a real need for NO_CTF if we can check to see if WITH_CTF is being defined. For the relevant sections of the tree that should never have WITH_CTF just dont add the ability to check and enable it. Or undefine it. JM2C Regards, -- jhellReceived on Mon Apr 19 2010 - 10:46:37 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:02 UTC