From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yann E. MORIN Date: Tue, 3 Apr 2018 19:01:19 +0200 Subject: [Buildroot] [PATCH 1/1] core: enhance printvars for variables with newlines In-Reply-To: References: <20180403143151.13372-1-chemobejk@gmail.com> <20180403165012.0d0e173a@windsurf> <20180403162156.GA2335@scaer> Message-ID: <20180403170119.GC2335@scaer> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Stefan, All, On 2018-04-03 19:37 +0300, Stefan Becker spake thusly: > Hi, > On Tue, Apr 3, 2018 at 7:21 PM, Yann E. MORIN < [1]yann.morin.1998@free.fr> wrote: > > The real solution IMHO is that you base your iamge creatikon out of the > rootfs.tar image generated by Buildroot. > > I'm not sure that is feasible, because then you would loose access to things that need to be done inside fakeroot (f.ex.). Of course, as I wrote below, your script that does the work woudl need to run under fakeroot, obviously. This can be easily achieved with a snippet like that: #!/bin/sh if [ $(id -u) -ne 0 ]; then fakeroot "${0]" "${@}" exit ${?} fi # here goes your real filesystem code... > Plus @master the new rootfs-common.tar has been added, but the build deletes it again and thus it can't be exported as build > artifact. Beause this is only an internal temporary file that you should not be concerned with. Besides, it is not even totaly complete either... I was talking about the *real* final rootfs.tar that you get with BR2_TARGET_ROOTFS_TAR. > If you are using a br2-external tree, you can also define your own > filesystem iamge type that depends on rootfs.tar. Then your image > generator (or a wrapper around that) would extract (under fakeroot) > rootfs.tar, and generate your own image format out of that. > > ...which would mean we are back in the slow monolithic meta build > system with our components. Sorry, but that won't do :-) Of course, if you are trying to fast-track Buildroot with local hacks, you are back on your own... > BTW: we do have a br2-external tree but it is basically "pure". It is only needed so that we do not pollute the buildroot tree with > things that are needed to run the buildroot build system and create the build artifacts afterwards. Sorry, I don't understand what you mean by "pure". There is no "purity" to talk of about a br2-external tree: by definition, you put in there whatever you want. You probably meant that you are not touching the buildroot tree. Yes, I understand. But nothing prevents you from putting your own filesystem (or rather, image) generation tool as a new filesystem type. See for example what I explained at ELCE last year: https://elinux.org/images/8/8e/2017-10-24_-_ELCE-Buildroot.pdf (slide 16) https://youtu.be/SN2hYO2rYtk?t=728 Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'