2015-12-02 12:27, Panu Matilainen:
> On 12/02/2015 05:57 AM, Thomas Monjalon wrote:
> > The old installed tree was static and always had .config, includes and
> > libs in a RTE_TARGET subdirectory. There is no such directory anymore in
> > an installed SDK. So the top directory is checked.
> > But RTE_TARGET can still be used, especially to build an app with a
> > compiled but not installed SDK.
> > That's why both cases are looked for RTE_SDK_BIN.
[...]
> > The old usage of an installed SDK is:
> > make -C examples/helloworld RTE_SDK=$(readlink -m $DESTDIR) \
> > RTE_TARGET=x86_64-native-linuxapp-gcc
> > RTE_TARGET can be specified but is useless now with an installed SDK.
> > The RTE_SDK directory must now point to a different path depending of
> > the installation.
[...]
> > + $(Q)$(call rte_mkdir, $(DESTDIR)$(sdkdir))
> > + $(Q)cp -a $(BUILD_DIR)/.config $(DESTDIR)$(sdkdir)
> > + $(Q)cp -a $(RTE_SDK)/{mk,scripts} $(DESTDIR)$(sdkdir)
> > + $(Q)$(call rte_symlink, $(DESTDIR)$(includedir),
> > $(DESTDIR)$(sdkdir)/include)
> > + $(Q)$(call rte_symlink, $(DESTDIR)$(libdir),
> > $(DESTDIR)$(sdkdir)/lib)
>
> $(prefix)/share is supposed to be shareable across different
> architectures. Most of the content here is, but at least the lib symlink
> and .config file are not.
The case you want to address is multilib 32/x32/64, right?
> One option is to install .config and the symlinks within $(sdkdir)/$(T)
> directories, then it can be shared across architectures because each
> lives in their own directory. Another possibility is moving the whole
> sdk directory into a subdir in $(libdir), but that misses the
> opportunity to share across architectures (whether anybody actually
> cares is a whole other question :)
Yes, I tried to remove the use of RTE_TARGET when building an example.
But we can keep it with a subdirectory in $(sdkdir).
> $(sdkdir)/lib -> $(libdir) symlink seems reasonable when installing to
> an empty staging root, but on a real-world installation it'd point to
> /usr/lib(something) which has hundreds or thousands of other unrelated
> libraries. My memory is hazy on details but I think this caused an
> actual problem with something because I ended up $(sdkdir)/lib an actual
> directory populated with symlinks to the individual DPDK libraries.
I don't see the problem.
I suggest to keep it and see how to fix it if an issue is raised.
