Re: [Ltib] Inter-package dependencies

[Peter Barada]

On 09/29/2012 07:02 AM, Stuart Hughes wrote:
> Thanks Peter,
>
> I'll need a little while to digest this, but in principle it seems like
> a good idea.
Sure.  I had trouble following your original suggestion using:

$platform_config_deps = {
   ...
};
$platform_build_deps = {
   ...
};
$platform_install_deps = {
   ...
};

in the platform dependency file since perl would complain that
$platform_config_deps was undefined in LTB after returning from "do", so
I instead returned the whole hash structure that contained CONFIG_DEP,
BUILD_DEP, INSALL_DEP as sub-hashes to get around it.  If there's a
better way to do it I'm all ears...

Thanks!

> Regards, Stuart
>
> On 28/09/12 21:45, Peter Barada wrote:
>> On 09/18/2011 06:40 AM, Stuart Hughes wrote:
>>> Hi Peter,
>>>
>>> There are currently only 2 mechanisms for inter-package dependencies
>>> right now. You probably know already, but for others' benefit:
>>>
>>> 1. The static .lkc stuff where in the packages.lkc you say for example:
>>>
>>> config PKG_BLUEZ_HCIDUMP
>>>     depends CAP_HAS_MMU
>>>     bool "bluez-hcidump"
>>>     select PKG_BLUEZ_LIBS
>>>
>>> This means if you select bluez-hcidump during configuration, it will
>>> also turn-on (select)  PKG_BLUEZ_LIBS.
>>>
>>> 2. Inside of the ltib script, there are also data-structures:
>>>
>>> # package config dependencies
>>> # re-build the key (lhs) if any of the dependents (rhs) in the list have
>>> changed
>>> $config_deps = {
>>>
>>> # package build dependencies
>>> # rebuild all packages in the list (rhs) if the key (lhs) has been installed
>>> $build_deps = { PKG_KERNEL => [ qw/PKG_MODEPS/ ],
>>>
>>> # packages install dependencies
>>> # re-install all the pkgs in the list (rhs) if the key (lhs) has been
>>> installed
>>> $install_deps = { PKG_SKELL => [ qw/PKG_SYSCONFIG/ ],
>>>                   PKG_BUSYBOX => [ qw/PKG_INETUTILS PKG_SYSKLOGD
>>>
>>> I think  you're referring to 2.
>>>
>>> It would be better to somehow bring those out to an external file and
>>> also be able to specify per-platform overrides/additions.
>>>
>>> I don't think it would be that hard, but it would take some time if you
>>> include all the testing etc that needs to be done.
>>>
>>> If you fancy trying to implement this, that would be good.  To start you
>>> could do something simple/hacky like including a file (perl data
>>> structure) as a string (if it exists) and then merging the data into the
>>> relevant global structures.
>>>
>>> So, for example you could have:
>>>
>>> config/platform/_target_/package_deps.pl, with something like:
>>>
>>> $config_deps = { };
>>> $build_deps = { };
>>> $install_deps = {};
>>>
>>> Of course, fill out your data structure with some content.  Then in the
>>> perl script say:
>>>
>>> if ( my $res = do "config/platform/_target_/package.pl@ ) {
>>>   _merge_results_into_globals_
>>> }
>>>
>>> I wish I had more time to try this out, but too busy right now.  A good
>>> idea though and be great if you could add this.
>>>
>>> Regards, Stuart
>> Stuart, sorry its taken so long to get to this but I've finally had some
>> time to cobble together the ability to have platform-specific package
>> dependencies...
>>
>> Here's an example config/platform/<platform>/package-dep.pl I use:
>>
>> #
>> # Following is a hash of hashes, pulled into LTIB via a "do" statement;
>> # last expression is what is returned (and is expected to be a hash).
>> #
>> # Format is top-level hash of CONFIG_DEPS, BUILD_DEPS, INSTALL_DEPS,
>> # each a hash of package keys with array values (containing quoted
>> # package keys) that are merged into $config_deps, $build_deps,
>> # and $install_deps respectively.
>> #
>> {
>>     CONFIG_DEPS => {
>>            PKG_X_LOADER => [ qw/X_LOADER_CONFIG_TYPE PKG_X_LOADER_BUILD_ARGS
>>                                 X_LOADER_REPOSITORY X_LOADER_SVN_BUILD
>>                                 X_LOADER_SCM_HEAD X_LOADER_SCM_BRANCH
>>                                 X_LOADER_GIT_BUILD
>>                                 X_LOADER_SCM_SKIP_UPDATE
>> BSP_RELEASE_LEVEL/ ],
>>            PKG_U_BOOT => [ qw/BOOTLOADER_SCM_HEAD BOOTLOADER_SCM_BRANCH
>>                                 BOOTLOADER_GIT_BUILD
>>                                 BOOTLOADER_SVN_BUILD
>> BOOTLOADER_SCM_RESPOITORY
>>                                 BSP_RELEASE_LEVEL/ ],
>>            PKG_KERNEL => [ qw/KERNEL_SVN_BUILD KERNEL_GIT_BUILD
>>                                 KERNEL_SCM_REPOSITORY KERNEL_SCM_SKIP_UPDATE
>>                                 KERNEL_SCM_HEAD KERNEL_SCM_BRANCH
>>                                 BSP_RELEASE_LEVEL/ ],
>>     },
>> };
>>
>> Attached is a patch to current LTIB to do this.  My perl fu isn't much
>> better than it was a year ago so there's probably a better way to solve
>> this, but at least it works...  Hope you find it useful; I can see
>> extending this further to have the userspace package dependencies in
>> config/usrspace/package_dep.pl.
>>
>>>
>>>
>>>
>>> On 16/09/11 19:41, Peter Barada wrote:
>>>> Stuart,
>>>>
>>>> Is there an easy way to add a dependency between packages into LTIB? 
>>>> Currently its hard-coded into the ltib perl script and I was wondering
>>>> if there's a way to have the ltib script include an optional script
>>>> from the platform directory (before it goes off building packages) to
>>>> allow a platform to specify inter-package dependencies?
>>>>
>>>> In my world I have modules/packages that depend on the kernel (and
>>>> each other) and figure its a lot easier to have those dependencies be
>>>> corralled into the platform directory as opposed to being in the ltib
>>>> script itself.
>>>>
>>>> I'll be glad to try out stuff, but as my perl fu is pretty weak some
>>>> guidance/suggestions are appreciated.
>>>>
>>>> Thanks in advance!
>>>>
>>> _______________________________________________
>>> LTIB home page: http://ltib.org
>>>
>>> Ltib mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/ltib
>>
>>
>>
>> _______________________________________________
>> LTIB home page: http://ltib.org
>>
>> Ltib mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/ltib
>>


-- 
Peter Barada
address@hidden