[haiku-development] Re: External package woes (was What to do with termcap?)
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 2 Feb 2013 10:15:49 +0100
Am 02.02.2013 um 00:17 schrieb pulkomandy@xxxxxxxxxxxxx:
>
>> 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.
>
> We don't encourage custom builds of Haiku for all different CPU instruction
> sets variants out there. We chose some requirements that make sense, and we
> make sure to keep binary compatibility as long as it makes sense. So, this
> doesn't need to be an easy task.
Isn't this besides the point?
>> 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.
>
> Even more time is spent answering mails here.
No reason to be rude. It appears to me, Landon is investing some serious effort
into Haiku and is genuinely interested in how an aspect of the work flow can be
improved. I would be hoping that the least we draw out of this discussion is a
possible improvement for his situation, even if externalized packages stay that
way. All I have heard so far is that tools would eventually support his
use-case, but the fact remains, they don't right now.
Best regards,
-Stephan
Other related posts:
