Re: [Ltib] Programming for an ltib system

[Stuart Hughes]

Hi Magnus,

On 14/10/11 15:24, Magnus Therning wrote:
> On Fri, Oct 14, 2011 at 10:07, Stuart Hughes <address@hidden> wrote:
>> Hi Magnus,
>>
>> LTIB is not ever intended to be an IDE or development environment. However
>> what it can help with is packaging up your work so you can build and deploy
>> in a repeatable fashion onto a number of different target platforms.
>>
>> With respect to developing your own package, you have 2 options.
>>
>> 1. The simplest, it to take the example 'helloworld' package and adapt that
>> to use your own code.
> [...]
> 
> That seems like a somewhat hack-ish way of doing it. Still it's good
> to know for those quick-and-dirty jobs :)
> 

If you ask me all software is one big hack :-)

>> 2. The other way, which is more geared at real on-going package development
>> is to use the directory-build process.  I don't have time to describe this
>> now, but the basics are shown in:
>>
>> dist/lfs-5.1/u-boot/u-boot-dir-build.spec.in
>> dist/lfs-5.1/u-boot/u-boot-common.tmpl (this is an example, yours can be
>> simpler)
>> config/userspace/u-boot-dir-build.lkc
>> config/platform/mpc8360epb/main.lkc (this is an example of how to wire in)
>>
>> The idea is that you point at the directory you have under cvs/git/svn
>> control and LTIB will build it for you with spoofing so you don't need any
>> CFLAGS/LDFLAGS etc.
>>
>> Sorry I don't have more time to explain, but I hope it gives a few clues.
> 
> This feels a bit more reliable, and more like "the right way". It took
> a little while to figure it all out, but I do have it working nicely
> now. I had to make the following modifications:
> 
> 1. Adding an option for including my package to the config, and a path
> entry in case the option is turned on.
> 2. Modifying 'ltib' itself so that the config variable holding the
> path makes it into the environment for use in the spec file.
> 3. A spec file.
> 
> Thanks for the pointers, they really did help a lot.

You should not have to modify ltib itself.  If you need environment
variables passed to your spec file, if the keys set in the configuration
system have the pattern:

_PRECONFIG or _WANT_ or SYSCFG_

they will be automatically exported. Grep some .spec files in
dist/lfs-5.1 to see how they get used.

> 
> Another question I ran into was how to get to the kernel headers when
> compiling my package. Should I point to the headers in
> $LTIB/rpm/BUILD/linux/include or is there a better place to use? (I
> didn't find such a pointer in the rpmbuild environment, it would be a
> handy thing to have pre-defined, no?)
> 

For well behaved userspace programs you normally get them from the root
filesystem staging area (rootfs/usr/include).  These are automatically
wired into the compiler spoofing and so you don't need to do anything
special for these (just use the normal #include <linux/...>)

If you need access to the real kernel headers, then I guess you're
building a kernel module or similar?  In which case, your package must
have an entry to say it wants the kernel headers, for example like:

config PKG_IPROUTE
    depends CAP_HAS_MMU
    depends !KERNEL_NONE
    select PKG_KERNEL_WANT_HEADERS
    bool "iproute(2)"
    help
       The iproute package contains networking utilities (ip and rtmon, for
       example) which are designed to use the advanced networking
       capabilities of the Linux kernel.


And then in your .spec file, do something like for example (iproute.spec):

%Build

make -j1 KERNEL_INCLUDE=$DEV_IMAGE/usr/src/linux HOSTCC="$BUILDCC"


Regards, Stuart