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

Re: [Xen-devel] [PATCH] build: Conditional build/clean/distclean targets on subsystems



On 05/03/2013 10:53 AM, Ian Campbell wrote:

> On Fri, 2013-05-03 at 09:43 +0100, Ian Campbell wrote:
>> On Fri, 2013-05-03 at 08:15 +0100, Jan Beulich wrote:
>>>>>> On 03.05.13 at 01:17, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
>>>> The commit 3378685 "Add conditional build of subsystems to configure.ac"
>>>> allows the user to disable/enable some components of Xen. After this commit
>>>> some targets are still called on every subsystems.
>>>
>>> For build this is correct to do, but for any clean target it isn't - clean
>>> should remove leftovers from earlier builds even if there was an
>>> intermediate reconfigure.
>>
>> Yes, I think so too.
>>
>>>> For Xen on ARM, the makefile targets build, clean and distclean will 
>>>> failed.
>>>
>>> If they fail, this will need fixing elsewhere then.
>>
>> Part of the issue is that there are targets which are simply not ported
>> to  ARM and therefore are missing bits of infrastructure , e.g. mini-os
>> where one if the clean failures is lack of
>> extras/mini-os/arch/arm/arch.mk.
>>
>> However I think it is wrong to tie the clean/distclean of these into the
>> configurey selection mechanism, i.e. mini-os should know that it only
>> support x86 (for the minute) and DTRT when called for ARM (which is
>> likely to be nothing much). Perhaps a stub
>> extras/mini-os/arch/arm/arch.mk is the answer?
>>
>> The other case is the kernel distclean, which fails with 
>>         buildconfigs/mk.linux-2.6-common:32: buildconfigs/src.: No such file 
>> or directory
>> but that seems to fail on x86 too. Having disabled it by default so long
>> ago perhaps the time has come to simply remove this stuff? I don't know
>> if anyone is still using it -- the test system perhaps?
>>
>> Or it could be fixed with the below, I think.
>>
>> Ian.
>>
>> 8<---------------------
>>
>> build: fix kernel build rules.
>>
>> Rename mk.linux-2.6-common to common.linux-2.6 so that it does not get
>> included in the ALLKERNELS logic.
>>
>> Specify XEN_LINUX_SOURCE for linux-2.6-native, looking at 414614d84e67
>> and todays linux-2.6-xen.mk I am guessing that hg-clone of the 2.6.18
>> tree is the expected method. To be honest I didn't even try it...
>>
>> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>> ---
>> NB git diff -M style diff, includes the rename...
>>
>>  .../{mk.linux-2.6-common => common.linux-2.6}      |    0
>>  buildconfigs/mk.linux-2.6                          |    2 +-
>>  buildconfigs/mk.linux-2.6-native                   |    3 ++-
>>  buildconfigs/mk.linux-2.6-pvops                    |    2 +-
>>  buildconfigs/mk.linux-2.6-tip-latest               |    2 +-
>>  buildconfigs/mk.linux-2.6-xen                      |    2 +-
>>  6 files changed, 6 insertions(+), 5 deletions(-)
> 
> Ahem....
> 
> 8<----------------
> 
> diff --git a/buildconfigs/mk.linux-2.6-common b/buildconfigs/common.linux-2.6
> similarity index 100%
> rename from buildconfigs/mk.linux-2.6-common
> rename to buildconfigs/common.linux-2.6
> diff --git a/buildconfigs/mk.linux-2.6 b/buildconfigs/mk.linux-2.6
> index 6b8d989..6523afb 100644
> --- a/buildconfigs/mk.linux-2.6
> +++ b/buildconfigs/mk.linux-2.6
> @@ -7,4 +7,4 @@ XEN_LINUX_CONFIG_UPDATE := buildconfigs/enable-xen-config
>  
>  EXTRAVERSION ?=
>  
> -include buildconfigs/mk.linux-2.6-common
> +include buildconfigs/common.linux-2.6
> diff --git a/buildconfigs/mk.linux-2.6-native 
> b/buildconfigs/mk.linux-2.6-native
> index c7c0949..6e2a77b 100644
> --- a/buildconfigs/mk.linux-2.6-native
> +++ b/buildconfigs/mk.linux-2.6-native
> @@ -1,5 +1,7 @@
>  EXTRAVERSION = -native
>  IMAGE_TARGET = bzImage
>  INSTALL_BOOT_PATH = $(DESTDIR)/boot
> +LINUX_VER    ?= 2.6.18
> +XEN_LINUX_SOURCE ?= hg-clone
>  
> -include buildconfigs/mk.linux-2.6-common
> +include buildconfigs/common.linux-2.6
> diff --git a/buildconfigs/mk.linux-2.6-pvops b/buildconfigs/mk.linux-2.6-pvops
> index 59cae79..9a11c7d 100644
> --- a/buildconfigs/mk.linux-2.6-pvops
> +++ b/buildconfigs/mk.linux-2.6-pvops
> @@ -14,4 +14,4 @@ XEN_LINUX_GIT_REMOTEBRANCH ?= xen/stable-2.6.32.x
>  
>  EXTRAVERSION ?=
>  
> -include buildconfigs/mk.linux-2.6-common
> +include buildconfigs/common.linux-2.6
> diff --git a/buildconfigs/mk.linux-2.6-tip-latest 
> b/buildconfigs/mk.linux-2.6-tip-latest
> index 2a0b9af..158dda0 100644
> --- a/buildconfigs/mk.linux-2.6-tip-latest
> +++ b/buildconfigs/mk.linux-2.6-tip-latest
> @@ -14,4 +14,4 @@ XEN_LINUX_GIT_REMOTEBRANCH ?= auto-latest
>  
>  EXTRAVERSION ?=
>  
> -include buildconfigs/mk.linux-2.6-common
> +include buildconfigs/common.linux-2.6
> diff --git a/buildconfigs/mk.linux-2.6-xen b/buildconfigs/mk.linux-2.6-xen
> index 8594b55..b1facb6 100644
> --- a/buildconfigs/mk.linux-2.6-xen
> +++ b/buildconfigs/mk.linux-2.6-xen
> @@ -3,4 +3,4 @@ LINUX_VER    ?= 2.6.18
>  
>  XEN_LINUX_SOURCE ?= hg-clone
>  
> -include buildconfigs/mk.linux-2.6-common
> +include buildconfigs/common.linux-2.6


Hum in fact, it seems the build target doesn't work because

make[3]: Leaving directory `/local/scratch/julieng/xen-unstable/xen/arch/arm'
gzip -f -9 < /local/scratch/julieng/xen-unstable/xen/xen > 
/local/scratch/julieng/xen-unstable/xen/xen.gz.new
mv /local/scratch/julieng/xen-unstable/xen/xen.gz.new 
/local/scratch/julieng/xen-unstable/xen/xen.gz
make[2]: Leaving directory `/local/scratch/julieng/xen-unstable/xen'
make[1]: Leaving directory `/local/scratch/julieng/xen-unstable/xen'
make -C tools build
make[1]: Entering directory `/local/scratch/julieng/xen-unstable/tools'
make[1]: *** No rule to make target `build'.  Stop.
make[1]: Leaving directory `/local/scratch/julieng/xen-unstable/tools'
make: *** [build] Error 2

The target build is missing in tools build. So I guess nobody use it now.
Is it possible to remove this target?

-- 
Julien

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.