[dpdk-dev] [PATCH 03/10] mk: install a standard cutomizable tree

Panu Matilainen pmatilai at redhat.com
Wed Dec 2 11:27:07 CET 2015


On 12/02/2015 05:57 AM, Thomas Monjalon wrote:
> The rule "install" follows these conventions:
> https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
> https://www.gnu.org/prep/standards/html_node/DESTDIR.html
>
> The variable sdkdir has been added to the more standards ones,
> to configure the directory used with RTE_SDK when using the DPDK makefiles
> to build an application.
>
> 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 default prefix /usr/local is empty in the T= case which is
> used only for a local install.
> It is still possible to build DPDK with the "install T=" rule without
> specifying any DESTDIR. In such case there is no install, as before.
>
> 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.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon at 6wind.com>
> ---
[...]
> @@ -32,10 +33,30 @@
>   # Build directory is given with O=
>   O ?= .
>
> +prefix      ?=     /usr/local
> +exec_prefix ?=      $(prefix)
> +bindir      ?= $(exec_prefix)/bin
> +libdir      ?= $(exec_prefix)/lib
> +includedir  ?=      $(prefix)/include/dpdk
> +datarootdir ?=      $(prefix)/share
> +datadir     ?=       $(datarootdir)/dpdk
> +sdkdir      ?= $(datadir)
> +
> +# The install directories may be staged in DESTDIR
[...]
> +	@echo ================== Installing $(DESTDIR)$(prefix)/
> +	$(Q)$(call rte_mkdir, $(DESTDIR)$(libdir))
> +	$(Q)cp -a $(BUILD_DIR)/lib/* $(DESTDIR)$(libdir)
> +	$(Q)$(call rte_mkdir, $(DESTDIR)$(bindir))
> +	$(Q)tar -cf -      -C $(BUILD_DIR) app  --exclude 'app/*.map' \
> +		--exclude 'app/cmdline*' --exclude app/test \
> +		--exclude app/testacl --exclude app/testpipeline | \
> +	    tar -xf -      -C $(DESTDIR)$(bindir) --strip-components=1 \
> +		--keep-newer-files --warning=no-ignore-newer
> +	$(Q)$(call rte_mkdir,      $(DESTDIR)$(datadir))
> +	$(Q)cp -a $(RTE_SDK)/tools $(DESTDIR)$(datadir)
> +	$(Q)$(call rte_mkdir, $(DESTDIR)$(includedir))
> +	$(Q)tar -chf -     -C $(BUILD_DIR) include | \
> +	    tar -xf -      -C $(DESTDIR)$(includedir) --strip-components=1 \
> +		--keep-newer-files --warning=no-ignore-newer
> +	$(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)
> +	@echo Installation in $(DESTDIR)$(prefix)/ complete
> +endif

$(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.

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 :)

$(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.

	- Panu -


More information about the dev mailing list