[dpdk-dev] including rte.app.mk from a Makefile.am

[Stefan Puiu]

On Wed, Feb 24, 2016 at 3:26 AM, Thomas Monjalon
<thomas.monjalon at 6wind.com> wrote:

> Yes it is prefixed when used instead of assignment.
> In 2.2, it is better fixed:
>
> ifeq ($(LINK_USING_CC),1)
> override EXTRA_LDFLAGS := $(call linkerprefix,$(EXTRA_LDFLAGS))
> O_TO_EXE = $(CC) $(CFLAGS) $(LDFLAGS_$(@)) \
>     -Wl,-Map=$(@).map,--cref -o $@ $(OBJS-y) $(call linkerprefix,$(LDFLAGS)) \
>     $(EXTRA_LDFLAGS) $(call linkerprefix,$(LDLIBS))
>
> So everything is properly prefixed.
>
> Could you please better describe your issue?
> Is $(LINK_USING_CC) true in your case?

Yes, everything would be perfect if the O_TO_EXE part was used. As far
as I can tell, that's not how automake works.

You just set bin_programs, <prog>_SOURCES, <prog>_CFLAGS and then it
generates the Makefile code to build your stuff, which is different
from the above thing; it also uses LDFLAGS, which it treats as a user
variable. In 1.7.1, LDFLAGS is prefixed properly. In 2.2, it's not
prefixed, so the build system ends up calling gcc with linker options.

I'm not implying this is something that should be fixed in the DPDK; I
was just trying to see how others handle this.

>
> Yes, mk/rte.app.mk is primarily used by internal apps.
> If an external app don't want to use the DPDK makefiles, it should be
> possible to use pkgconfig on DPDK. I hadn't time yet to write a patch for
> pkgconfig support, so any contribution is welcome.

I'm not very familiar with pkgconfig, but if it can supply some *FLAGS
to build against, then it sounds good. I've worked on a project where
we built with scons, so including mk files wasn't much of an option.

Thanks,
Stefan.