qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/3] add --confdir option to configure


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 0/3] add --confdir option to configure
Date: Mon, 19 Mar 2012 11:25:08 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 03/19/2012 11:03 AM, Eric Blake wrote:
On 03/19/2012 09:43 AM, Eduardo Habkost wrote:
A --package-name option could be provided to make it easier to override
all the defaults at the same time, but I don't see why not include an
option to define the full path for confdir, just like we allow for
datadir, docdir, and mandir.

No, I'm not suggesting --package-name, I'm suggesting that qemu-kvm
would carry a patch to configure that changed a fixed PACKAGE_NAME
define.

Actually, the idea of an explicit --package-name is not that bad: the
upstream automake list recently had a discussion on whether it should be
possible to alter the PACKAGE_NAME at configure or even make time, and
the conclusion was that it might be a useful idea, but we'd need to
pursue getting the GNU Coding Standards, autoconf, and automake all
updated to make it a reality, as it is not necessarily a trivial task
from the outset.

https://lists.gnu.org/archive/html/automake/2012-02/msg00034.html

That's interesting, thanks for point it out.

But I think for qemu, we should stick to not making PACKAGE_NAME configurable.

I would hope that qemu-kvm would stop being packaged separate from qemu in most distributions in the not so distance future.

Regards,

Anthony Liguori


If you suggest making it configurable using a variable on the 'make'
command-line it would be OK, but I kind of hoped that no modern software
project would ever require packagers to use configure-by-sed methods to
set build parameters.

Obviously, since qemu doesn't use automake, we aren't quite in the same
position as that automake thread; and even though we are not bound by
GNU Coding Standards, it might be interesting to see what happens on
that front, to make sure we are not proposing an incompatible solution.





reply via email to

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