Subject: Re: Problems with system makefiles and optimization flags
To: Frederick Bruckman <>
From: Jaromir Dolecek <>
List: tech-toolchain
Date: 11/07/2002 17:14:24

.ifndef DESTDIR

in /etc/mk.conf perhaps?

Frederick Bruckman wrote:
> On Thu, 7 Nov 2002, Andrew Brown wrote:
> > >>        2. The kernel and userland Makefiles now use completely
> > >>           different variables for holding the optimization flags.
> > >
> > >Currently, if I set "COPTS" to apply a sub-model optimization to the
> > >userland binaries, it also applies to the GENERIC and INSTALL kernels
> > >and the ramdisk, which is undesirable, and usually breaks the release.
> > >Is there (will there) be a way to do that?
> >
> > yes.  i have a small patch to config(8) that simply sets
> > KERNEL_BUILD=<CONFIGNAME> at the top of the kernel makefile.  that
> > means you can (or will soon be able to) define things in your mk.conf
> > that only apply to kernels.
> That would almost work, though it would be awkward to turn it around,
> but what about the ramdisks?
> I realize there's a limit as to how much variation we support, but I
> think it's reasonable to want to build sets with, say, -march=i486, or
> -m68020-60, just to see what it does. The ramdisks and kernels, on the
> other hand, seem to already be carefully tuned, and shouldn't be
> messed with. For custom kernels, I think it makes more sense to set
> "makeoptions=COPTS=-O2 -msomething" in the kernel's config, since
> you're going to want to comment out Mxxxxx options there anyhow. That
> neatly overrides conditionally (globally) set COPTS in "/etc/mk.conf"
> or COPTS set in the environment. The problem is that globally set
> COPTS leaks into sysinstall, and the GENERIC and INSTALL kernels,
> because they don't override it.
> Frederick

Jaromir Dolecek <>  
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-