Re: [Ltib] Programming for an ltib system

[Stuart Hughes]

On 20/10/11 16:21, Magnus Therning wrote:
> On Thu, Oct 20, 2011 at 09:44, Stuart Hughes<address@hidden>  wrote:
> > Qt is horrible to package, but if I recall qtopia.spec deals with a similar
> > situation when it builds the host tools that are needed (once).  Take a look
> > at dist/lfs-5.1/qtopia/qtopia.spec, maybe that helps?
> Yes indeed, Qt is a horrible package ;)
>
> I don't think the situation is similar to qtopia though, since the
> tools built by Qt are needed by all subsequent packages that use Qt.
> This means I need to put them somewhere on the $PATH (I settled for
> ${TOP}/bin), and I also need to install a few data files needed by
> those tools (I settled for ${TOP}/bin here too). It seems to work all
> right, but it's far from elegant.
>
> Am I correct in my assessment that this scenario is rather poorly
> supported by ltib (and probably every other rootfs builder out there
> too)?
>
> /M
Hi Magnus,

It's worth taking a look, I believe qtopia used to build a whole pile of 
host packages and cache/stuff them in the users' home directory (? can't 
remember) so that subsequent builts etc could use them (for example moc 
and friends).  I think the build systems are similar.  Might be a few clues.

Your approach is reasonable.  There's not magic bullet here 
unfortunately as you have to trade off whether the tools you built can 
be shared across projects (lets say you have another BSP that has a 
different set of options/versions of the same tools).  This will drive 
where you save these.

I'm not sure about other rootfs builders.  For ltib, the approach for 
host support packages is to build them and put them under /opt/ltib as 
rpm packages, controlled by their own private rpm database.  So you 
could create a qt-host-package.spec file and build this and install it 
as an ltib host support package (check out ./ltib --hostcf).  Doing this 
would mean it would be common for everyone on that host, which may or 
maynot be okay for you.

Regards, Stuart