[haiku-development] Re: External package woes (was What to do with termcap?)
- From: Landon Fuller <landonf@xxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 1 Feb 2013 09:31:34 -0500
On Feb 1, 2013, at 3:35 AM, Stephan Aßmus <superstippi@xxxxxx> wrote:
> Am 01.02.2013 09:15, schrieb Ingo Weinhold:
>> Stephan Aßmus wrote:
>>> Am 01.02.2013 08:19, schrieb Ingo Weinhold:
>>>> Landon J Fuller wrote:
>>>>> I'd personally find a lot of value in being able to very easily
>>>>> automatically build the full OS, using the toolchain configured for the
>>>>> purpose (including cross-compilation).
>>>>
>>>> Being able to automate as much as possible is certainly desirable. I doubt
>>>> that we will be able to build the whole OS from the scratch automatically
>>>> anytime soon, though. One major problem is that many software packages
>>>> cannot be cross-built by default (even something as fundamental as bash
>>>> falls into that category). Making/hacking them so that they can be
>>>> cross-built is likely quite a lot of one-time and continuous maintenance
>>>> work. I think it is more realistic that we get cross-building support
>>>> going for the minimal set of software packages required to do native
>>>> builds. A fully automatic OS build would then involve building most
>>>> software in a VM.
>>>
>>> Ok, but the work to make packages cross compilable was already done by
>>> integrating them into the Haiku source tree build system. That work (and
>>> feature) gets wasted by externalizing them again.
>>
>> In most cases the work done was basically a minimal effort to get the
>> software building. They are *not* properly cross-building. E.g. in many
>> cases you will find files like config.h (or similar) which have at some
>> point been generated by the respective native build system (under Haiku) and
>> checked in. In many cases they are likely outdated and might not even work
>> for all architectures, anyway.
>
> Ok, that is rather convincing.
It's usually pretty easy to hand-manage a config.h (which is what I've done in
the past). The issue I have here is that the old method introduced a cost when
maintaining those particular packages (but not an insurmountable one, it worked
for years, and works for other projects), while the new method creates enormous
barriers to development when one has to touch core components.
I'd rather volunteer to be maintainer of all things third party (I've done it
before, and now I have need of being able to build them), than have a huge
barrier like the one being created now by moving things out-of-tree before
there's any automated infrastructure to manage building them.
-landonf
Other related posts:
