[PATCH] Headers for the x86 subtree

[John Baldwin]

On Thursday, October 28, 2010 1:32:23 pm Warner Losh wrote:
>   On 10/28/2010 10:49, John Baldwin wrote:
> > On Thursday, October 28, 2010 11:58:25 am Warner Losh wrote:
> >>    On 10/28/2010 08:53, TAKAHASHI Yoshihiro wrote:
> >>> In article<201010281013.03261.jhb at freebsd.org>
> >>> John Baldwin<jhb at freebsd.org>   writes:
> >>>
> >>>> I'm still doing testing, but this seems to be working so far.  I am
> >>>> moving mca.h as my current test.
> >>> sys/conf/kmod.mk requires the same change of sys/conf/kern.post.mk.
> >> I think that the pre-patch kern.post.mk code actually may be wrong...
> >> Or not so much wrong as redundant with what config(8) already does.
> >> IIRC, it was put in there as a stop-gap compatibility thing and it can
> >> now actually be removed (although it makes things nicer for John's patch).
> > Err, I'd rather remove the code from config?  config can't handle the kmod.mk
> > and include/Makefile cases and it is easier to verify the logic is identical
> > for the three cases if all three are done in Makefiles rather than having two
> > of them done via Makefiles and one done via config.
> Yea, the current behavior in config is to match NetBSD's approach (both 
> at the time years ago, and now)
> > Honestly, I also prefer that we do kernel build stuff in the Makefiles rather
> > than config when possible since config is much more of a black box.  Putting
> > things in config is also a bit more fragile.
> Config knows things that the make system might not know.  It has been 
> used to create the proper environment to build in.  That's its job.
> 
> Having said that, we can have config just export that information when 
> generating its Makefiles.  It dates from a time when it was difficult to 
> do things in a Makefile, so it makes sense to reevaluate what we're 
> doing with config.
> 
> One example: We should have it set MACHINE and MACHINE_ARCH in the 
> generated Makefile.  We've hacked things to include and/or rely on them 
> being set, but right now have them in the Makefiles.  This isn't quite 
> right anymore, so moving the code into config to export this 
> information, and moving things out of config like the symbolic links 
> makes sense.  But we'll need to bump the config version to do this 
> properly since there's compatibility issues if we're not careful...

It turns out our Makefiles were already fixed by ru@ to handle this properly
and config already exports the path to the source directory in the generated
Makefile.  ru@ had planned on removing the code to generate symlinks from
config but didn't do it.  My makefile changes to generate the x86 link worked
fine with buildkernel (using config -d) even though config was not patched to
create the link because of ru@'s changes.  I'm going to test just removing the
changes from config altogether.

-- 
John Baldwin