[U-Boot] Python subprocess module missing in multiconfig.py
Hello. I read the posts a couple days ago about the Python issues with Kconfig feature. I didn't see a resolution on how this would be fixed. I am running Ubuntu 14.04LTS, building u-boot and the problem I have is that the eldk tools have a older python (2.7.3) which does not have the subprocess module but the current Ubuntu python (2.7.6) does include the subprocess module. When I add the eldk (cross compiler) path before my env $PATH the defconfig fails in multiconfig.py (uses the python in the eldk toolkit). Can I just remove python from the eldk tools (so the newer python will be used) or is that older python version required for some other script in the cross compiler?
pdavid@david-TECRA-A8:~$ python Python 2.7.6 (default, Mar 22 2014, 22:59:38) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import subprocess
[1]+ Stopped python david@david-TECRA-A8:~$ export PATH=/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin/armv5te-linux-gnueabi:$PATH david@david-TECRA-A8:~$ python Python 2.7.3 (default, Oct 18 2013, 13:50:05) [GCC 4.8.1] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import subprocess
Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: No module named subprocess
[2]+ Stopped python david@david-TECRA-A8:~$ which python /opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/python
On Thu, Aug 07, 2014 at 12:11:41PM -0400, david@plentovichdesign.com wrote:
Hello. I read the posts a couple days ago about the Python issues with Kconfig feature. I didn't see a resolution on how this would be fixed. I am running Ubuntu 14.04LTS, building u-boot and the problem I have is that the eldk tools have a older python (2.7.3) which does not have the subprocess module but the current Ubuntu python (2.7.6) does include the subprocess module. When I add the eldk (cross compiler) path before my env $PATH the defconfig fails in multiconfig.py (uses the python in the eldk toolkit). Can I just remove python from the eldk tools (so the newer python will be used) or is that older python version required for some other script in the cross compiler?
pdavid@david-TECRA-A8:~$ python Python 2.7.6 (default, Mar 22 2014, 22:59:38) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import subprocess
[1]+ Stopped python david@david-TECRA-A8:~$ export PATH=/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin/armv5te-linux-gnueabi:$PATH
You only need /opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi to be added to your PATH to compile U-Boot (or the kernel). I don't know why OpenEmbedded-based SDKs default to such a stripped down Python2 installation.
Hello Tom,
On 07-08-14 21:08, Tom Rini wrote:
On Thu, Aug 07, 2014 at 12:11:41PM -0400, david@plentovichdesign.com wrote:
Hello. I read the posts a couple days ago about the Python issues with Kconfig feature. I didn't see a resolution on how this would be fixed. I am running Ubuntu 14.04LTS, building u-boot and the problem I have is that the eldk tools have a older python (2.7.3) which does not have the subprocess module but the current Ubuntu python (2.7.6) does include the subprocess module. When I add the eldk (cross compiler) path before my env $PATH the defconfig fails in multiconfig.py (uses the python in the eldk toolkit). Can I just remove python from the eldk tools (so the newer python will be used) or is that older python version required for some other script in the cross compiler?
pdavid@david-TECRA-A8:~$ python Python 2.7.6 (default, Mar 22 2014, 22:59:38) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import subprocess
[1]+ Stopped python david@david-TECRA-A8:~$ export PATH=/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin/armv5te-linux-gnueabi:$PATH
You only need /opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi to be added to your PATH to compile U-Boot (or the kernel). I don't know why OpenEmbedded-based SDKs default to such a stripped down Python2 installation.
Because it is unneeded bloat? Adding a DEPENDS to the U-boot recipe for python-subprocess and python-xyz and rebuilding the sdk should fix this I guess.
Regards, Jeroen
On Thu, Aug 07, 2014 at 09:37:22PM +0200, Jeroen Hofstee wrote:
Hello Tom,
On 07-08-14 21:08, Tom Rini wrote:
On Thu, Aug 07, 2014 at 12:11:41PM -0400, david@plentovichdesign.com wrote:
Hello. I read the posts a couple days ago about the Python issues with Kconfig feature. I didn't see a resolution on how this would be fixed. I am running Ubuntu 14.04LTS, building u-boot and the problem I have is that the eldk tools have a older python (2.7.3) which does not have the subprocess module but the current Ubuntu python (2.7.6) does include the subprocess module. When I add the eldk (cross compiler) path before my env $PATH the defconfig fails in multiconfig.py (uses the python in the eldk toolkit). Can I just remove python from the eldk tools (so the newer python will be used) or is that older python version required for some other script in the cross compiler?
pdavid@david-TECRA-A8:~$ python Python 2.7.6 (default, Mar 22 2014, 22:59:38) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import subprocess
[1]+ Stopped python david@david-TECRA-A8:~$ export PATH=/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin/armv5te-linux-gnueabi:$PATH
You only need /opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi to be added to your PATH to compile U-Boot (or the kernel). I don't know why OpenEmbedded-based SDKs default to such a stripped down Python2 installation.
Because it is unneeded bloat? Adding a DEPENDS to the U-boot recipe for python-subprocess and python-xyz and rebuilding the sdk should fix this I guess.
Putting on my OE-guy hat, if we're shipping a host python for some good reason, it should be as useful as a stock python install on desktop-or-server-distro-du-jour. I did some quick poking when I first hit this and it seems the OE one ships with almost nothing for external modules which made me question why it's even shipped.
Hello Tom,
On 07-08-14 21:43, Tom Rini wrote:
On Thu, Aug 07, 2014 at 09:37:22PM +0200, Jeroen Hofstee wrote:
Hello Tom,
On 07-08-14 21:08, Tom Rini wrote:
On Thu, Aug 07, 2014 at 12:11:41PM -0400, david@plentovichdesign.com wrote:
Hello. I read the posts a couple days ago about the Python issues with Kconfig feature. I didn't see a resolution on how this would be fixed. I am running Ubuntu 14.04LTS, building u-boot and the problem I have is that the eldk tools have a older python (2.7.3) which does not have the subprocess module but the current Ubuntu python (2.7.6) does include the subprocess module. When I add the eldk (cross compiler) path before my env $PATH the defconfig fails in multiconfig.py (uses the python in the eldk toolkit). Can I just remove python from the eldk tools (so the newer python will be used) or is that older python version required for some other script in the cross compiler?
pdavid@david-TECRA-A8:~$ python Python 2.7.6 (default, Mar 22 2014, 22:59:38) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
> import subprocess >
[1]+ Stopped python david@david-TECRA-A8:~$ export PATH=/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin/armv5te-linux-gnueabi:$PATH
You only need /opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi to be added to your PATH to compile U-Boot (or the kernel). I don't know why OpenEmbedded-based SDKs default to such a stripped down Python2 installation.
Because it is unneeded bloat? Adding a DEPENDS to the U-boot recipe for python-subprocess and python-xyz and rebuilding the sdk should fix this I guess.
Putting on my OE-guy hat, if we're shipping a host python for some good reason, it should be as useful as a stock python install on desktop-or-server-distro-du-jour. I did some quick poking when I first hit this and it seems the OE one ships with almost nothing for external modules which made me question why it's even shipped.
Well putting on my small, tiny OE user head, you need to spell out every python-module you use. To make it a bit more funny there are likely grouped, so don't be surprised this is python-system or something. I am in the impression the nativesdk uses the same recipes where possible, so hence needs to be rebuild with explicit DEPENDS (unless you got luckily that a recipe before u-boot included it.) Anyway there are a lot more people on the list who know this a lot better, Marex?
Regards, Jeroen
On 07-08-14 22:02, Jeroen Hofstee wrote:
Hello Tom,
On 07-08-14 21:43, Tom Rini wrote:
On Thu, Aug 07, 2014 at 09:37:22PM +0200, Jeroen Hofstee wrote:
Hello Tom,
On 07-08-14 21:08, Tom Rini wrote:
On Thu, Aug 07, 2014 at 12:11:41PM -0400, david@plentovichdesign.com wrote:
Hello. I read the posts a couple days ago about the Python issues with Kconfig feature. I didn't see a resolution on how this would be fixed. I am running Ubuntu 14.04LTS, building u-boot and the problem I have is that the eldk tools have a older python (2.7.3) which does not have the subprocess module but the current Ubuntu python (2.7.6) does include the subprocess module. When I add the eldk (cross compiler) path before my env $PATH the defconfig fails in multiconfig.py (uses the python in the eldk toolkit). Can I just remove python from the eldk tools (so the newer python will be used) or is that older python version required for some other script in the cross compiler?
pdavid@david-TECRA-A8:~$ python Python 2.7.6 (default, Mar 22 2014, 22:59:38) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
>> import subprocess >>
[1]+ Stopped python david@david-TECRA-A8:~$ export PATH=/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin:/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin/armv5te-linux-gnueabi:$PATH
You only need /opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi
to be added to your PATH to compile U-Boot (or the kernel). I don't know why OpenEmbedded-based SDKs default to such a stripped down Python2 installation.
Because it is unneeded bloat? Adding a DEPENDS to the U-boot recipe for python-subprocess and python-xyz and rebuilding the sdk should fix this I guess.
Putting on my OE-guy hat, if we're shipping a host python for some good reason, it should be as useful as a stock python install on desktop-or-server-distro-du-jour. I did some quick poking when I first hit this and it seems the OE one ships with almost nothing for external modules which made me question why it's even shipped.
Well putting on my small, tiny OE user head,
ok I am not beheaded, hat ^
Regards, Jeroen
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On Thursday, August 07, 2014 at 10:02:54 PM, Jeroen Hofstee wrote:
Hello Tom,
On 07-08-14 21:43, Tom Rini wrote:
On Thu, Aug 07, 2014 at 09:37:22PM +0200, Jeroen Hofstee wrote:
Hello Tom,
On 07-08-14 21:08, Tom Rini wrote:
On Thu, Aug 07, 2014 at 12:11:41PM -0400, david@plentovichdesign.com
wrote:
Hello. I read the posts a couple days ago about the Python issues with Kconfig feature. I didn't see a resolution on how this would be fixed. I am running Ubuntu 14.04LTS, building u-boot and the problem I have is that the eldk tools have a older python (2.7.3) which does not have the subprocess module but the current Ubuntu python (2.7.6) does include the subprocess module. When I add the eldk (cross compiler) path before my env $PATH the defconfig fails in multiconfig.py (uses the python in the eldk toolkit). Can I just remove python from the eldk tools (so the newer python will be used) or is that older python version required for some other script in the cross compiler?
pdavid@david-TECRA-A8:~$ python Python 2.7.6 (default, Mar 22 2014, 22:59:38) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
>> import subprocess
[1]+ Stopped python david@david-TECRA-A8:~$ export PATH=/opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin:/opt/eldk- 5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gnueabi:/op t/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/sbin:/opt/eldk-5.5/arm v5te/sysroots/i686-eldk-linux/usr/sbin/armv5te-linux-gnueabi:$PATH
You only need /opt/eldk-5.5/armv5te/sysroots/i686-eldk-linux/usr/bin/armv5te-linux-gn ueabi to be added to your PATH to compile U-Boot (or the kernel). I don't know why OpenEmbedded-based SDKs default to such a stripped down Python2 installation.
Because it is unneeded bloat? Adding a DEPENDS to the U-boot recipe for python-subprocess and python-xyz and rebuilding the sdk should fix this I guess.
Putting on my OE-guy hat, if we're shipping a host python for some good reason, it should be as useful as a stock python install on desktop-or-server-distro-du-jour. I did some quick poking when I first hit this and it seems the OE one ships with almost nothing for external modules which made me question why it's even shipped.
Well putting on my small, tiny OE user head, you need to spell out every python-module you use. To make it a bit more funny there are likely grouped, so don't be surprised this is python-system or something. I am in the impression the nativesdk uses the same recipes where possible, so hence needs to be rebuild with explicit DEPENDS (unless you got luckily that a recipe before u-boot included it.) Anyway there are a lot more people on the list who know this a lot better, Marex?
Thanks for CCing me.
I sent a patch to OE-core to ship the python modules. This is a problem with the Yocto Qt SDK toolchain in general and you can track the mayhem at [1]. There will likely be ELDK 5.5.3 once this is all settled.
btw. you should update to ELDK 5.5.2 in the first place, since the compiler in Yocto 1.5.0 did have trouble with code generation [2], [3].
[1] http://lists.openembedded.org/pipermail/openembedded-core/2014- August/095470.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 [3]http://lists.openembedded.org/pipermail/openembedded-core/2014- February/089489.html
Best regards, Marek Vasut
Hello Marex, Tom,
On 07-08-14 22:14, Marek Vasut wrote:
<snip> > Well putting on my small, tiny OE user head, you need to spell out > every python-module you use. To make it a bit more funny there are > likely grouped, so don't be surprised this is python-system or something. > I am in the impression the nativesdk uses the same recipes where > possible, so hence needs to be rebuild with explicit DEPENDS (unless > you got luckily that a recipe before u-boot included it.) Anyway there > are a lot more people on the list who know this a lot better, Marex? Thanks for CCing me.
I sent a patch to OE-core to ship the python modules. This is a problem with the Yocto Qt SDK toolchain in general and you can track the mayhem at [1]. There will likely be ELDK 5.5.3 once this is all settled.
btw. you should update to ELDK 5.5.2 in the first place, since the compiler in Yocto 1.5.0 did have trouble with code generation [2], [3].
[1] http://lists.openembedded.org/pipermail/openembedded-core/2014- August/095470.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 [3]http://lists.openembedded.org/pipermail/openembedded-core/2014- February/089489.html
A bit of topic, beside the toolchain problems, aren't these dependencies of the u-boot recipe? The native sdk will pick them up if any machine needs them (at least in my setup). Besides of that, do we really want so much dependencies for u-boot what used to be sed, awk.. and uh find perhaps? Is all of this needed to just compile u-boot?
nativesdk-python-core \ nativesdk-python-textutils \ nativesdk-python-sqlite3 \ nativesdk-python-pickle \ nativesdk-python-logging \ nativesdk-python-elementtree \ nativesdk-python-curses \ nativesdk-python-compile \ nativesdk-python-compiler \ nativesdk-python-fcntl \ nativesdk-python-shell \ nativesdk-python-misc \ nativesdk-python-multiprocessing \ nativesdk-python-subprocess \ nativesdk-python-xmlrpc \ nativesdk-python-netclient \ nativesdk-python-netserver \ nativesdk-python-distutils \ nativesdk-python-unixadmin \ nativesdk-python-compression \ nativesdk-python-json \ nativesdk-python-unittest \ nativesdk-python-mmap \ nativesdk-python-difflib \ nativesdk-python-pprint \ nativesdk-python-git \ nativesdk-python-pkgutil \
Regards, Jeroen
On Thursday, August 07, 2014 at 10:37:52 PM, Jeroen Hofstee wrote:
Hello Marex, Tom,
On 07-08-14 22:14, Marek Vasut wrote:
<snip>
Well putting on my small, tiny OE user head, you need to spell out every python-module you use. To make it a bit more funny there are likely grouped, so don't be surprised this is python-system or something. I am in the impression the nativesdk uses the same recipes where possible, so hence needs to be rebuild with explicit DEPENDS (unless you got luckily that a recipe before u-boot included it.) Anyway there are a lot more people on the list who know this a lot better, Marex?
Thanks for CCing me.
I sent a patch to OE-core to ship the python modules. This is a problem with the Yocto Qt SDK toolchain in general and you can track the mayhem at [1]. There will likely be ELDK 5.5.3 once this is all settled.
btw. you should update to ELDK 5.5.2 in the first place, since the compiler in Yocto 1.5.0 did have trouble with code generation [2], [3].
[1] http://lists.openembedded.org/pipermail/openembedded-core/2014- August/095470.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 [3]http://lists.openembedded.org/pipermail/openembedded-core/2014- February/089489.html
A bit of topic, beside the toolchain problems, aren't these dependencies of the u-boot recipe? The native sdk will pick them up if any machine needs them (at least in my setup).
Why would it do it please?
What exactly is your setup, please describe it in detail.
Besides of that, do we really want so much dependencies for u-boot what used to be sed, awk.. and uh find perhaps? Is all of this needed to just compile u-boot?
This is a question for Yamada-san, +CC . But from my point of view, I see we had dependency on python with some tools for a while -- it's only now that the dependency got pulled into the build system. On the other hand, I don't know what are the plans with the Kconfig and it might end up that this dependency will eventually disappear.
nativesdk-python-core \ nativesdk-python-textutils \ nativesdk-python-sqlite3 \ nativesdk-python-pickle \ nativesdk-python-logging \ nativesdk-python-elementtree \ nativesdk-python-curses \ nativesdk-python-compile \ nativesdk-python-compiler \ nativesdk-python-fcntl \ nativesdk-python-shell \ nativesdk-python-misc \ nativesdk-python-multiprocessing \ nativesdk-python-subprocess \ nativesdk-python-xmlrpc \ nativesdk-python-netclient \ nativesdk-python-netserver \ nativesdk-python-distutils \ nativesdk-python-unixadmin \ nativesdk-python-compression \ nativesdk-python-json \ nativesdk-python-unittest \ nativesdk-python-mmap \ nativesdk-python-difflib \ nativesdk-python-pprint \ nativesdk-python-git \ nativesdk-python-pkgutil \
Regards, Jeroen
Best regards, Marek Vasut
Hello Marek,
On 07-08-14 23:52, Marek Vasut wrote:
<small> Thanks for CCing me.
I sent a patch to OE-core to ship the python modules. This is a problem with the Yocto Qt SDK toolchain in general and you can track the mayhem at [1]. There will likely be ELDK 5.5.3 once this is all settled.
btw. you should update to ELDK 5.5.2 in the first place, since the compiler in Yocto 1.5.0 did have trouble with code generation [2], [3].
[1] http://lists.openembedded.org/pipermail/openembedded-core/2014- August/095470.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 [3]http://lists.openembedded.org/pipermail/openembedded-core/2014- February/089489.html
A bit of topic, beside the toolchain problems, aren't these dependencies of the u-boot recipe? The native sdk will pick them up if any machine needs them (at least in my setup).
Why would it do it please?
For the RDEPENDS at least adding it to the recipe itself instead of some common image file makes sure it gets deleted if nobody is using it any longer. And hopefully makes sure you can't compile/use something on the host which isn't on the target, since the header files will be missing. RDEPENDS do get included in the sdk in my setup. For DEPENDS it would mean the sdk can build the same targets with the same tools, but I never checked if it does that.
What exactly is your setup, please describe it in detail.
Doesn't really matter, you need to convince the oe people. Not me, I am just a user of oe user, if the thing does what I want I am happy enough.
Besides of that, do we really want so much dependencies for u-boot what used to be sed, awk.. and uh find perhaps? Is all of this needed to just compile u-boot?
This is a question for Yamada-san, +CC . But from my point of view, I see we had dependency on python with some tools for a while -- it's only now that the dependency got pulled into the build system. On the other hand, I don't know what are the plans with the Kconfig and it might end up that this dependency will eventually disappear.
yup, understood, I will leave it up to them.
With kind regards, Jeroen
On Saturday, August 09, 2014 at 12:16:01 AM, Jeroen Hofstee wrote:
Hello Marek,
On 07-08-14 23:52, Marek Vasut wrote:
<small> Thanks for CCing me.
I sent a patch to OE-core to ship the python modules. This is a problem with the Yocto Qt SDK toolchain in general and you can track the mayhem at [1]. There will likely be ELDK 5.5.3 once this is all settled.
btw. you should update to ELDK 5.5.2 in the first place, since the compiler in Yocto 1.5.0 did have trouble with code generation [2], [3].
[1] http://lists.openembedded.org/pipermail/openembedded-core/2014- August/095470.html [2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 [3]http://lists.openembedded.org/pipermail/openembedded-core/2014- February/089489.html
A bit of topic, beside the toolchain problems, aren't these dependencies of the u-boot recipe? The native sdk will pick them up if any machine needs them (at least in my setup).
Why would it do it please?
For the RDEPENDS at least adding it to the recipe itself instead of some common image file makes sure it gets deleted if nobody is using it any longer. And hopefully makes sure you can't compile/use something on the host which isn't on the target, since the header files will be missing.
It does make sense, but the toolchain is then stripped down in such fashion that it's rather useless. Still, would you mind commenting on the patch sent to the OE list and expressing this concern?
RDEPENDS do get included in the sdk in my setup. For DEPENDS it would mean the sdk can build the same targets with the same tools, but I never checked if it does that.
Yes, this does make sense. But then, this also means the toolchain becomes useless for general use.
What exactly is your setup, please describe it in detail.
Doesn't really matter, you need to convince the oe people. Not me, I am just a user of oe user, if the thing does what I want I am happy enough.
Urgh, this was not really helpful answer.
Besides of that, do we really want so much dependencies for u-boot what used to be sed, awk.. and uh find perhaps? Is all of this needed to just compile u-boot?
This is a question for Yamada-san, +CC . But from my point of view, I see we had dependency on python with some tools for a while -- it's only now that the dependency got pulled into the build system. On the other hand, I don't know what are the plans with the Kconfig and it might end up that this dependency will eventually disappear.
yup, understood, I will leave it up to them.
Uh, OK.
Best regards, Marek Vasut
participants (4)
-
david＠plentovichdesign.com -
Jeroen Hofstee -
Marek Vasut -
Tom Rini