In theory. In practice there can be a lot of issues when
cross-compiling SW using autotools etc.
For example, while autotools itself supports cross-compiling[1],
many programs utilizing autotools don't. Host system stuff
like available headers, features, tools, paths etc leak into
compiled target binaries & scripts, so that they don't work
completely correctly on the target system.
And when you fix such things, and do an update, upstream has
breaked something else. There's a good reason why Linux
distros do native builds even on slower platforms (e.g.
Debian m68k using Aranym).
When the amount of software is smaller and stable, and/or
"core" SW (which typically supports cross-compilation out
of box), this is less of an issue, but can still be a lot
of work.
When you don't have much developer time, it's better to skip
trying to do cross-compilation where you don't need to do it.
Machine-time is cheap (only problem could be building large
C++ programs, compiling them may require more memory than
the native system supports).
I propose starting from native compilation and just speeding
up slow things with e.g. distcc where the slaves are cross
compilers.