[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection
On Fri, Apr 17, 2020 at 03:39:48PM +0200, Jan Beulich wrote: > On 17.04.2020 15:19, Anthony PERARD wrote: > > Or do you mean keeping exception to the rule? And hope that when someone > > changes the rule, it doesn't forget to check if the exception needs > > changing as well? > > ... "exception" like you put it (requiring special care to keep > multiple instances in sync) is not the only way this can be done > (and indeed I'd not want something like this). Since you have > (in patch 15) e.g. > > guest_walk_%.o: guest_walk.c FORCE > $(call if_changed_rule,cc_o_c) > > anyway, the desire to skip the objcopy step could be communicated > to the command from here, without needing to clone the command. > One way might be a special (phony) dependency, another might be to > set some variable along the lines of > > guest_walk_%.o: SPECIAL := y I guess something like that could be done. But if possible, I'd like to avoid that. > > Also, I'm going to have to use this patch later anyway as sometime CC > > use a full path to the source as file symbol. So this is going to be > > important when we will run for example > > `clang -o arch/x86/mm/guest_walk_2.o arch/x86/mm/guest_walk.c`. > > (There isn't a patch for that yet.) > > That's interesting - what will be the goal of that future adjustment? It's a step toward my goal of been able to have out-of-tree build for xen, as stated in my cover letter. In order to do that, I try to adapt Kbuild to build Xen. Kbuild is building the linux kernel without changing directory, so I'd like to do the same, as it probably makes it easier to do out-of-tree build. Another tool I'd like to use from Kbuild is ./fixdep, it's a small program that run after running CC and fix the dependency file that CC generates. The main thing it does is to add a dependency on Kconfig options that a source file uses instead of having a dependency on whether any unrelated Kconfig has change at all. But ./fixdep from Linux only works if we build without changing directory. ([1] for more on fixdep) I guess one advantage of never changing directory is that we can always use relative path in global *FLAGS. There isn't a need to use absolute path, which is an issue when the source tree is moved to a different location. That can easily happen when for example you try to build in a container (mapping the source tree inside it) then try to rebuild from outside. (After using automation/scripts/containerize for example.) And we don't need tricks like the .*.d2 files (which isn't needed in the hypervisor anyway, so far at least). [1], copied from Linux's scripts/basic/fixdep.c introduction: If the user re-runs make *config, autoconf.h will be regenerated. make notices that and will rebuild every file which includes autoconf.h, i.e. basically all files. This is extremely annoying if the user just changed CONFIG_HIS_DRIVER from n to m. So we play the same trick that "mkdep" played before. We replace the dependency on autoconf.h by a dependency on every config option which is mentioned in any of the listed prerequisites. kconfig populates a tree in include/config/ with an empty file for each config symbol and when the configuration is updated the files representing changed config options are touched which then let make pick up the changes and the files that use the config symbols are rebuilt. So if the user changes his CONFIG_HIS_DRIVER option, only the objects which depend on "include/config/his/driver.h" will be rebuilt, so most likely only his driver ;-) -- Anthony PERARD
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |