I think you will end up having to support generating different source trees for each multilib variant to be safe and correct.
Yes, that comes out naturally if the RTS is built in libada. In fact, Arnaud said:
The idea currently is to make these values explicit so that when people read system.ads, they know right away what the right value is.
That's "when people read system.ads", not "when people read system-linux-x86.ads". In other words, he's not necessarily against automatically generating system.ads from other means, for example using configure tests. Which, I repeat, comes out naturally if the RTS build is confined in libada.
This will work for native builds but may have problems on cross builds where you can't run a program. I know for the RTEMS g-soccon* file we have to run a program on target hardware and capture the output.
Do you really need to run programs? Most of gen-soccon can be done by running Ada source code through the C pre-processor and massaging the output. In fact, the code that would be passed through cpp strongly resembles gen-soccon.c itself.
If you move the source to libada and start potentially using different source combinations for different multilib variants, then it does need to be on a branch. But some of the patches so far seem like they would be OK to commit on the mainline and minimize diffs.
Yes, that's true. Paolo
