[haiku-development] Re: External package woes (was What to do with termcap?)

  • From: pulkomandy@xxxxxxxxxxxxx
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Fri, 01 Feb 2013 18:36:19 +0100

On 2013-02-01 at 06:53:33 [+0100], Landon J Fuller <landonf@xxxxxxxxxxxxxx> 
> 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. Instead, you run Haiku, checkout both ICU and Haiku 
sourcecode, and build just ICU and libbe. You put them both in a "lib" dir 
next to your test executables. And you don't even have to reboot to test your 

When this is not possible, we have tools to do it anyway. For example, there 
is the test_app_server environment which allows to test changes to app_server 
and decorators.

> 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).


Other related posts: