[haiku-development] Re: BuildSystem: Automatically creating symlinks in GCC Alt Dir.

  • From: Ingo Weinhold <ingo_weinhold@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 24 Apr 2010 17:37:46 +0200

On 2010-04-24 at 16:56:27 [+0200], Matt Madia <mattmadia@xxxxxxxxx> wrote:
> >From :
> //www.freelists.org/post/haiku-commits/r36431-haikutrunkbuildjam,5
> This wip patch allows build/jam/OptionalPackages to denote "this
> archive can be used on either gcc." and for that to trigger the
> automatic creation of symlinks in the alt gcc subdir,  (eg
> boot/common/lib/gcc4).
> So far it's working for archives that get extracted onto the image.
> One issue is that packages like XML contain *.so | *.so.* in odd
> directories, such as common/lib/python2.6/site-packages/libxml2mod.so.
> These too will have symlinks created in an alt gcc subdir.

That's why I suggested to rewrite the paths to target FS relative paths and 
check against the standard library paths (system/lib, common/lib, 
home/config/lib). One doesn't even need the original paths for creating the 
symlinks as one can just as well do that on the target image.

> More importantly, OptionalPackages that set the isCDPackage are not
> yet handled. This latter part is where I could use some feedback.
> I'm not sure if it'd be better to implement addSymlinksForCDPackage()
> in build_haiku_image, which creates a listing of files in the archive
> or if Installer's UnzipEngine should be enhanced.

I'm not familiar with Installer's UnzipEngine, but it seems that it would 
be the best place. The archives would need to be marked whether they are 
gcc-agnostic (e.g. via attribute).

Generally I'd rather like to phase out the traditional CD images and switch 
to anyboot, though. This would make the zipped packages obsolete. My work 
on the caching for CDs looks promising so far at least. So this might be an 
option for the release already. My only concern is disk space, 
particularly, if we intend to add all sources.

CU, Ingo

Other related posts: