[Buildroot] [PATCH] fs: allow extra arguments to common tarball extraction
arnout at mind.be
Fri Jun 8 19:58:17 UTC 2018
On 08-06-18 19:34, Yann E. MORIN wrote:
> Arnout, All,
> On 2018-06-08 09:48 +0200, Arnout Vandecappelle spake thusly:
>> On 08-06-18 01:12, Carlos Santos wrote:
>>> BTW, it took me some time to understand the dual personality of TARGET_DIR
>>> in fs/common.mk and the role of BASE_TARGET_DIR. Then I found the line in
>>> the top Makefile with
>>> TARGET_DIR = $(if $(ROOTFS),$(ROOTFS_$(ROOTFS)_TARGET_DIR),$(BASE_TARGET_DIR))
>>> I understand that this trick avoids changing fs/*/*.mk replacing each
>>> reference to TARGET_DIR by a ROOTFS_<FOO>_TARGET_DIR but it reduces
>>> the readability a lot. I'm compelled to restore it to how it was prior
>>> to commit 7e9870ce32d.
>> The same (or a similar) trick will be applied to the normal packages for
>> per-package host/staging/target (which is ultimately needed for top-level
>> parallel build). If we want to avoid it there, we would have to change 785
>> package.mk files, and also many package definitions in BR2_EXTERNALs that we
>> don't control...
>> That said, I would also prefer to use explicit $(FOO)_TARGET_DIR variables. But
>> doing so *will* require legacy handling.
>> Maybe we should indeed use explicit ROOTFS_$(ROOTFS)_TARGET_DIR in our rootfs
>> definitions, document that that is the one to use, and wait a year or two before
>> deprecating TARGET_DIR entirely.
> Well, It is really cumbersome to have to prefix that directory with the
> package name or the rootfs name... TARGET_DIR is just plainly easy to
I don't agree with that - we use FOO_SOME_VARIABLE all over the place in
package foo, so using FOO_TARGET_DIR feels quite natural to me.
> Especially since we would break a long-established variable name.
That's the worst reason ever :-) Except that indeed there should be a (long)
transition period where the old name is still supported, but we don't use it
> And it is not the only variable that changes its content based on the
> current package: $(@D) and $(@) et al. Yes, they are make special
> variables, but so?
That makes a huge difference - people know those variables.
And anyway, I wouldn't mind to use $(FOO_BUILD_DIR) instead of $(@D). I think
that is easier for people to understand. $(@D) just happens to work because the
stamp files are created in the build directory, which IMO is an implementation
detail that shouldn't leak into the packages.
> In the end, I still fail to see the problem. But I am usual pretty
> stubborn, so... ;-)
> Yann E. MORIN.
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
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