RFC core: install foo-config scripts early in the PATH (branch yem/foo-config-in-PATH)
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 8 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 8 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Buildroot] [PATCH 0/8 RFC] core: install foo-config scripts early in the PATH (branch yem/foo-config-in-PATH)
Thomas, All,
On 2015-12-22 11:53 +0100, Thomas Petazzoni spake thusly:
Quoted 14 lines · Yann E. MORIN
Quoted 5 lines
That one is interesting, indeed. We "fix" rtai-config in-place in staging, but then we never pass $(STAGING_DIR)/usr/bin/rtai-config to any variable of any package, which means that any consumer of rtai-config, if any, is called with $(STAGING_DIR)/usr/bin in its PATH.
Absolutely not.
There are no packages in Buildroot that use the RTAI libraries. The rtai-config script in $(STAGING_DIR) is meant to be used:
1/ by custom packages (i.e not in Buildroot mainline)
Quoted 7 lines
2/ by people building their stuff outside of Buildroot
Quoted 1 line
I think this is an abomination. There are three cases there:
There is absolutely no abomination here. This is a regular *-config script, installed in
STAGING_DIRlike any other. It is just not used by any package in the upstream Buildroot.
Oh, sorry, what I meant is: having staging/usr/bin in the PATH is an abomination.
Of course, the rtai-config script is not the abomination I was referring too. My bad, I was not carefull enough in proof-reading what I wrote.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
It is not broken today. Such special *-config scripts get naturally installed in $(STAGING_DIR), they might be fixed up by a patch or some custom hook. And then on the consumer side, we pass some environment variable or other trick to get the consumer build system to use this specific -config script rather than the one in the PATH. Nothing special.
Quoted 11 lines
Quoted 3 lines
Then those patch-or-hook fixups should be complemented by a post-install hook that also installs the -config script in the newly-introduced
FOO_CONFIG_DIR.Correct.
Quoted 5 lines
Again, nothing that this series would *break*; existing "workarounds" would continue to work as-is. It's only a new opportunity to cleanup the mess, but will need much more pathces later on.
Ah, that's probably what I forgot to write in my cover later: this
s/later/letter/ Damit... :-)
Cheers! ;-)
Regards,
Yann E. MORIN.
Quoted 16 lines
Quoted 7 lines
8-patch series only introduces the "infra" and does not actually fix the packages, or undo our workarounds, or removes our patches, of add new fixes. Hmm. Well, actually I did:
When/if the topic is accepted (and the series is fixed after the reviews), we can then (un)fix / (un)patch packages in follow-up patches.
Yes, yes, this is fully understood, I do understand that we will be able to remove a number of patches, or custom variable passing.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | 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. | '------------------------------^-------^------------------^--------------------'