[haiku-development] Re: A modest (FatELF) proposal
- From: Jonathan Schleifer <js-haiku-development@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 20 Nov 2012 00:59:10 +0100
Am 19.11.2012 um 22:04 schrieb pulkomandy:
> This, on the other hand, doesn't sound ok to me.
> The developper would have to test and debug binaries on all the
> architectures he wants to release. This means having a development
> environment on each platform, building and testing binaries there. THEN,
> when they work, package and release them. The packaging can then be done
> at package manager level and has no need for fatelf.
Nothing is preventing the developer to publish a test binary that many users
can test before he makes a release.
> As for the size increase : one of the selling points of Haiku is that it
> is lightweight. Fat binaries are adding extra weight to it for a purpose
> I'm not sure is that useful : being able to use an Haiku installation on
> different CPUs. You can drag and drop your apps, but not a full
> partition because the bootloader (and possibly the partition scheme of
> the disk) would be different.
> The size inclrease was not too important for Apple because they had at
> most 3 architectures in the same package (PPC, x86, x86-64). On Haiku we
> have :
> * x86-gcc2
> * x86-gcc4
> * ARM
> * x86-64
> * PPC
> * 68k
>
> And the list could be growing (MIPS, ...). That's already 6 archs to
> support, which starts to have a significant impact on the size of
> packages even if there is a lot of data.
> To me, this means we WILL be wasting space on disk, and download
> bandwidth, for no practical purpose. It means Haiku wouldn't fit on a CD
> or an 1GB USB stick anymore, for example.
I wouldn't include every arch in the standard Haiku distribution, but maybe in
some kind of developer distribution that also comes with everything set up for
crosscompiling. But x86-gcc2 + x86-gcc4 fat binaries would make a lot of sense
for libraries. The applications however could be flat.
--
Jonathan
Other related posts:
