Hi, Mathieu Othacehe <othac...@gnu.org> skribis:
>> I've had this experience before, it's very confusing (it goes on trying >> to build a toolchain for something that is sure to fail). Perhaps we >> could at least have a place to refer to in the manual for the common GNU >> triplets which make the most sense in for GNU Guix (e.g., the currently >> supported GNU system triplets). Currently I grep the manual for >> disparate examples when my memory fail me. > > Yes, I also cannot remember those triplets even though I'm > cross-compiling all day long. This bug report was about system types, not triplets, but the problem is kinda similar and equally in need of a fix. :-) > Maybe we could: > > * Define all the supported architectures in (gnu platforms). We already > have ARM and Hurd defined there. > > * Define %supported-systems and %supported-targets lists constructed by > parsing the <platform> records. > > * Use those lists to check the values passed to --system and --target > arguments. > > * Add --list-available-systems and --list-available-targets arguments > for all the commands supporting --system and --target arguments. > > WDYT? I think it’s “nice” for ‘--target’ to accept a free-form triplet, because users might want to target a system triplet that Guix maintainers do not care about (we only cross-build for a handful of triplets right now). Based on that, I thought we could emit warnings when ‘cross-gcc’ & co. were passed a string that doesn’t look like a valid triplet. But then I realized that internally these procedures are passed things that are not quite triplets: see avr.scm and embedded.scm. So, a list of “supported” triplets like you suggest may be a good idea, though IMO it should be used to emit a warning rather than error out. For system types, we can probably error out to strings not in the list. Thoughts? Ludo’.
