| Summary: | dobin: automatic support of EXEEXT | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | kinzo.x.beato |
| Component: | Enhancement/Feature Requests | Assignee: | Package Manager Specification <pms> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | dev-portage, lucianposton, toolchain |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=588330 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
kinzo.x.beato
2012-08-24 18:27:34 UTC
we can't blanket assume the argument to dobin implicitly ends with an .exe as we might be installing a shell script, but there probably should be a bit more intelligence here. similarly (but to a lesser degree), we might hit scaling problems with libraries due to .so vs .dll, although the prefix guys already have that with .dylib and such ... *** Bug 579042 has been marked as a duplicate of this bug. *** TL;DR: no, I doubt this will happen. First of all, this is against the direction PMS is taking. We'd rather make things simpler, more predictable, free of unnecessary magic. Compare e.g. with removing dohtml. Adding extra magic like this to dobin is inconsistent with this policy. Right now dobin is simple: take X and put it in $bindir/X. With this change, dobin starts to mean: take X or X.exe, or... It starts being less predictable. It starts being confusing. It starts introducing corner cases that need to be considered. It starts introducing multiple ways of doing the same thing. What will 'dobin X' do if there is both X and X.exe? Even if you define a good behavior for this case, note that it will be different for systems with .exe and for systems without suffix. Furthermore, if we add suffix magic to dobin, we need the same for doexe. Then for consistency we should also add it to dolib*. Since libraries differ both in prefixes and suffixes, soon enough we have half of multilib.eclass in the PMS. Finally, all those new functions need data. For consistency with existing libdir logic, this data should be provided by profiles. Which means we need to add a significant amount of data to profiles, and I don't even know if we have enough diverse profiles for this. To summarize, please don't add all this complexity. Especially for a corner-case of cross-compiling to a rare target. This is much better solved with explicit suffix getter for ebuilds (i.e. "dobin foo$(get_exeext)") which will at least make it reliable and predictable. That said, I wouldn't oppose strongly to adding such getters to PMS. However, as noted above for consistency they should cover all the related cases (i.e. library prefixes and suffixes as well -- and probably versions too). But the question still holds -- do we want all that complexity for a rare use case? I think it is possible to override dobin in a mingw32 profile. No progress. Closing per comment #3. |
