Andy Ross skrev: > Ove Kaaven wrote: >> It looks like there are some portability issues in the current >> code... > > On three platforms which don't have the CPU power (or GPU support!) to > actually, y'know, run the software. :)
Well, the Debian source package is currently declared as "Architecture: any", which means it declares itself buildable on all Debian-supported architectures, and the Debian buildds will thus automatically build packages for them all (or try to). A FTBFS (failure to build from source) on a buildd (or any other system satisfying the constraints declared by the package, for that matter) is automatically a serious bug that will make the package be considered unfit for release (and subject to removal if not fixed by release freeze), by Debian policy. It's not just him being cranky about his own pet issues, it's about policy and the pursuit of high software standards. And if that's not convincing, it's also about fitting everything into Debian's highly automated distribution infrastructure, where build failures create a problem. In cases like this, there are two ways to fix the FTBFS: fix the source to actually *be* buildable on all architectures as declared (even if performance isn't expected to be optimal on them all), *or* fix the Debian source package's declaration to specifically list *only* the architectures it is supposed to work on, instead of "any". Obviously, that will remove the package from distribution on the remaining architectures, but in a policy-compliant way that the infrastructure is now aware of; the package will then be distributed fine on the declared architectures. I'd personally prefer the first option if possible, as it'd lead to less headaches about maintaining the list of supported architectures, but... Which would you recommend, then? > As explained very clearly in the comments, all known platforms support > this code just fine, and the benefits are very large. And I'm even > conservative about refusing to compile on platforms on which I can't > test, thus the #error (it's a feature, not a bug!). Well, I guess the real question here is, what happens if Linux decides to change this in a future release, then? If they think it's a good idea, they're not going to take "it breaks FlightGear" as a good reason not to, more likely Linus Torvalds is going to flame you guys good, or something... > I'm happy to take patches, though. This support is trivially really > easy to add, if Mr. Langasek is actually willing to help out a little. > Just the output of "echo | gcc -dM -E -" on each of the platforms is > sufficient. I think he already provided the requisite defines, though somewhat buried in his mail. Beyond that, perhaps this web page would be of interest: http://predef.sourceforge.net/prearch.html ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
