Explain the current purpose of the script. Drop the former eclass
documentation tokens which are no longer useful.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
Quite possible overlooked something, far too much noise in the
build system files diff to figure out what needs attention.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Existing use implies a desire to:
- treat leading "-" as optional
- query the value of a "flag"
- query the entire arg of a "-flag" or "-flag=" or really anything other
than "flag" where CFLAGS has "-flag=*"
But unfortunately we also do odd things like match `get-flag -g` to
retrieve -grecord-gcc-switches or -fno-gnu-keywords etc. It's a rough
substring match and really we want to match flag *names*. It is also a
bit awkward to do "-flag=" and then trim off the flag name by hand.
Update the algorithm to allow for this. Given it's a big change to
usability, require users to opt in to the new algorithm by migrating
their ebuilds to EAPI 9 and testing there. They could have been relying
on what I called a bug.
Some things that will definitely break, but I cannot conceive of why one
would do it:
- FLAGS="-fno-gnu-keywords"; get-flag -g
Gross misuse.
- FLAGS="-flto-incremental=/path"; get-flag "-flto-inc*="
omitting the = works fine, what is the goal here???
Acked-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
If you look hard enough, every single code branch uses the same byte
range processor, repetitively repeated again (and also again) and then
branches on tar or gzip depending on the inner contents. That final
command is better suited as an array, so we can run the main command
*once*.
It is not clear to me why this function has "true" followed by commented
out dies. It lacks real explanation, and dates back to
gentoo-historical-2.git:
```
commit 557d48b91a21b650f2fadd609fc8bee679dc1af3
Author: Mike Frysinger <vapier@gentoo.org>
AuthorDate: Sat Feb 4 23:48:42 2012
Commit: Mike Frysinger <vapier@gentoo.org>
CommitDate: Sat Feb 4 23:48:42 2012
initial unpacker eclass
```
Do I dare add the relevant `pipestatus || die` here? Not really, this
code already terrifies me. But *perhaps* running the command here once
would solve whatever concerns the year 2012 had about this code. Maybe.
Possibly. You be the judge!
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
It is feature-compatible with rpm2tar but utilizes the rpm codebase. The
first any-of element remains rpm2targz as it's vastly smaller, but for
users who happen to have rpm installed as a dep of some other package,
there is no need to additionally install another package.
rpm 4.19.0 is required because:
- rpm2archive was added in 2014 / rpm 4.12
- it learned -n in 2021 / rpm 4.17
- it learned to write to a pipe in 2022 / rpm 4.19
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
It should have always been die.
From gentoo-historical-2.git,
```
commit 712cd6740c0bfa9d15dfd33ead7a52d5cdd4f87b
Author: Tomas Chvatal <scarabeus@gentoo.org>
AuthorDate: Sat Mar 23 06:16:57 2013
Commit: Tomas Chvatal <scarabeus@gentoo.org>
CommitDate: Sat Mar 23 06:16:57 2013
Add next version of office-ext eclass. This time we can directly deploy libreoffice exts, but ooo crashes so keep backcompat over crashy uno interface for them (it is oo bug and they should fix it).
```
I have many questions. However, the one which is relevant here is: why
did this new eclass *add* new src_unpack logic to actually unpack files,
which called a single simple command, `unzip`, and then uses assert to
catch pipe errors in it.
Same issue as myspell-r2.eclass in the previous commit.
assert is banned in EAPI 9, so it has to go anyway. Take this
opportunity to perform a 14 year old cleanliness fix.
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
It should have always been die.
From gentoo-historical-2.git,
```
commit 39b01d59be512eb9ed10a66db19513e6b53130f4
Author: Tomas Chvatal <scarabeus@gentoo.org>
AuthorDate: Tue Apr 24 08:49:09 2012
Commit: Tomas Chvatal <scarabeus@gentoo.org>
CommitDate: Tue Apr 24 08:49:09 2012
Add myspell-r2.eclass which is just eclassdoced myspell.eclass with removed no-longer required stuff.
```
I have many questions. However, the one which is relevant here is: why
did this new eclass *add* a new src_unpack, which called a single simple
command, `unzip`, and then uses assert to catch pipe errors in it.
assert is banned in EAPI 9, so it has to go anyway. Take this
opportunity to perform a 14 year old cleanliness fix.
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
The preceding command pipeline is `printf | xargs`, and printf is a bash
builtin. It cannot fail. `die`ing if xargs fails to consume the pipe
buffer is sufficient.
assert is banned in EAPI 9, so it needs to go regardless. There's no
point to using `inherit eapi9-pipestatus` here.
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
The whole purpose of this function is really just to run specific
commands "as CHOST=${CBUILD}" during cross, in case you really need
CBUILD copies of stuff e.g. to do asset generation.
We also have an econf helper which... sets CHOST then runs econf. And
ebuilds such as anki and zig also override CHOST when using
tc-env_build, which implies it is useful/needed.
While exploring app-containers/containerd failing to cross build, I
observed a challenging issue for go-env.eclass as well. One may wish to
use tc-env_build to override the go env to set up, as such:
```
tc-env_build go-env_set_compile_environment emake ....
```
but the latter function sets go's host mode (goarch) based on CHOST,
while the former function checks for cross mode by comparing CHOST
versus CBUILD. Once again, we need a wrapper for tc-env_build to run,
just to set CHOST?
It seems simpler and more consistent to always set it.
Note order is important; tc-getBUILD_XXX must appear and run on the
command line *first*, as they use CHOST internally.
Bug: https://bugs.gentoo.org/966257
Reviewed-by: Sam James <sam@gentoo.org>
Reviewed-by: James Le Cuirot <chewi@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>