[Top][All Lists]

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

Re: [Qemu-devel] [PULL v2 for-2.8 0/9] tcg queued patches

From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PULL v2 for-2.8 0/9] tcg queued patches
Date: Tue, 1 Nov 2016 17:43:37 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

On Tue, Nov 01, 2016 at 04:26:57PM +0000, Peter Maydell wrote:
> On 1 November 2016 at 16:20, Daniel P. Berrange <address@hidden> wrote:
> > On Tue, Nov 01, 2016 at 09:34:24AM -0600, Richard Henderson wrote:
> >> On 11/01/2016 06:07 AM, Richard Henderson wrote:
> >> > V2, now with more windows workarounds.  I'll note that I have not
> >> > been 100% successful in actually building a mingw64 image.  But
> >> > at least the error Peter saw with v1 is fixed.
> >> >
> >> > I'll report on the other mingw64 failures under separate cover.
> >>
> >> Bah.  I think I've been tripped up by the fact that we fail to preserve
> >> PKG_CONFIG_PATH when re-running configure via make.  We really should
> >> finally fix that -- it's really really annoying when building a non-default
> >> config.
> >
> > I sent a fix for this issue last year, but it never got picked up
> > by anyone for merge
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg04074.html
> Hmm, that's a lot of random environment variables.
> I think I prefer the approach of "if you care about anything
> in the environment, pass it to both configure and to make".
> For instance we don't pass PATH from configure to make, so
> with that patch we would have the opposite behaviour, that
> make can run configure (which will get the saved PATH from
> config.status) but then make itself runs with a different PATH.
> That seems awkwardly inconsistent.

Yeah, it is akward - I was coming at it from an autotools perspective
where the generated Makefile tends to get variables added for each
tool used, containing the fully qualified path. eg so 'make' ends
up running '/usr/bin/sed' instead of just 'sed', and so 'make' is
not dependant on stuff in your env like $PATH - it mostly honours the
env that was set at time of configure.

Of course QEMU is not using autotools, so this doesn't map exactly
hence the inconsistency you point out.

Personally the idea that you must explicitly pass the same environment
to both configure & make is kind of hard to guarantee - I'll have
many terminal windows open when working on QEMU and I can't have any
confidence that the env seen by 'make' will exactly match what I used
with 'configure' (which may have been run quite some time earlier - hours
or even days).

It was a particular pain-point for me when doing mingw builds, where
I would typically use 'PKG_CONFIG_PATH=/blah ./configure' so that I
didn't permanently pollute my shell with mingw32 pkg-config env

|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

reply via email to

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