17 Apr
2008
17 Apr
'08
3:01 a.m.
Am Mittwoch, 16. April 2008 22:41:36 schrieben Sie:
You are not really following what I am trying to get
across. Cross
compilation isn't the issue. The issue is that something as generic as
i386 (or i686 for rpm based distros IIRC) actually targets a lot of
different types of hardware. It can run on pretty old pentium based CPUs,
but also modern
systems. A binary distributor has no way of knowing which
CPU is going to be used, in fact, a single binary package
is going to be used by many of the supported variants.
Trust me, I can follow what you mean and I also thought about a solution for
that problem years ago. The point is, where do you draw the line? You might
say, for the x86 architecture you detect at runtime whether the system
supports: MMX, SSE(1), SSE2, SSE3 and precompile 5 binaries which is going to
be picked automatically at application startup. Unfortunately that's not
sufficient to achieve max. performance. On some weak systems for example you
achieve better results with -Os than with -O3. So wanna make extra binarie(s)
and runtime benchmark for that as well? You could continue that game for a
lot of other GCC flags and your binary collection would grow to a horrible
huge cross product. And we're still just talking about one architecture.
That's why I was thinking about a little different approach for binary
distributions: just precompile some part of the audio application (/most of
it) and actually compile the core elements (the ones that are crucial to
overall performance) on demand by the user. Because I agree compiling a whole
complex audio app is usually an unconvenient user-unfriendly task, especially
because all of those library dependencies and system specific path locations
etc. the user has to deal with and the long time it takes to compile the
whole beast. But with such a partly precompiled solution you (as a
distribution package maintainer) can already take away those hairy tasks,
because the few core elements that are going to be compiled by the user will
only have fery few dependencies left: the applications own library (which is
already there anyway) a compiler and very basic standard header files like
math.h which are usually there on a machine with compiler anyway. And since
those dependencies are so small, it wouldn't be a hard task to integrate such
a build system into the application itself, so the user just has to adjust
the CXXFLAGS in a line input box or something and press the "Recompile"
button.
CU
Christian