found 774129 1.19.7 quit You might consider -a/--target-arch or -t/--target-type to merely be conveniences, but /not/ enabling the cross profile when the build arch differs from the host arch is stopping a decimeter shy of the goal line.
Is it even possible someone /wouldn't/ want the cross profile if cross-building? (a --no-default-profiles option could be worthwhile) While the original bug report is about `dpkg-buildpackage`, this also applies to `dpkg-checkbuilddeps`. I'm inclined to rate this as more than "wishlist". At a minimum, the man page for `dpkg-buildpackage` would need to suggest using "-P cross" when using -a or -t. What is worthy of consideration is whether enabling the cross profile should cause the noocaml profile (possibly others) to be enabled. Cross-compiling Python bindings is pretty simple, depend on libpython-dev and python-dev:any. OCAML is presently very broken for cross-compilation (pretty well impossible). I'm unsure of the other profiles. My concern is if enabling cross doesn't enable noocaml, any package setup for cross-compilation, but includes some OCAML will have to disable OCAML if either is enabled. In the future once OCAML becomes cross-friendly, every single package will then need to reenable OCAML. Whereas if dpkg-buildpackage is handling the situation merely removing cross => noocaml could take care of those which don't need adjustment to OCAML invocation (and would then generate new reports for packages which do need adjustment). -- (\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/) \BS ( | ehem+sig...@m5p.com PGP 87145445 | ) / \_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
