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

Re: [XEN PATCH v2 4/5] build: evaluate XEN_BUILD_* and XEN_DOMAIN on first use


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Date: Thu, 27 Jul 2023 10:15:53 +0100
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Jason Andryuk <jandryuk@xxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, "Julien Grall" <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 27 Jul 2023 09:16:10 +0000
  • Ironport-data: A9a23:n2P0jqJOnQugFi9DFE+RAJUlxSXFcZb7ZxGr2PjKsXjdYENS3mAFm mAeWGuHO/2CZ2f3eo8ibYy29BtX6JTXzdRhSQRlqX01Q3x08seUXt7xwmUcnc+xBpaaEB84t ZV2hv3odp1coqr0/0/1WlTZhSAgk/rOHvykU7Ss1hlZHWdMUD0mhQ9oh9k3i4tphcnRKw6Ws Jb5rta31GWNglaYCUpKrfrawP9TlK6q4mhA4QZhPakjUGL2zBH5MrpOfcldEFOgKmVkNrbSb /rOyri/4lTY838FYj9yuu+mGqGiaue60Tmm0hK6aYD76vRxjnVaPpIAHOgdcS9qZwChxLid/ jnvWauYEm/FNoWU8AgUvoIx/ytWZcWq85efSZSzXFD6I+QrvBIAzt03ZHzaM7H09c5tKm5kq PUmEgxSZw+KpcCJkO2rELZz05FLwMnDZOvzu1llxDDdS/0nXYrCU+PB4towMDUY354UW6yEP oxANGQpNU6bC/FMEg5/5JYWleG0hn75YntApUicv6Yf6GnP1g1hlrPqNbI5f/TTHJsOxxzJ+ ziuE2LRQQAoC9mZ0za/wHO8uujQzB7afaxILejtnhJtqALKnTFCYPEMbnO5q/Skjk+1W/pEN lcZvCEpqMAa9kWtQsPsQh6Qr3uNvxpaUN1Ve8U49QWMx6z88wufQG8eQVZpc8c6vcU7QTgr0 F6hnN7zAzFr9rqPRhq16bO8vT60fy8PIgcqdSICCAcI/dTniIUylQ7UCMZuFravid/4Ei22x CqFxAA3n7gJhNQH/7m691vAxTmro/D0ohUdv1uNGDj/t0UgOdDjPtbzgbTG0RpeBJyyQXPct UY+p5eX8+ksL67dyzzXH/pYSdlF+M253C3gbU9HRsdwr2/8oC77Iei88xkleh43b59slSvBJ RaK5FgPvMI70G6CN/cfXm6nNyg9IUEM//zBX+ucUNdBa4MZmOSvrHA3Ph74M4wAfSERfUAD1 XSzK5zE4Y4yU/gP8dZPb751PUUX7i4/33jPYpvw0g6q17GTDFbMF+ZdawrQNL9ot/vbyOkwz zq5H5HUo/m4eLSgChQ7DKZJdQxaRZTFLc6eRzNrmh6rfVM9RTBJ5w75yrI9YY1195m5Zc+Rl kxRrnRwkQKl7VWecFXiV5yWQO+3NXqJhS5hbHNE0JfB8yRLXLtDG49GKMBsIOh4rLc4pRO2J tFcE/i97j10Ymyv01wggVPV9eSOqDzDadqyAheY
  • Ironport-hdrordr: A9a23:FNrn+6yhh3TK8eZ3XRgRKrPxU+skLtp133Aq2lEZdPWaSL3iqy nOpoVr6faQslwssR4b6La90cW7MArhHNtOkPQs1NSZLXfbURWTXftfBOLZqlWKJ8S9zJ8g6U 4KSdkANDSfNykDsS842mWFOudl7t+A/qWlwc/a1HtkQBEvQ7pr7gdnBgvzKCxLbTgDK5w+Gp +RouJDvDapdGRSRt+wB3kbU+WGicbMiIujQRNuPX4aAcu14A+A2frVFR6X2xtbfjVEhZcumF K18DDR1+GMtfe0zxOZ82PI9ZxZlJ/c0d4rPr3otiHYEFrRozftSoJmVbiP+A01u+2m5RILnb D30nUdFvU2xXXWcGS45SbtwAXp3XIT8HqK8y79vVLT5eL+Qjw+B45+iYkcWB7Y50081esMt5 6jFlj2i6Zq
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Jun 23, 2023 at 10:07:02AM +0200, Jan Beulich wrote:
> On 22.06.2023 17:30, Anthony PERARD wrote:
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -11,10 +11,10 @@ export XEN_FULLVERSION   = 
> > $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
> >  -include xen-version
> >  
> >  export XEN_WHOAMI  ?= $(USER)
> > -export XEN_DOMAIN  ?= $(shell ([ -x /bin/dnsdomainname ] && 
> > /bin/dnsdomainname) || ([ -x /bin/domainname ] && /bin/domainname || echo 
> > [unknown]))
> > -export XEN_BUILD_DATE      ?= $(shell LC_ALL=C date)
> > -export XEN_BUILD_TIME      ?= $(shell LC_ALL=C date +%T)
> > -export XEN_BUILD_HOST      ?= $(shell hostname)
> > +export XEN_DOMAIN  ?= $(eval XEN_DOMAIN := $(shell ([ -x 
> > /bin/dnsdomainname ] && /bin/dnsdomainname) || ([ -x /bin/domainname ] && 
> > /bin/domainname || echo [unknown])))$(XEN_DOMAIN)
> > +export XEN_BUILD_DATE      ?= $(eval XEN_BUILD_DATE := $(shell LC_ALL=C 
> > date))$(XEN_BUILD_DATE)
> > +export XEN_BUILD_TIME      ?= $(eval XEN_BUILD_TIME := $(shell LC_ALL=C 
> > date +%T))$(XEN_BUILD_TIME)
> > +export XEN_BUILD_HOST      ?= $(eval XEN_BUILD_HOST := $(shell 
> > hostname))$(XEN_BUILD_HOST)
> 
> Interesting approach. It looks like it should be independent of make's
> internal workings, but I still wonder: Is this documented somewhere,
> so we won't be caught by surprise of it not working anymore because of
> some change to make's internals?

So, this is a makefile trick that I've seen on someone's blog post.

But I tried to find evidence in the GNU make manual if variable expansion is
expected to work like that, and I can't. So I can imagine one day make
doing expansion of variable in parallel, or were the result of the eval
would happen only on the next line. So I don't know if this approach is
always going to work.

Maybe we could go for a safer alternative:

Simply replacing ?= by something actually documented in the manual, and
then replacing = by := .

    ifeq ($(origin XEN_BUILD_DATE), undefined)
    export XEN_BUILD_DATE := $(shell LC_ALL=C date)
    endif

An alternative, with a macro could be:

    set-shell-if-undef = $(if $(filter undefined,$(origin $(1))),$(eval $(1) := 
$(shell $(2))))

    $(call set-shell-if-undef,XEN_BUILD_DATE,LC_ALL=C date)
    export XEN_BUILD_DATE

But this kind of hide that a shell command is been called. But having
$(shell) as parameter of call $(call) mean the shell command is always
called even when unneeded.

But then, with the macro, I'm not sure where to put it, to be able to
use it here and in Config.mk for the next patch, another file in
xen.git/config/*.mk ?

Should I replace all the eval with "ifeq (); endif" ?

Thanks,

-- 
Anthony PERARD



 


Rackspace

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