[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>
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. 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
changes.
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).
--
Adrien.
Other related posts:
