On Mon, Feb 02, 2015 at 03:01:44PM +0000, Ian Campbell wrote: > On Mon, 2015-02-02 at 12:59 +0000, Wei Liu wrote: > > Provide mini-os url and revision in Config.mk > > > > Introduce Makefile.mini-os which contains mini-os specific targets. > > I'm not sure it has enough content to warrant that, those two targets > could easily be inlined. > > > +ifeq ($(wildcard $(MINI_OS)/Config.mk),) > > +$(error Please run `make mini-os-dir' in top-level directory) > > +endif > > This makes me think that maybe my earlier suggestion to move the clone > under stubdom/ might be better done right away. > > In fact, that would avoid the need to play tricks with renaming extras/ > too, since you could build both for a commit. >
I think I made this hack not because of the location, but because I couldn't get it to clone in a sensible way without breaking stubdom build. I'm not GNU Make expert so I'm open to suggestion on this issue. So in this Makefile: 6 export stubdom=y 7 export debug=y 8 include $(XEN_ROOT)/Config.mk Line 8 includes $(XEN_ROOT)/Config.mk, which in turn includes $(MINI_OS)/Config.mk. Mini-os's Config.mk contains a bunch of flags. In GNU Make's manual: If an included makefile cannot be found in any of these directories, a warning message is generated, but it is not an immediately fatal error; processing of the makefile containing the include continues. Once it has finished reading makefiles, make will try to remake any that are out of date or don’t exist. See How Makefiles Are Remade. Only after it has tried to find a way to remake a makefile and failed, will make diagnose the missing makefile as a fatal error. So I once had something like: $(XEN_ROOT)/Config.mk: mini-os-dir Mini-os got clone and the build proceeded. But stubdom build still broke miserably, because *FLAGS in stubdom/Makefile are not reevaluated. Is there a solution to this? Wei. > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
