Development mailing list

On Thu, Jan 31, 2013 at 2:50 PM, John Scipione jscipione@xxxxxxxxx wrote: Would it be possible to modify the build system to grab and build a package from a haikuport instead of grabbing a pre-build binary since the haikuport package already reproduce[s[ their build systems' installation procedure in the bep file and is already out of tree? More than likely, we'll have to modify each bep, and possibly a version of HaikuPorter to support cross-compilation to accomplish this. Right now, bep files pretty much assume they're being used from a Haiku host. ...

On Thu, Jan 31, 2013 at 3:37 PM, Ingo Weinhold ingo_weinhold@xxxxxx wrote: [...] I am aware that it may sound like I mean we should put everything into the Haiku tree and have no external packages at all. I don't think that's a good idea either, but I specifically wonder about those build-dependency packages. Keeping them in the tree is a mess IMO. These packages are usually also needed as dependencies of other packages, so we end up having to reproduce ...

Stephan Aßmus superstippi@xxxxxx wrote: For what it's worth, I totally agree, that the externalization of packages has often made things more complicated. I agree that some software has a tricky build system and depends on certain compiler flags to work correctly like for example ffmpeg. It is sometimes error-prone to replace their build system with Haiku's. Most packages build with no or only small Haiku specific patches. Updating them to a newer version is usually just a matter of rebuilding them. If they are in ...

On Jan 31, 2013, at 3:04 PM, Ingo Weinhold ingo_weinhold@xxxxxx wrote: That may be so, but Haiku's build system is not meant to optimize your rare use case, but rather the common everyday use cases. I'd consider maintaining an OS to be the common everyday use case (eg, adding functionality, keeping things in sync, being able to target new devices). I've never thought about how I'd want to break FreeBSD's world build into a bunch of manual processes just to save a little time on the initial full build, ...

On Jan 31, 2013, at 3:02 PM, Ingo Weinhold ingo_weinhold@xxxxxx wrote: Landon J Fuller landonf@xxxxxxxxxxxxxx wrote: On Jan 30, 2013, at 11:48 AM, Ryan Leavengood leavengood@xxxxxxxxx wrote: On Wed, Jan 30, 2013 at 11:14 AM, Landon J Fuller landonf@xxxxxxxxxxxxxx wrote: It means that a developer (ie, me) has to have access to the ports system rebuild all the software in the ports system, ...

Landon J Fuller landonf@xxxxxxxxxxxxxx wrote: On Jan 30, 2013, at 12:44 PM, pulkomandy@xxxxxxxxxxxxx wrote: - Building all this stuff makes the Haiku build longer and more memory hungry than it needs to be. I'd rather spend some time waiting for the compiler than spend a bunch of time actively tracking down individual dependencies and building them. This has been very frustrating. ...

Landon J Fuller landonf@xxxxxxxxxxxxxx wrote: On Jan 30, 2013, at 11:48 AM, Ryan Leavengood leavengood@xxxxxxxxx wrote: On Wed, Jan 30, 2013 at 11:14 AM, Landon J Fuller landonf@xxxxxxxxxxxxxx wrote: It means that a developer (ie, me) has to have access to the ports system rebuild all the software in the ports system, Why *all* the software? I would just rebuild the package I am interested in. ...

Am 30.01.2013 18:21, schrieb Landon J Fuller: Speaking from direct and recent experience, this makes it much harder to patch/rebuild that software when working on the base system, especially in cases where one is targeting new compilers/ABIs/platforms and rebuilding the entire system (including dependencies) is necessary. It means that a developer (ie, me) has to have access to the ports system, rebuild all the software in the ports system, and put it somewhere that can be ...

On Jan 30, 2013, at 12:44 PM, pulkomandy@xxxxxxxxxxxxx wrote: Having all the core components in-tree makes it a lot easier to maintain the system cleanly in lock-step, add support for OS-specific features in lock-step with the OS release, deploy to new targets, update to new ABIs, and otherwise manage the core system as a cohesive whole. That's not true. We don't blindly use svn:externals or similar tools, but ...

Having all the core components in-tree makes it a lot easier to maintain the system cleanly in lock-step, add support for OS-specific features in lock-step with the OS release, deploy to new targets, update to new ABIs, and otherwise manage the core system as a cohesive whole. That's not true. We don't blindly use svn:externals or similar tools, but use a clearly identified version of the external packages. So, we can update them only as needed and matching the OS releases if we need so. ...

On Jan 30, 2013, at 11:48 AM, Ryan Leavengood leavengood@xxxxxxxxx wrote: On Wed, Jan 30, 2013 at 11:14 AM, Landon J Fuller landonf@xxxxxxxxxxxxxx wrote: So in that regard I don't see anything wrong with shipping ncurses, and really, think that moving software that the OS reuqires *out* of the core system is counter-productive. It just means a lot more work to manage putting the same bits and pieces back together again, ala Linux distributions. ...

On Wed, Jan 30, 2013 at 11:14 AM, Landon J Fuller landonf@xxxxxxxxxxxxxx wrote: So in that regard I don't see anything wrong with shipping ncurses, and really, think that moving software that the OS reuqires *out* of the core system is counter-productive. It just means a lot more work to manage putting the same bits and pieces back together again, ala Linux distributions. The difference between Haiku and Linux is that Haiku is a full system and even if the pieces of software we use are not in our source ...

Jérôme Duval писал 30.01.2013 16:42: 2013/1/30 Kit kervas@xxxxxxxxx: Excuse my naïvety, but why would FreeBSD be ashamed of having ncurses in their tree? ...

On Jan 30, 2013, at 10:42 AM, Jérôme Duval korli@xxxxxxxxxxxxxxxx wrote: 2013/1/30 Kit kervas@xxxxxxxxx: Excuse my naïvety, but why would FreeBSD be ashamed of having ncurses in their tree? I think he is opposing the fact that Haiku tries to outsource out of its tree software maintained by third parties and ncurses would be such a case, but I might be wrong :) ...