From: Paolo Bonzini <pbonzini@redhat.com>
To: Stefan Weil <sw@weilnetz.de>, Thomas Huth <thuth@redhat.com>,
Joshua Watt <jpewhacker@gmail.com>,
qemu-devel@nongnu.org
Cc: Yonggang Luo <luoyonggang@gmail.com>
Subject: Re: [PATCH] configure: Add flags for MinGW32 standalone build
Date: Mon, 11 Jan 2021 08:44:08 +0100 [thread overview]
Message-ID: <b7585238-25c7-d25f-dae1-d682dc084284@redhat.com> (raw)
In-Reply-To: <a0cbc0c3-7c5b-ed81-8cfa-2129dda6a268@weilnetz.de>
On 11/01/21 08:29, Stefan Weil wrote:
> Am 11.01.21 um 08:04 schrieb Thomas Huth:
>
>> On 08/01/2021 19.30, Joshua Watt wrote:
>>>
>>> On 1/8/21 1:25 AM, Thomas Huth wrote:
>>>> On 07/01/2021 22.38, Joshua Watt wrote:
>>>>> There are two cases that need to be accounted for when compiling QEMU
>>>>> for MinGW32:
>>>>> 1) A standalone distribution, where QEMU is self contained and
>>>>> extracted by the user, such as a user would download from the
>>>>> QEMU
>>>>> website. In this case, all of the QEMU files should be rooted in
>>>>> $prefix to ensure they can be easily packaged together for
>>>>> distribution
>>>>> 2) QEMU integrated into a distribution image/sysroot/SDK and
>>>>> distributed with other programs. In this case, the provided
>>>>> arguments for bindir/datadir/etc. should be respected as they
>>>>> for a
>>>>> Linux build.
>>>>>
>>>>> Add a configure time flags --enable-standalone-mingw and
>>>>> --disable-standalone-mingw that allows the user to control this
>>>>> behavior. The flag defaults to "enabled" if unspecified to retain the
>>>>> existing build behavior
>>>>>
>>>>> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
>>>>> ---
>>>>> configure | 8 +++++++-
>>>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/configure b/configure
>>>>> index 5860bdb77b..5c83edb502 100755
>>>>> --- a/configure
>>>>> +++ b/configure
>>>>> @@ -358,6 +358,7 @@ strip_opt="yes"
>>>>> tcg_interpreter="no"
>>>>> bigendian="no"
>>>>> mingw32="no"
>>>>> +mingw32_standalone="yes"
>>>>> gcov="no"
>>>>> EXESUF="$default_feature"
>>>>> HOST_DSOSUF=".so"
>>>>> @@ -1558,6 +1559,10 @@ for opt do
>>>>> ;;
>>>>> --disable-fuse-lseek) fuse_lseek="disabled"
>>>>> ;;
>>>>> + --enable-standalone-mingw) mingw32_standalone="yes"
>>>>> + ;;
>>>>> + --disable-standalone-mingw) mingw32_standalone="no"
>>>>> + ;;
>>>>> *)
>>>>> echo "ERROR: unknown option $opt"
>>>>> echo "Try '$0 --help' for more information"
>>>>> @@ -1570,7 +1575,7 @@ libdir="${libdir:-$prefix/lib}"
>>>>> libexecdir="${libexecdir:-$prefix/libexec}"
>>>>> includedir="${includedir:-$prefix/include}"
>>>>> -if test "$mingw32" = "yes" ; then
>>>>> +if test "$mingw32" = "yes" && test "$mingw32_standalone" = "yes";
>>>>> then
>>>>> mandir="$prefix"
>>>>> datadir="$prefix"
>>>>> docdir="$prefix"
>>>>> @@ -1897,6 +1902,7 @@ disabled with --disable-FEATURE, default is
>>>>> enabled if available
>>>>> libdaxctl libdaxctl support
>>>>> fuse FUSE block device export
>>>>> fuse-lseek SEEK_HOLE/SEEK_DATA support for FUSE exports
>>>>> + standalone-mingw Build for standalone distribution on MinGW
>>>>> NOTE: The object files are built at the place where configure
>>>>> is launched
>>>>> EOF
>>>>
>>>> I think this should maybe be done independently from MinGW, so that
>>>> it could be used on other systems, too. Thus maybe rather name the
>>>> switch "--enable-standalone-distribution" or
>>>> "--enable-standalone-installation" or something like this? On MinGW,
>>>> the value of the switch could then default to "yes" while on other
>>>> systems it would be "no" by default.
>>>
>>> We could, but I'm curious how useful that is? Does that make the
>>> option just a shorthand for "--mandir=$prefix --bindir=$prefix
>>> --datadir=$prefix etc..." for all builds?
>>
>> Yes, that would basically be a shorthand for that. Could be useful for
>> people who want to create standalone binaries on Linux etc., too.
>>
>> Thomas
>
>
> Aren't nearly all files already rooted in $prefix? The only exception I
> know is /etc/qemu.
>
> Rooting in $prefix still allows hierarchical subdirectories. I'd prefer
> them for MinGW, too.
I agree, it was an issue before 5.2 but now we have relocatable
installations. So it would be better to remove all the special casing
of mingw, except that (for backwards compatibility) on mingw bindir
defaults to $prefix instead of $prefix/bin. Then Joshua's usecase is
covered simply by --bindir=/mingw/bin.
Paolo
next prev parent reply other threads:[~2021-01-11 7:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-07 21:38 [PATCH] configure: Add flags for MinGW32 standalone build Joshua Watt
2021-01-08 7:25 ` Thomas Huth
2021-01-08 18:30 ` Joshua Watt
2021-01-11 7:04 ` Thomas Huth
2021-01-11 7:29 ` Stefan Weil
2021-01-11 7:44 ` Paolo Bonzini [this message]
2021-01-11 16:01 ` Joshua Watt
2021-01-11 17:34 ` Paolo Bonzini
2021-01-12 21:02 ` [PATCH v2] configure: MinGW respect --bindir argument Joshua Watt
2021-01-13 5:33 ` Thomas Huth
2021-01-13 10:01 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b7585238-25c7-d25f-dae1-d682dc084284@redhat.com \
--to=pbonzini@redhat.com \
--cc=jpewhacker@gmail.com \
--cc=luoyonggang@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=sw@weilnetz.de \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).