| # 04:26:30 | cpackham | I wouldn't say it's a non goal. Just that I tried and gave up. If someone with the right level of knowledge and energy wants to pick up the effort I'd happily carry whatever changes are required in ct-ng to make it work' |
| # 04:31:07 | cpackham | quits : Ping timeout: 252 seconds |
| # 07:11:26 | milkylainen | cpackham: I guess one could package some sort of default for various archs, but my guess is that you're going to get a bunch of new issues related to people and their distro interaction plus a new wishlist of packaging combinations. "Why this glibc, can't we have another?" etc. |
| # 11:21:56 | HcE | quits : Quit: kernel++ |
| # 11:23:14 | HcE | joins #crosstool-ng |
| # 11:26:19 | Net147 | quits : Quit: Quit |
| # 11:57:11 | Net147 | joins #crosstool-ng |
| # 11:57:15 | Net147 | quits : Changing host |
| # 11:57:15 | Net147 | joins #crosstool-ng |
| # 11:57:36 | HcE | quits : Quit: kernel++ |
| # 11:59:18 | HcE | joins #crosstool-ng |
| # 12:05:23 | Net147 | quits : Quit: Quit |
| # 12:07:31 | Net147 | joins #crosstool-ng |
| # 12:07:33 | Net147 | quits : Changing host |
| # 12:07:34 | Net147 | joins #crosstool-ng |
| # 14:02:55 | realtime-neil | I can't speak for non-Debian distros, but I daresay that native Debian packaging (where you keep the `debian/` in your own source control) would be an unwelcome disruption to your release process. |
| # 14:04:59 | realtime-neil | milkylainen: I was under the impression that ct-ng (at runtime) acquires literally everything it needs to produce the user-given toolchain. Does it require a compiler and/or libc from the host? |
| # 14:09:18 | milkylainen | realtime-neil: you need a somewhat normal, basic C development environment for the bootstrap parts. configure{.ac} will whine if it doesn't find mandatory bits. |
| # 15:04:14 | realtime-neil | milkylainen: ah, okay; you're probably correct in your prediction; that _is_ where the first complaints will spawn. |
| # 19:21:27 | milkylainen | realtime-neil: ? Not sure what you mean. I mean that providing binaries for user, you have to be ready for whatever usage errors or distribution strangeness they may face. Also, packaging toolchain is something with a lot of options on how to build what and why. Different users have different needs from a toolchain. Ergo, the perfect default toolchain hardly exists. |
| # 19:21:53 | milkylainen | realtime-neil: I create my own with ct-ng. That's one way to make sure I get what I want etc. |
| # 19:42:06 | cpackham | joins #crosstool-ng |
| # 19:54:36 | realtime-neil | milkylainen: I mean that --- even though the build-time dependencies of ct-ng are so meager (a basic C dev env, as you say) --- end users will find a way to take issue with what is found and used during packaging. |
| # 19:54:59 | realtime-neil | I'm not advocating the packaging of the toolchains themselves --- only ct-ng proper. |
| # 19:55:35 | realtime-neil | Which I've done in my little salsa repo. |
| # 19:57:28 | realtime-neil | as far as all the other stuff --- the things that get dumped in ~/x-tools/ --- those probably can't be packaged easily. At any rate, because there are so many supported variants, it's probably infeasible. |
| # 20:01:29 | milkylainen | realtime-neil: A toolchain in x-tools can be tarballed up. It is relative, so you can place it wherever you like. |
| # 20:03:25 | realtime-neil | milkylainen: Absolutely concur and it's one of the things I like most about ct-ng. But there's too many `.config` combinations to package everything. |