Re: [gentoo-osx] The road ahead?

[Kito]

On Nov 1, 2005, at 4:01 PM, m h wrote:

>>>
>>> Well, if this is "round two" (which seems kind of weird since it's
>>> backported from v2.1 to 2.0...).
>>
>> Well. the 2.1 branch has been officially killed, which is the version
>> Haubi did his original work on, so Brian back ported it just so we
>> could start testing out the ebuilds in an overlay and have a working
>> prototype.
>
> Well, I'm interested in testing the 2.0 version if possible.

Few more days, and should have an updated tarball to post for testing.

> 3.0
> timeframe is start of next year?

I think its mostly a question of manpower...

>
>>
>>> I'm interested in tracking the
>>> "official" version as closely as possible. Maybe I should test this
>>> version out on FC4.  What will "round three", etc, look like (are
>>> there missing features, is it just testing, getting ebuilds
>>> converted,
>>> evangelism)?
>>>
>>> Kito- Could you please elaborate on the bootstrap process?
>>
>> Well, I started by building a toolchain manually in the prefix
>> (gcc,cctools[apples linker/assembler], coreutils, make, python, bash
>> and some others I'm forgetting), then configured and installed
>> portage. Once portage was up and running I just started importing the
>> base-system ebuilds to the overlay and merging as I went along. On a
>> FC4 system, you could probably just use some symlinks instead of
>> manually building a toolchain for bootstrap.
>>
>
> Yeah on linux you could get by pretty easily.  But if you want to
> allow end users to add new archs (could be distro, or posix operating
> system) wouldn't it be easier to have something like haubi's
> bootstrapper?

End users would simply download a stage tarball, just like a  
traditional gentoo install. People porting to other archs are welcome  
to try toolsbox, it was just more work for me to port toolsbox to  
Darwin than it was to build a toolchain manually and rebuild  
everything via portage.

>
>> I've finished the base-system ebuilds for a Darwin/OS X prefix, but
>> for linux you will still need a few extra that I haven't done yet,
>> like binutils, libtool, and gcc[1]. I'm going back and doing some
>> cleanup and additional testing, should have it checked into svn later
>> this week. Definitely want to get this working on as many archs as
>> possible, so any help is welcome.
>>
>>>   Perhaps
>>> we could put it in the wiki?
>>
>> I was going to create a project page in xml under the gentoo-alt
>> page, but a wiki might be a better idea, especially if a few other
>> non-gentoo devs want to start helping out with the linux/aix/solaris
>> stuff.
>>
>
> Making the information public is better than no information.  It seems
> like it is better suited to be in the wiki right now, since end users
> (non-gento devs) could add/edit/fix things in it.

Sounds good to me. I'll probably add another page and leave the  
existing one that describes haubis method there for posterity.

>
>>> Regarding changes to ebuilds, yes I
>>> agree small (or no) changes is preferred.
>>
>> Yeah, by far the biggest change needed right now is `make DESTDIR=$
>> {DEST} install`. I've made functions to address the ebuilds that
>> don't use econf, so the changes are very very slight, and with some
>> more work could probably even be lessened further.
>>
>
> So DEST is PREFIX now?

No. Most ebuilds do things in src_install() like `mv ${D}/usr/bin $ 
{D}/bin` and/or `[[ -e ${ROOT}/foo/bar]] && boof`

So instead of being faced with a lot of changes in virtually every  
ebuild in the tree, we shifted the meaning of the vars slightly.
So now, in the ebuild environment:

D=${BUILDDIR}/image/${PREFIX}
DEST=${BUILDDIR}/image
ROOT=${ROOT}/${PREFIX}

SO, really the only place you would ever use ${DEST} is `make DESTDIR= 
${DEST} install` as there should be no valid reason to ever touch the  
image dir directly.

This drastically reduces the number of changes required to get most  
ebuilds prefix compliant.

--Kito
-- 
gentoo-osx@g.o mailing list