Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This question is inherently subjective, but I think option (1) is a better choice - since you specify that "performance is of utmost importance."</p> <p>Most users of a package (i.e., distro users) will be happy with either pre-built packages, or source builds with default options. If performance <em>is</em> critical, it is reasonable to expect the user to be familiar with compiler flags and <code>configure ...</code> usage. If a user is not bothered by performance, or is too lazy to read a simple <code>README</code> in the distribution, then the default build should just be something that works - it needn't be optimal.</p> <p>I'm not sure about the disadvantages of cross-compilation - it seems you might have <code>host</code> and <code>target</code> confused, as <code>target</code> is rare outside of building cross-compiler tools. Correct use of the <code>host</code> triple in conjunction with <code>config.guess</code> gives a lot of useful information. For example:</p> <pre><code>case $host_cpu in x86_64) ... we always have SSE available ... ;; esac </code></pre> <p>Now let's say you specify <code>-march=core2</code> as a [cross] compiler flag:</p> <pre><code>#if defined (__SSE3__) #include &lt;pmmintrin.h&gt; /* (SSE3 Intel intrinsics) #endif </code></pre> <p>would work even with a cross compiler. (Although <code>&lt;immintrin.h&gt;</code> is preferable nowadays) </p> <p>In short, a novice user gets a novice build. You cannot optimize for every possible host and environment combination, but you can provide options.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload