qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH] Makefile: Update unmodified config-devices.mak


From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: [PATCH] Makefile: Update unmodified config-devices.mak automatically
Date: Thu, 24 Dec 2009 17:06:12 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Thu, Dec 24, 2009 at 04:03:17PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" <address@hidden> wrote:
> > On Thu, Dec 24, 2009 at 02:31:58PM +0100, Stefan Weil wrote:
> >> Michael S. Tsirkin schrieb:
> >> > On Sun, Dec 20, 2009 at 03:39:03PM +0100, Stefan Weil wrote:
> >> >   
> >> >> This makes rebuilds after source updates easier
> >> >> for most users (who don't edit config-devices.mak).
> >> >>
> >> >> Signed-off-by: Stefan Weil <address@hidden>
> >> >>     
> >> >
> >> > Sorry about missing this and not commenting earlier.
> >> >
> >> > So the problem here is that it relies on keeping
> >> > .old file around. This is a generated file, but
> >> > - you don't remove it with make clean or distclean
> >> >   
> >> 
> >> As long as config-devices.mak is not removed,
> >> config-devices.mak.old has to be kept, too.
> >
> > Yes but you keep it around even after config-devices.mak
> > is removed.
> >
> >> > - it is not removed on error properly as it is not
> >> >   a target of makefile
> >> > so it seems easy to get into a situation where
> >> > a corrupted file will be created and the only way
> >> > to get rid of it would be by manual rm command.
> >> >   
> >> 
> >> I don't think that this is a real world scenario.
> >> The .old file is a simple copy of config-devices.mak.
> >
> > By the way, what if you really *do* want configuration that happens to
> > exactly match the default at some point?  There is no way to take that
> > config and make it persistent, is there?  With my approach, any edit of
> > the file adding something will do.
> 
> You can't make your cake and have it.
> Your include file fails exactly in this very scenary:
> 
> #include default-config
> 
> local modifications
> 
> You change default-config, and you also have a different configuration.
> 
> I don't see any advantage at using includes instead of copy the file,
> and implement include directive just make things more complex IMHO.
> 
> >> > Instead, what I think we should do is make
> >> > the generated file *almost empty*
> >> > and then it is easy to detect user tweaking
> >> > it without keeping more state.
> >> >   
> >> 
> >> This is a matter of personal preferences.
> >> Maybe other users who want to modify
> >> config-devices.mak prefer to have a full
> >> version where they can remove some lines
> >> they don't need.
> >
> > IMO this encourages sloppiness, it is better to have a file which does
> > 1. include default
> > 2. change some values
> > than have a full copy of said default and then try to figure out what
> > did you change.  If you want to look at the original, it is there.
> 
> This build system is lossely bassed on kernel config files.  And in the
> kernel, once that you have your .config, it will never be overwritten.
> 
> Both options have its advantages and disadvantages.
> 
> I am looking at this patch, and was thinking about reordering the
> comparisons, but I am still not sure that my approach is better than
> this one.  Will think a bit more about it and include this one or
> propose something similar in spirit.
> 
> Later, Juan.

IMO the really best approach is not to generate any files
at all. This way we avoid confusion: if there is config
file around, user created this file.
But I don't care much, really.

Whatever you do, please make sure that
make defconfig itself does not print "run make defconfig",
this is just silly.

-- 
MST




reply via email to

[Prev in Thread] Current Thread [Next in Thread]