[Buildroot] [RFCv1 0/4] Per-package SDK and target directories
Arnout Vandecappelle
arnout at mind.be
Tue Nov 7 23:21:01 UTC 2017
On 03-11-17 17:06, Thomas Petazzoni wrote:
[snip]
> What remains to be done?
> ========================
>
> - Completely get rid of the global HOST_DIR, TARGET_DIR and
> STAGING_DIR definitions, so that nothing uses them, and they really
> become per-package variables.
I don't think that that's needed.
> - While the toolchain sysroot, pkg-config paths and host RPATHs are
> properly handled, there are quite certainly a lot of other places
> that have absolute paths that won't work well with per-package SDK,
> and that need to be adjusted.
>
> - Perhaps use a temporary per-package SDK and target directory when
> building a package, and rename it to the final name once the
> package has finished building. This would allow to detect
> situations where the per-package SDK directory of package A
> contains absolute paths referring to the per-package SDK directory
> of package B. Such absolute paths are wrong, but we currently don't
> see them because the per-package SDK directory for package B still
> exists.
Add an instrumentation hook:
! grep -r $(PER_PACKAGE_DIR) $(HOST_DIR) $(TARGET_DIR)
That will immediately point to the culprit package. Maybe you want to avoid
grepping through gigabytes of data over and over again so perhaps use the same
approach as check-bin-arch.
But actually,
>
> - Many other issues that I'm sure people will report.
>
> Comparison with Gustavo's patch series
> ======================================
>
> Gustavo Zacarias did a previous implementation of this, available in
> http://repo.or.cz/buildroot-gz.git/shortlog/refs/heads/pps3-next. Compared
> to Gustavo's patch series, this patch series:
>
[snip]
> - I haven't integrated Gustavo patches that move from $(shell ...) to
> using backticks to delay the evaluation of
> STAGING_DIR/HOST_DIR/TARGET_DIR:
>
> http://repo.or.cz/buildroot-gz.git/commitdiff/0c11c60865f1445830643bb404f92c20d563260c
> http://repo.or.cz/buildroot-gz.git/commitdiff/207d2248ec8542293b6201b5c86f971021a3a591
> http://repo.or.cz/buildroot-gz.git/commitdiff/7f6a69819fbb176e29a1c3a53b4a76efe87dad15
> http://repo.or.cz/buildroot-gz.git/commitdiff/3328a9745eee555f5e5ef7df835afc26612ecd7b
> http://repo.or.cz/buildroot-gz.git/commitdiff/45a9d8c2aa6f3c0d2d8ed989d843890025faa3e8
Independently of the PPS feature, these are useful patches I think. Can you
submit them?
> - I haven't looked at Qt specific issues, such as the ones fixed by
> Gustavo in:
>
> http://repo.or.cz/buildroot-gz.git/commitdiff/643e982e635f4386ccefcda9da4b84536af84d04
Yeah, and something similar for CMake as well...
I'm a bit worried about python and friends. They may embed paths in all kinds
of weird places. Like sysconfigdata has paths to compilers and stuff.
But now I think about it a little more: is there really a problem if e.g. a .la
file refers to a library in one of the other per-package dirs? The library does
exist there after all... The only thing we need to avoid is that a package
installs something in a different package's per-package dir. You may of course
end up with references to indirect dependencies, but they are still dependencies
that are tracked by Buildroot so they're OK.
So how about this: at the end of the package build, we make the per-package dir
readonly. An evil package can of course still make it readwrite again before
installing something, but it's not very likely.
Cleaning up all references to other per-package dirs is only really needed if
we want to make a tarball of the directory to save as a seed for a later build.
But we're not there yet by a long shot, so let's just ignore that use case.
Regards,
Arnout
>
> - I am not doing all the .la files, *-config, *.prl, etc. tweaks that
> Gustavo is doing in:
>
> http://repo.or.cz/buildroot-gz.git/commitdiff/3f7b227b4c8e4514df6e5d54f88fcfb3a3a4bae0
>
> It is part of the "remaining absolute paths that need to be fixed"
> item that I mentionned above.
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
More information about the buildroot
mailing list