From: Ian Lance Taylor <iant@google.com>
To: Joey Ye <joey.ye@arm.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch] Shorten Windows path
Date: Tue, 25 Mar 2014 13:18:00 -0000 [thread overview]
Message-ID: <CAKOQZ8wOiFwKA7BpA4bmo8HsxmWsvJY2TP8dCsJb+0nLNLKVKw@mail.gmail.com> (raw)
In-Reply-To: <000a01cf4808$67f71ce0$37e556a0$@arm.com>
On Tue, Mar 25, 2014 at 1:58 AM, Joey Ye <joey.ye@arm.com> wrote:
> Ping
This code looks different on mainline.
Writing "if ( do_canonical )" is not GCC style.
This patch does not respect the configure option
--disable-canonical-system-headers.
Also I personally don't actually know what the consequences would be.
Are there any downsides to canonicalizing header names?
Ian
>> -----Original Message-----
>> From: Joey Ye [mailto:joey.ye@arm.com]
>> Sent: 19 February 2014 15:45
>> To: gcc-patches@gcc.gnu.org; Ian Lance Taylor (iant@google.com)
>> Subject: [patch] Shorten Windows path
>>
>> Max length of path on Windows is 255, which is easy to exceed in a
>> complicated project. Ultimate solution may be complex but canonizing the
>> path and skipping the ".."s in path is helpful.
>>
>> Relative discussion in gcc-patches:
>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00582.html
>>
>> OK to trunk stage 1?
>>
>> ChangeLog.libcpp:
>> * files.c (find_file_in_dir): Always try to shorten for DOS.
>>
>> diff --git a/libcpp/files.c b/libcpp/files.c index 7e88778..9dcc71f 100644
>> --- a/libcpp/files.c
>> +++ b/libcpp/files.c
>> @@ -386,9 +386,18 @@ find_file_in_dir (cpp_reader *pfile, _cpp_file *file,
>> bool *invalid_pch)
>> hashval_t hv;
>> char *copy;
>> void **pp;
>> + bool do_canonical;
>>
>> +#ifdef HAVE_DOS_BASED_FILE_SYSTEM
>> + /* For DOS based file system, we always try to shorten file path
>> + * to as it has a shorter constraint on max path length. */
>> + do_canonical = true;
>> +#else
>> /* We try to canonicalize system headers. */
>> - if (CPP_OPTION (pfile, canonical_system_headers) &&
> file->dir->sysp)
>> + do_canonical = (CPP_OPTION (pfile, canonical_system_headers)
>> + && file->dir->sysp); #endif
>> + if ( do_canonical )
>> {
>> char * canonical_path = maybe_shorter_path (path);
>> if (canonical_path)
>
>
next prev parent reply other threads:[~2014-03-25 13:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-25 9:06 Joey Ye
2014-03-25 13:18 ` Ian Lance Taylor [this message]
2014-04-01 10:17 ` Joey Ye
2014-06-04 18:45 ` Meador Inge
2014-04-25 10:28 ` Joey Ye
2014-04-25 13:58 ` Ian Lance Taylor
2014-05-09 6:30 ` Jeff Law
-- strict thread matches above, loose matches on Subject: below --
2014-02-19 7:45 Joey Ye
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=CAKOQZ8wOiFwKA7BpA4bmo8HsxmWsvJY2TP8dCsJb+0nLNLKVKw@mail.gmail.com \
--to=iant@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=joey.ye@arm.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 read-only IMAP folder(s) and NNTP newsgroup(s).