[dpdk-dev] [PATCH] mk: optimize directory dependencies

Ferruh Yigit ferruh.yigit at intel.com
Tue Jan 24 14:05:08 CET 2017


On 1/23/2017 5:19 PM, Olivier Matz wrote:
> Before this patch, the management of dependencies between directories
> had several issues:
> 
> - the generation of .depdirs, done at configuration is slow: it can take
>   more than one minute on some slow targets (usually ~10s on a standard
>   PC).
> 
> - for instance, it is possible to expressed a dependency like:
>   - app/foo depends on lib/librte_foo
>   - and lib/librte_foo depends on app/bar
>   But this won't work because the directories are traversed with a
>   depth-first algorithm, so we have to choose between doing 'app' before
>   or after 'lib'.
> 
> - the script depdirs-rule.sh is too complex.
> 
> - we cannot use "make -d" for debug, because the output of make is used for
>   the generation of .depdirs.
> 
> This patch moves the DEPDIRS-* variables in the upper Makefile, making
> the dependencies much easier to calculate. A DEPDIRS variable is still
> used to process library dependencies in LDLIBS.
> 
> After this commit, "make config" is almost immediate.
> 
> Signed-off-by: Olivier Matz <olivier.matz at 6wind.com>

Hi Olivier,

It seems both have pros and cons,

Your patch pros,
- faster
- and simpler implementation.

cons,
- Need to update another Makefile in another level to update
dependencies of a library/driver.
- Root level dependencies hardcoded to a mk level makefile.
- removes depgraph target too, not sure how commonly used



Original implementation pros:
- self contained, it manages dependencies of library in same Makefile
- no hardcoded dependencies, all resolved dynamically

cons,
- relatively slower, but not too bad with -j make option.
- complex implementation


I would prefer my version, surprisingly J, but it is good to have
alternatives, and I don't have strong opinion against your patch.

Thanks,
ferruh


More information about the dev mailing list