From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Michal Marek <mmarek@suse.cz>
Cc: nicolas.dichtel@6wind.com, Sam Ravnborg <sam@ravnborg.org>,
linux-kbuild@vger.kernel.org
Subject: Re: make headers_install fail when path is too long
Date: Thu, 7 Mar 2013 08:28:25 -0500 [thread overview]
Message-ID: <513895F9.2050900@windriver.com> (raw)
In-Reply-To: <51384F21.9070800@suse.cz>
On 13-03-07 03:26 AM, Michal Marek wrote:
> Dne 6.3.2013 17:27, Nicolas Dichtel napsal(a):
>> - $(PERL) $< $(installdir) $(SRCARCH) $(input-files); \
> [...]
>> + @echo $(input-files) > $(INSTALL_HDR_PATH)/.input-files
>
> Are you sure this is a reliable fix? What make does is to spawn
>
> /bin/sh -c 'echo <long list of files> > usr/include/.input-files'
It's what I was referencing in my original email. It works here,
and fixes our install of headers in previously failing environments.
But yes, it does shuffle the args enough to get around the limit, but
there's still a way to have even deeper and longer path names that
could cause failures.
I experimented with loops, and other options as well. But any
construct like "for f in $(input-files)", is both slow and explodes
on the argument length limits just like the original.
>
> here. So I guess that it works for you just because "sh -c" is shorter
> than "sh -c 'perl scripts/headers_install.pl...'".
Partly, yes, but we are more than a few characters over the limit
in my testing. So it shouldn't be the whole story.
Cheers,
Bruce
>
> Michal
>
next prev parent reply other threads:[~2013-03-07 13:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 11:16 make headers_install fail when path is too long Nicolas Dichtel
2013-03-06 16:10 ` Sam Ravnborg
2013-03-06 16:24 ` Michal Marek
2013-03-06 16:27 ` Nicolas Dichtel
2013-03-06 16:50 ` Bruce Ashfield
2013-03-07 8:26 ` Michal Marek
2013-03-07 13:28 ` Bruce Ashfield [this message]
2013-04-26 16:36 ` [PATCH] fix make headers_install " Nicolas Dichtel
2013-04-26 18:14 ` Bruce Ashfield
2013-04-26 18:57 ` Sam Ravnborg
2013-04-29 12:13 ` Michal Marek
2013-04-29 12:17 ` Nicolas Dichtel
2013-04-29 12:15 ` [PATCH linux-next v2] " Nicolas Dichtel
2013-04-29 12:34 ` Bruce Ashfield
2013-05-06 8:19 ` Nicolas Dichtel
2013-05-17 9:12 ` Nicolas Dichtel
2013-05-17 20:08 ` Michal Marek
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=513895F9.2050900@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=mmarek@suse.cz \
--cc=nicolas.dichtel@6wind.com \
--cc=sam@ravnborg.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.