Does "makeoptions WITH_CTF=yes" actually work?

[jhell]

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)
> @@ -314,7 +314,7 @@
>  .endif
> 
>  # kernel stage
> -KMAKEENV=      ${WMAKEENV}
> +KMAKEENV=      ${WMAKEENV:NNO_CTF=1}
>  KMAKE=         ${KMAKEENV} ${MAKE} KERNEL=${INSTKERNNAME}
> 
>  #
> @@ -780,7 +780,7 @@
>         @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,

-- 

 jhell