[dpdk-dev] Fw: dpdk-armv7 - Build # 342 - Failure!

[Thomas Monjalon]

2016-03-11 14:53, Sergio Gonzalez Monroy:
> On 11/03/2016 13:33, Thomas Monjalon wrote:
> > 2016-03-11 11:47, Sergio Gonzalez Monroy:
> >> On 11/03/2016 11:39, Jan Viktorin wrote:
> >>> Hello Sergio,
> >>>
> >>> I've detected a build regression for the ARMv7. It seems to me the
> >>> source of the problem is the following commit:
> >>>
> >>>    http://dpdk.org/browse/dpdk/commit/?id=d299106e8e31a622b3a1c1653f7795fa8a55860e
> >>>
> >>> The ipsec-secgw should be compiled only when LPM is enabled. See, eg.
> >>> how the l3fwd-power example is done in examples/Makefile.
> >> Right!
> >>
> >> Actually the app has dependencies on a few libraries, so I'll fix that.
> > Please take the opportunity to move the crypto examples in the
> > alphabetical order in this Makefile. Thanks
> >
> >
> 
> So the fix is easy enough but I'm really not a fan of cluttering the 
> examples/Makefile ifeq checks
> which would only avoid building ipsec-secgw if doing:
> $ make examples
> 
> but would still fail to build if doing something like:
> $ make -C examples/ipsec-secgw

If you explicitly want to build this example, it is normal to fail.

> examples/Makefile:
> +ifeq ($(CONFIG_RTE_LIBRTE_ACL),y)
> +ifeq ($(CONFIG_RTE_LIBRTE_HASH),y)
> +ifeq ($(CONFIG_RTE_LIBRTE_LPM),y)
> DIRS-$(CONFIG_RTE_LIBRTE_CRYPTODEV) += ipsec-secgw
> +endif
> +endif
> +endif

You can do it in one line:
ifeq ($(CONFIG_RTE_LIBRTE_ACL)$(CONFIG_RTE_LIBRTE_HASH)$(CONFIG_RTE_LIBRTE_LPM),yyy)

> Another way to achive this and also avoid building the app with 'make -C 
> ...' is something like this:
> 
> examples/ipsec-secgw/Makefile:
> +all:
> +%:
> 
> +ifeq ($(CONFIG_RTE_LIBRTE_ACL),y)
> +ifeq ($(CONFIG_RTE_LIBRTE_HASH),y)
> +ifeq ($(CONFIG_RTE_LIBRTE_LPM),y)
> +ifeq ($(CONFIG_RTE_LIBRTE_CRYPTODEV),y)
> include $(RTE_SDK)/mk/rte.extapp.mk
> +endif
> +endif
> +endif
> +endif

No, as said above, you should not be smart here and let it fail.
 
> Anyway, none of those are the right fix, which I think should be 
> something along the lines of Kconfig.

Yes maybe one day...

> Any preference?

First one