Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1450257 > unrolled thread

Re: [PATCH 1/1 linux-next] kbuild: add make force=1 for testing

Started byAndrew Morton <akpm@linux-foundation.org>
First post2016-07-26 02:10 +0200
Last post2016-07-27 16:40 +0200
Articles 4 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 1/1 linux-next] kbuild: add make force=1 for testing Andrew Morton <akpm@linux-foundation.org> - 2016-07-26 02:10 +0200
    Re: [PATCH 1/1 linux-next] kbuild: add make force=1 for testing Robert Jarzmik <robert.jarzmik@free.fr> - 2016-07-26 08:50 +0200
    Re: [PATCH 1/1 linux-next] kbuild: add make force=1 for testing Michal Marek <mmarek@suse.com> - 2016-07-26 23:50 +0200
      Re: [PATCH 1/1 linux-next] kbuild: add make force=1 for testing Fabian Frederick <fabf@skynet.be> - 2016-07-27 16:40 +0200

#1450257 — Re: [PATCH 1/1 linux-next] kbuild: add make force=1 for testing

FromAndrew Morton <akpm@linux-foundation.org>
Date2016-07-26 02:10 +0200
SubjectRe: [PATCH 1/1 linux-next] kbuild: add make force=1 for testing
Message-ID<rYY6B-3fZ-5@gated-at.bofh.it>
On Sun, 24 Jul 2016 15:28:18 +0200 Fabian Frederick <fabf@skynet.be> wrote:

> Commit 51193b76bfff
> ("kbuild: forbid kernel directory to contain spaces and colons")
> 
> makes it impossible to build kernel on default SD labels like
> "SD Card" for instance.
> 
> Makefile:133: *** main directory cannot contain spaces nor colons.  Stop.
> 
> User could rename directories but volume name is not always writable.
> 
> This patch adds ability to do make force=1 for people
> not interested in modules_install in this case but only testing.
> 
> (Note that other options could go under ifndef force)

That's a bit of a hack on a hack.

51193b76bfff said:

:    When the kernel path contains a space or a colon somewhere in the path
:    name, the modules_install target doesn't work anymore, as the path names
:    are not enclosed in double quotes. It is also supposed that and O= build
:    will suffer from the same weakness as modules_install.
:    
:    Instead of checking and improving kbuild to resist to directories
:    including these characters, error out early to prevent any build if the
:    kernel's main directory contains a space.

What's involved in fixing this properly?  Make the whole kbuild
system operate correctly when there are spaces/colons in the
pathname?

[toc] | [next] | [standalone]


#1450413

FromRobert Jarzmik <robert.jarzmik@free.fr>
Date2016-07-26 08:50 +0200
Message-ID<rZ4lI-744-11@gated-at.bofh.it>
In reply to#1450257
Andrew Morton <akpm@linux-foundation.org> writes:

> On Sun, 24 Jul 2016 15:28:18 +0200 Fabian Frederick <fabf@skynet.be> wrote:
>
>> Commit 51193b76bfff
>> ("kbuild: forbid kernel directory to contain spaces and colons")
>> 
>> makes it impossible to build kernel on default SD labels like
>> "SD Card" for instance.
>> 
>> Makefile:133: *** main directory cannot contain spaces nor colons.  Stop.
>> 
>> User could rename directories but volume name is not always writable.
>> 
>> This patch adds ability to do make force=1 for people
>> not interested in modules_install in this case but only testing.
>> 
>> (Note that other options could go under ifndef force)
>
> That's a bit of a hack on a hack.
>
> 51193b76bfff said:
>
> :    When the kernel path contains a space or a colon somewhere in the path
> :    name, the modules_install target doesn't work anymore, as the path names
> :    are not enclosed in double quotes. It is also supposed that and O= build
> :    will suffer from the same weakness as modules_install.
> :    
> :    Instead of checking and improving kbuild to resist to directories
> :    including these characters, error out early to prevent any build if the
> :    kernel's main directory contains a space.
>
> What's involved in fixing this properly?  Make the whole kbuild
> system operate correctly when there are spaces/colons in the
> pathname?

I was thinking originally fixing it by :
	http://www.spinics.net/lists/linux-kbuild/msg12036.html

This fixed "properly" the make modules_install I think.
And Marek pointed out that there were other cases, such as O=/my dir/ but not
limited to, where it would also break, hence this patch.

I'm not a kbuild expert so I'd like someone else (Marek) to enumerate the
remaining cases not covered by the original patch.

Cheers.

-- 
Robert

[toc] | [prev] | [next] | [standalone]


#1450934

FromMichal Marek <mmarek@suse.com>
Date2016-07-26 23:50 +0200
Message-ID<rZioG-7lp-17@gated-at.bofh.it>
In reply to#1450257
Dne 26.7.2016 v 02:05 Andrew Morton napsal(a):
> On Sun, 24 Jul 2016 15:28:18 +0200 Fabian Frederick <fabf@skynet.be> wrote:
>> This patch adds ability to do make force=1 for people
>> not interested in modules_install in this case but only testing.
>>
>> (Note that other options could go under ifndef force)
> 
> That's a bit of a hack on a hack.

Agreed.


> 51193b76bfff said:
> 
> :    When the kernel path contains a space or a colon somewhere in the path
> :    name, the modules_install target doesn't work anymore, as the path names
> :    are not enclosed in double quotes. It is also supposed that and O= build
> :    will suffer from the same weakness as modules_install.
> :    
> :    Instead of checking and improving kbuild to resist to directories
> :    including these characters, error out early to prevent any build if the
> :    kernel's main directory contains a space.
> 
> What's involved in fixing this properly?  Make the whole kbuild
> system operate correctly when there are spaces/colons in the
> pathname?

modules_install probably could be fixed. However, O= builds are
definitely unfixable: We use -I$(srctree)/... in various *FLAGS
variables, which are space-separated lists. We assign $(srctree) to
VPATH, which is a colon-separated list. Also, we pass $(srctree)/... to
the wildcard, addprefix or patsubst functions, which take a
space-separated list of words. The Makefile language simply does does
not give us tools to handle special characters properly.

To work around such paths, I suggest to create a symlink and use that.
As far as I can tell, we do not call readlink/realpath in the buildsystem.

Michal

[toc] | [prev] | [next] | [standalone]


#1451309

FromFabian Frederick <fabf@skynet.be>
Date2016-07-27 16:40 +0200
Message-ID<rZya5-Bn-5@gated-at.bofh.it>
In reply to#1450934

> On 26 July 2016 at 23:47 Michal Marek <mmarek@suse.com> wrote:
>
>
> Dne 26.7.2016 v 02:05 Andrew Morton napsal(a):
> > On Sun, 24 Jul 2016 15:28:18 +0200 Fabian Frederick <fabf@skynet.be> wrote:
> >> This patch adds ability to do make force=1 for people
> >> not interested in modules_install in this case but only testing.
> >>
> >> (Note that other options could go under ifndef force)
> >
> > That's a bit of a hack on a hack.
>
> Agreed.
>
>
> > 51193b76bfff said:
> >
> > :    When the kernel path contains a space or a colon somewhere in the path
> > :    name, the modules_install target doesn't work anymore, as the path
> > names
> > :    are not enclosed in double quotes. It is also supposed that and O=
> > build
> > :    will suffer from the same weakness as modules_install.
> > :   
> > :    Instead of checking and improving kbuild to resist to directories
> > :    including these characters, error out early to prevent any build if the
> > :    kernel's main directory contains a space.
> >
> > What's involved in fixing this properly?  Make the whole kbuild
> > system operate correctly when there are spaces/colons in the
> > pathname?
>
> modules_install probably could be fixed. However, O= builds are
> definitely unfixable: We use -I$(srctree)/... in various *FLAGS
> variables, which are space-separated lists. We assign $(srctree) to
> VPATH, which is a colon-separated list. Also, we pass $(srctree)/... to
> the wildcard, addprefix or patsubst functions, which take a
> space-separated list of words. The Makefile language simply does does
> not give us tools to handle special characters properly.
>
> To work around such paths, I suggest to create a symlink and use that.
> As far as I can tell, we do not call readlink/realpath in the buildsystem.

This was the first thing I tried but make still doesn't work.

Fabian

>
> Michal

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web