public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Preudhomme <thomas.preudhomme@foss.arm.com>
To: JonY <10walls@gmail.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows
Date: Fri, 20 Jan 2017 09:06:00 -0000	[thread overview]
Message-ID: <c3a648ee-b7dc-e406-f20c-131816e5aecb@foss.arm.com> (raw)
In-Reply-To: <3c3cd900-7d38-a66d-d306-12c968d26f0b@gmail.com>

Hi JonY,

On 19/01/17 01:37, JonY wrote:
> On 01/18/2017 09:48 AM, Thomas Preudhomme wrote:
>> By default, wildcard support on Windows for programs compiled with mingw
>> depends on how the mingw runtime was configured. This means if one wants
>> to build GCC for Windows with a consistent behavior with Wildcard
>> (enabled or disabled) the mingw runtime must be built as well. This
>> patch adds an option to GCC configuration to force the behavior with
>> wildcard when building GCC for Windows host. It does so by setting the
>> _dowildcard variable in the driver to a given value depending on the
>> configure option value (yes or no), thus overriding the variable from
>> mingw runtime.
>>
>> Testing: I've successfully done a build of the arm-none-eabi cross GCC
>> for Windows with Ubuntu system mingw runtime (configured without
>> wildcard support by default) with the three configure options:
>>   1) --enable-wildcard: wildcard can be used successfully and nm of
>> driver-mingw32.o shows that _dowildcard is in .data section
>>   2) --disable-wildcard: wildcard cannot be used and nm of
>> driver-mingw32.o shows that _dowildcard is in .bss section
>>   3) no option: wildcard cannot be used and nm of driver-mingw32.o shows
>> no _dowildcard defined and all sections are empty
>>
>> Is this ok for stage1?
>>
>> Best regards,
>>
>> Thomas
>
> No objections, but documentation should mention that wildcard expansion
> is not handled by the CMD shell on Windows, it is up to individual
> programs to interpret it.

Do you mean that this configuration option should make it clear that it only 
affects wildcard expansion for GCC itself but not for programs built by GCC?

Best regards,

Thomas

  reply	other threads:[~2017-01-20  9:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18  9:49 Thomas Preudhomme
2017-01-19  2:05 ` JonY
2017-01-20  9:06   ` Thomas Preudhomme [this message]
2017-01-26 13:19   ` Thomas Preudhomme
2017-02-07  8:48     ` JonY
2017-02-14  9:46       ` Thomas Preudhomme
2017-02-14 10:58         ` JonY
2017-02-17 11:01           ` JonY
2017-02-17 11:51             ` Thomas Preudhomme
2017-02-17 23:05               ` JonY
2017-02-22 16:07                 ` Thomas Preudhomme
     [not found]                   ` <CAF1jjLtsw10najrRwzJ7MJSSKxqmX0Wy4gKyf=dhmcAebS+JOA@mail.gmail.com>
2017-03-02 16:58                     ` Thomas Preudhomme
2017-03-04 14:25                       ` [wwwdocs] gcc-8/porting_to.html (was: [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows) Gerald Pfeifer
2017-03-09 10:51                         ` [wwwdocs] gcc-8/porting_to.html Thomas Preudhomme
2017-03-09 10:59                           ` Jakub Jelinek
2017-03-09 11:22                             ` Thomas Preudhomme
2017-03-09 13:16                               ` JonY
2017-03-12 14:08                           ` Gerald Pfeifer
2017-03-12 23:51                             ` JonY
2017-03-22 17:39                               ` Thomas Preudhomme
2017-03-22 22:51                                 ` JonY
2017-03-23  6:47                                 ` Gerald Pfeifer
2017-03-23 10:47                                   ` Thomas Preudhomme
2017-05-04 11:10                                     ` JonY
2017-05-04 14:37                                       ` Thomas Preudhomme
2017-05-04 14:43                                   ` Thomas Preudhomme
2017-05-04 15:17                 ` [arm-embedded] [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows Thomas Preudhomme

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=c3a648ee-b7dc-e406-f20c-131816e5aecb@foss.arm.com \
    --to=thomas.preudhomme@foss.arm.com \
    --cc=10walls@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).