> Autotools-based can be good or bad for cross-compiling. The biggest > issue is that lots of people write broken tests that need to run test > programs to get the results they want.
As long as there are differences between systems, build-time tests will be necessary to check for what the system provides and what needs working around. This is the main problem with cross-compilation: build-time tests only work in the native case. When cross-compiling, there is no way to automatically figure out what the target flags are. The best solution would be to have a centralized, worldwide database of system-dependent flags and options that any cross-compilation process could search and extract target information from. Until we have that, the only clean way to cross-compile is to have the user provide target sysdeps *by hand*. As far as I am aware, autotools do not make that easy. This essential part of the cross-compilation process is not integrated into the autotools architecture, which is why I do not consider them a reliable system. I don't know CMake, but my guess is that it does not do that either. The busybox KBuild-like system, as difficult to automate as it is, is a step towards clean sysdeps management. (Part of the reason why it works is also that it only supports Linux, which gets rid of all incompatibility problems between different flavours of Unix, and only leaves machine-dependent issues, which are the easiest to tackle since the kernel handles most of them.) Until there is a database I can automatically extract complete cross-compilation information from, I will keep maintaining my own list of sysdeps, and have my users provide the relevant sysdeps values by hand when they need to cross-compile. -- Laurent _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox