* Officially vetted programming languages
@ 2016-07-25 13:11 Alexey Dobriyan
2016-07-26 20:39 ` Michal Marek
2016-07-26 20:46 ` Jim Davis
0 siblings, 2 replies; 6+ messages in thread
From: Alexey Dobriyan @ 2016-07-25 13:11 UTC (permalink / raw)
To: linux-kbuild
Do I understand correctly that POSIX sh and GNU make are
the only acceptable languages in kernel build
(ignoring optional scripts)?
Alexey
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Officially vetted programming languages 2016-07-25 13:11 Officially vetted programming languages Alexey Dobriyan @ 2016-07-26 20:39 ` Michal Marek 2016-07-26 20:46 ` Jim Davis 1 sibling, 0 replies; 6+ messages in thread From: Michal Marek @ 2016-07-26 20:39 UTC (permalink / raw) To: Alexey Dobriyan; +Cc: linux-kbuild Dne 25.7.2016 v 15:11 Alexey Dobriyan napsal(a): > Do I understand correctly that POSIX sh and GNU make are > the only acceptable languages in kernel build Also sed, awk and bc. Perl is required to some extent (by headers_install and some arch drivers). Plus ia64 has a python script. But you would need to provide a compelling reason for introducing another build dependency. Michal ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Officially vetted programming languages 2016-07-25 13:11 Officially vetted programming languages Alexey Dobriyan 2016-07-26 20:39 ` Michal Marek @ 2016-07-26 20:46 ` Jim Davis 2016-07-26 23:15 ` Randy Dunlap 1 sibling, 1 reply; 6+ messages in thread From: Jim Davis @ 2016-07-26 20:46 UTC (permalink / raw) To: Alexey Dobriyan; +Cc: linux-kbuild On Mon, Jul 25, 2016 at 6:11 AM, Alexey Dobriyan <adobriyan@gmail.com> wrote: > Do I understand correctly that POSIX sh and GNU make are > the only acceptable languages in kernel build > (ignoring optional scripts)? Well, Documentation/Changes mandates using GNU make (version 3.80 or later, though 3.80 doesn't seem to work building the 4.6.4 version of the kernel). I don't know of a similar mandate for the shell; in practice (as enshrined in the top level Makefile) it's /bin/bash, which is kind of sort of POSIX-y, except when it isn't. The README file says Linux "aims towards POSIX and Single UNIX Specification compliance", which does at least suggest staying within POSIX features of the shell. Though POSIX shell compliance isn't always easy to sort out, as the examples at https://stackoverflow.com/questions/11376975/is-there-a-minimally-posix-2-compliant-shell illustrate. I've tried building defconfigs with alternate, POSIX-y shells: /bin/dash worked, /bin/posh didn't, and going for broke by setting POSIXLY_CORRECT=1 unraveled big time in a bc script in kernel/time. -- Jim ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Officially vetted programming languages 2016-07-26 20:46 ` Jim Davis @ 2016-07-26 23:15 ` Randy Dunlap 2016-07-26 23:50 ` Jim Davis 0 siblings, 1 reply; 6+ messages in thread From: Randy Dunlap @ 2016-07-26 23:15 UTC (permalink / raw) To: Jim Davis, Alexey Dobriyan; +Cc: linux-kbuild On 07/26/16 13:46, Jim Davis wrote: > On Mon, Jul 25, 2016 at 6:11 AM, Alexey Dobriyan <adobriyan@gmail.com> wrote: >> Do I understand correctly that POSIX sh and GNU make are >> the only acceptable languages in kernel build >> (ignoring optional scripts)? python is used in several optional areas (perf, gdb, some random scripts). > Well, Documentation/Changes mandates using GNU make (version 3.80 or > later, though 3.80 doesn't seem to work building the 4.6.4 version of > the kernel). I don't know of a similar mandate for the shell; in > practice (as enshrined in the top level Makefile) it's /bin/bash, > which is kind of sort of POSIX-y, except when it isn't. I don't see "/bin/bash". Where is that? > The README file says Linux "aims towards POSIX and Single UNIX > Specification compliance", which does at least suggest staying within > POSIX features of the shell. Though POSIX shell compliance isn't > always easy to sort out, as the examples at > https://stackoverflow.com/questions/11376975/is-there-a-minimally-posix-2-compliant-shell > illustrate. We have merged Many patches for POSIX behavior in the past years. I would expect that to continue. > I've tried building defconfigs with alternate, POSIX-y shells: > /bin/dash worked, /bin/posh didn't, and going for broke by setting > POSIXLY_CORRECT=1 unraveled big time in a bc script in kernel/time. > -- ~Randy ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Officially vetted programming languages 2016-07-26 23:15 ` Randy Dunlap @ 2016-07-26 23:50 ` Jim Davis 2016-07-27 0:00 ` Randy Dunlap 0 siblings, 1 reply; 6+ messages in thread From: Jim Davis @ 2016-07-26 23:50 UTC (permalink / raw) To: Randy Dunlap; +Cc: Alexey Dobriyan, linux-kbuild On Tue, Jul 26, 2016 at 4:15 PM, Randy Dunlap <rdunlap@infradead.org> wrote: > On 07/26/16 13:46, Jim Davis wrote: >> On Mon, Jul 25, 2016 at 6:11 AM, Alexey Dobriyan <adobriyan@gmail.com> wrote: >>> Do I understand correctly that POSIX sh and GNU make are >>> the only acceptable languages in kernel build >>> (ignoring optional scripts)? > > python is used in several optional areas (perf, gdb, some random scripts). > >> Well, Documentation/Changes mandates using GNU make (version 3.80 or >> later, though 3.80 doesn't seem to work building the 4.6.4 version of >> the kernel). I don't know of a similar mandate for the shell; in >> practice (as enshrined in the top level Makefile) it's /bin/bash, >> which is kind of sort of POSIX-y, except when it isn't. > > I don't see "/bin/bash". Where is that? I was thinking of this snippet from the top level Makefile # SHELL used by kbuild CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ else if [ -x /bin/bash ]; then echo /bin/bash; \ else echo sh; fi ; fi) Speaking of POSIX compliance, I thought I'd been able to use /bin/dash for a defconfig build on my desktop, but checking again, make -f ./scripts/Makefile.build obj=arch/x86/entry/syscalls all /bin/dash './arch/x86/entry/syscalls/syscalltbl.sh' arch/x86/entry/syscalls/syscall_32.tbl arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h ./arch/x86/entry/syscalls/syscalltbl.sh: 48: [: I386: unexpected operator ./arch/x86/entry/syscalls/syscalltbl.sh: 53: [: I386: unexpected operator ./arch/x86/entry/syscalls/syscalltbl.sh: 58: [: I386: unexpected operator which points to if [ "$abi" == "COMMON" -o "$abi" == "64" ]; then and it seems the test operator should use "=" instead of "==" for POSIX compliance. -- Jim ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Officially vetted programming languages 2016-07-26 23:50 ` Jim Davis @ 2016-07-27 0:00 ` Randy Dunlap 0 siblings, 0 replies; 6+ messages in thread From: Randy Dunlap @ 2016-07-27 0:00 UTC (permalink / raw) To: Jim Davis; +Cc: Alexey Dobriyan, linux-kbuild On 07/26/16 16:50, Jim Davis wrote: > On Tue, Jul 26, 2016 at 4:15 PM, Randy Dunlap <rdunlap@infradead.org> wrote: >> On 07/26/16 13:46, Jim Davis wrote: >>> On Mon, Jul 25, 2016 at 6:11 AM, Alexey Dobriyan <adobriyan@gmail.com> wrote: >>>> Do I understand correctly that POSIX sh and GNU make are >>>> the only acceptable languages in kernel build >>>> (ignoring optional scripts)? >> >> python is used in several optional areas (perf, gdb, some random scripts). >> >>> Well, Documentation/Changes mandates using GNU make (version 3.80 or >>> later, though 3.80 doesn't seem to work building the 4.6.4 version of >>> the kernel). I don't know of a similar mandate for the shell; in >>> practice (as enshrined in the top level Makefile) it's /bin/bash, >>> which is kind of sort of POSIX-y, except when it isn't. >> >> I don't see "/bin/bash". Where is that? > > I was thinking of this snippet from the top level Makefile > > # SHELL used by kbuild > CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \ > else if [ -x /bin/bash ]; then echo /bin/bash; \ > else echo sh; fi ; fi) Thanks. > Speaking of POSIX compliance, I thought I'd been able to use > /bin/dash for a defconfig build on my desktop, but checking again, We have fixed it several times for dash and should do so again. > make -f ./scripts/Makefile.build obj=arch/x86/entry/syscalls all > /bin/dash './arch/x86/entry/syscalls/syscalltbl.sh' > arch/x86/entry/syscalls/syscall_32.tbl > arch/x86/entry/syscalls/../../include/generated/asm/syscalls_32.h > ./arch/x86/entry/syscalls/syscalltbl.sh: 48: [: I386: unexpected operator > ./arch/x86/entry/syscalls/syscalltbl.sh: 53: [: I386: unexpected operator > ./arch/x86/entry/syscalls/syscalltbl.sh: 58: [: I386: unexpected operator > > which points to > > if [ "$abi" == "COMMON" -o "$abi" == "64" ]; then > > and it seems the test operator should use "=" instead of "==" for > POSIX compliance. > Patch? -- ~Randy ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-07-27 0:01 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-07-25 13:11 Officially vetted programming languages Alexey Dobriyan 2016-07-26 20:39 ` Michal Marek 2016-07-26 20:46 ` Jim Davis 2016-07-26 23:15 ` Randy Dunlap 2016-07-26 23:50 ` Jim Davis 2016-07-27 0:00 ` Randy Dunlap
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.