[haiku-development] Re: External package woes (was What to do with termcap?)
- From: Landon J Fuller <landonf@xxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 1 Feb 2013 13:01:17 -0500
On Feb 1, 2013, at 12:36 PM, pulkomandy@xxxxxxxxxxxxx wrote:
>
> On 2013-02-01 at 06:53:33 [+0100], Landon J Fuller <landonf@xxxxxxxxxxxxxx>
> wrote:
>>
>> Now, imagine it's a bit more complex -- you need to be able to quickly test
>> changes to ICU that affect LocaleKit, which means you need to build both,
>> repeatedly. A build bot isn't an option there, so what you really need is a
>> way to do this automatically, and then rebuild LocaleKit, as part of a
>> standard compile+run test cycle.
>
> You don't do it this way.
It's an efficient way of working on the Core OS, and has been very handy in
testing changes that span libraries, the runtime loader, and the kernel.
>> Or, let's say you're trying to test an experimental new compiler (say, a
>> beta version of clang where you've implemented support for the legacy gcc2
>> CXXABI, or in my case, a fatelf-capable toolchain), which means you really
>> need to be able to test building and executing the full system, including
>> all of its dependencies.
>
> Porting the OS to a new CPU goes the same way. This does not happen very
> often and it didn't seem to be a problem for our ports to ARM, PowerPC and
> x86_64. On the other hand, we did ran, several times, into problems because
> we imported libs inside our build system (for ICU, ffmpeg, and bash, this
> happened). Updating the libs to a newer version and tweaking the jam build
> system for it is error-prone and dangerous. This happens more often than
> porting to new archs and annoys more people (everyone using nightly builds).
I've watched this generate work repeatedly for ports, and it has been a
constant time drain for my own work. I also expect it to be a large roadblock
when I get around to the clang work on my TODO list, and from past experience,
I expect it to increase the costs of most efforts that have to cross package
boundaries. You're effectively preferring/optimizing for maintenance of
relatively simple third-party tools that *lots* of people can maintain, over
optimization of work on core components (compilers, ABIs, etc) that very few
people can/will do. The result is that I can't, today, just go build the ARM
port for a new ARMv7 ABI or modified calling conventions -- I have to do a
bunch of manual heavy lifting to bootstrap an OS environment that I can then
use to build the required packages, instead of being able to focus on the
actual problem at-hand.
This doesn't seem worth it for the 20 or so core dependencies that are
necessary to build+run the OS, especially since most of the world to integrate
them was already done, and now more work is being invested in lifting them back
out of the source tree before genuinely automated tools to deal with them exist.
-landonf
Other related posts:
