On Thu, 2008-04-17 at 06:41 +0200, Jens M Andreasen wrote:
On Wed, 2008-04-16 at 22:41 +0200, Mario Lang wrote:
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
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
2008/4/17, Christian Schoenebeck [EMAIL PROTECTED]:
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
On Thu, 2008-04-17 at 09:58 +0200, Richard Spindler wrote:
This sounds really cumbersome. And some very widely used distributions
do not install a C-Compiler by default.
Very few distributions - if any at all? - installs TeX by default
either. Nevertheless this is a dependency if you want
2008/4/17, Jens M Andreasen [EMAIL PROTECTED]:
What do you think about the approach taken by liboil?
http://liboil.freedesktop.org/
The library has implementations for various CPU-Extensions, and at run
time, when the library is initialized, a set of function pointers is
set to
El dc 16 de 04 del 2008 a les 18:55 +0200, en/na Lars Luthman va
escriure:
On Wed, 2008-04-16 at 18:36 +0200, Pau Arumí Albó wrote:
Luthman va escriure:
This is a development tool, but I'm sending it to the LAU list as well
in case there are any not-yet-hackers who would like to start
On Thu, 2008-04-17 at 13:08 +0200, Pau Arumí wrote:
So basically it's just a more descriptive way of referencing plugin
ports. You could just as well use the indices and the number of ports
directly and don't bother with lv2peg, but it's nice to have while
working on a plugin with lots of
On Thu, 2008-04-17 at 10:49 +0200, Richard Spindler wrote:
2008/4/17, Jens M Andreasen [EMAIL PROTECTED]:
It would have been smarter to have liboil.so be a symlink to
liboil-sse_4_1.so (or whatever hardware you may have)
What if I export /usr over NFS and have machines with different
2008/4/17, Jens M Andreasen [EMAIL PROTECTED]:
You really do that? OK, the solution is identical to choosing the right
base architecture in the first place. One of these gets mounted
as /usr/lib
---8---
/*/usr/lib/i386
/*/usr/lib/i686
/*/usr/lib/i686.sse2
this is getting ridiculous,
On Thu, 2008-04-17 at 14:00 +0200, Richard Spindler wrote:
2008/4/17, Jens M Andreasen [EMAIL PROTECTED]:
You really do that? OK, the solution is identical to choosing the right
base architecture in the first place. One of these gets mounted
as /usr/lib
---8---
/*/usr/lib/i386
On Thu, 2008-04-17 at 14:00 +0200, Richard Spindler wrote:
First of all being that the original developer is likely the most
knowledgeable person to handle this problem.
You are assuming that the original unpaid developer owns any of the
fancy hardware in question? That is in the general case
This sounds really cumbersome. And some very widely used distributions
do not install a C-Compiler by default.
What do you think about the approach taken by liboil?
http://liboil.freedesktop.org/
The library has implementations for various CPU-Extensions, and at run
time, when the
2008/4/17, Jens M Andreasen [EMAIL PROTECTED]:
You are assuming that the original unpaid developer owns any of the
fancy hardware in question? That is in the general case - to put it
mildly - a stretch.
This depends on how much work/money the individual dev wants to put
into his project.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Schoenebeck wrote:
| 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
On Thu, 2008-04-17 at 16:14 +0200, Fernando Lopez-Lezcano wrote:
You mean _complete_ binaries? All of the executable replicated several
times with different optimizations inside the package? So your intention
is not to optimize selected portions of the program, but _all_ of it??
No, plase be
Jens M Andreasen [EMAIL PROTECTED] writes:
On Wed, 2008-04-16 at 22:41 +0200, Mario Lang wrote:
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
On Thu, 2008-04-17 at 19:02 +0200, Mario Lang wrote:
No. If you optimize code, you will only have to special case
a few routines. The greater hunk of the code will stay the same on different
variants. So you do not want to precompile binary packages for
all sorts of special CPU types and
On Thu, 2008-04-17 at 19:31 +0200, Jens M Andreasen wrote:
On Thu, 2008-04-17 at 19:02 +0200, Mario Lang wrote:
No. If you optimize code, you will only have to special case
a few routines. The greater hunk of the code will stay the same on
different
variants. So you do not want to
On Thu, 2008-04-17 at 18:36 +0200, Jens M Andreasen wrote:
On Thu, 2008-04-17 at 16:14 +0200, Fernando Lopez-Lezcano wrote:
You mean _complete_ binaries? All of the executable replicated several
times with different optimizations inside the package? So your intention
is not to optimize
19 matches
Mail list logo
