[haiku-development] Re: gcc4 build broken in headers/private/userlandfs/shared/HashMap.h

  • From: Marcus Jacob <rossi@xxxxxxxxxxxxxxx>
  • To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
  • Date: Thu, 19 Mar 2009 12:32:39 +0100

On 19.03.2009, at 12:06, Stephan Aßmus <superstippi@xxxxxx> wrote:


Marcus Jacob schrieb:

On 19.03.2009, at 11:41, "Stephan Assmus" <superstippi@xxxxxx> wrote:

Hi,

Von: Marcus Jacob <rossi@xxxxxxxxxxxxxxx>
On 19.03.2009, at 09:31, "Stephan Assmus" <superstippi@xxxxxx> wrote: 
"Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:

Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
Any opinions regarding HAIKU_ADD_ALL_OPTIONAL_PACKAGES? It really 
installs
*all* known optional packages and optional test packages. Is that 
still
considered useful?
I've never used it, and I also don't think it still makes much sense.
Same here. I think I may have used it in the beginning, but that's a 
long time ago... :-)


How about an option to just download all optional packages for
inclusion in the image and a little script to install from those
"cached" packages outside the build system?

Would allow to see whats available but still requires a sensible
decision about what one wants to install?
The OptionalPackages jam file already lists all optional packages at the beginning and is always up2date.
I meant in an actual install, which doesn't nescessarily has a local copy of the source tree. This would also allow to install different setups from the same image (e.g. dev system vs. test system) without creating different images and would allow for deferred installation of optional packages.
Yes, a proper package management system and a nice UI to access it would be nice. There is already "box" for the command line from the Tilt-OS project. However, this thread is just about removing the HAIKU_ADD_ALL_OPTIONAL_PACKAGES variable from the build system in order to prevent it's use because it will cause more trouble than being a convenience like it was originally intended to be.
Actually I didn't mean proper package management, even though that would be nice ;-)
I just meant an alternative to the install all optional packages during the build, which doesn't have the grave consequences as the curtent solution but still allows an easy way to have all packages (uninstalled for later installation) downloaded and copied to the image and a stand-alone installer script to be able to easily install those packages later on, without the need of a checked out source tree.
My usage is to currently use this option, as I have a dedicated build machine, which toasts a new image every day and by using this option all new packages are automagically part of the build, without constant maintanance of the build configuration scripts ;-) 

Cheers,
Rossi

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 03-2009