[dpdk-dev] [PATCH v3 06/13] mk: split install rule
Hi Thomas,
I'm testing this set of patches that has been applied, and I haven't noticed
before
that you exclude some binaries in "install-runtime" (test, testpipeline,
testacl etc...), I would like
to ask you the reason about this :)
Thanks.
Mario.
From: Thomas Monjalon [thomas.monja...@6wind.com]
Sent: Thursday, December 03, 2015 5:45 AM
To: dev at dpdk.org
Cc: olivier.matz at 6wind.com; Arevalo, Mario Alfredo C; Richardson, Bruce;
Panu Matilainen
Subject: [PATCH v3 06/13] mk: split install rule
Provides new sub-rules to install runtime and sdk separately.
The build directory must be changed from BUILD_DIR to O in install
rules to avoid a bad recursive effect (O being BUILD_DIR being O + T).
Suggested-by: Mario Carrillo
Signed-off-by: Thomas Monjalon
Acked-by: Panu Matilainen
---
mk/rte.sdkinstall.mk | 18 --
mk/rte.sdkroot.mk| 2 ++
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
index dc57baf..ec093d3 100644
--- a/mk/rte.sdkinstall.mk
+++ b/mk/rte.sdkinstall.mk
@@ -93,25 +93,31 @@ ifeq ($(DESTDIR)$(if $T,,+),)
@echo Installation cannot run with T defined and DESTDIR undefined
else
@echo == Installing $(DESTDIR)$(prefix)/
+ $(Q)$(MAKE) O=$(RTE_OUTPUT) T= install-runtime
+ $(Q)$(MAKE) O=$(RTE_OUTPUT) T= install-sdk
+ @echo Installation in $(DESTDIR)$(prefix)/ complete
+endif
+
+install-runtime:
$(Q)$(call rte_mkdir, $(DESTDIR)$(libdir))
- $(Q)cp -a $(RTE_OUTPUT)/lib/* $(DESTDIR)$(libdir)
+ $(Q)cp -a$O/lib/* $(DESTDIR)$(libdir)
$(Q)$(call rte_mkdir, $(DESTDIR)$(bindir))
- $(Q)tar -cf - -C $(RTE_OUTPUT) app --exclude 'app/*.map' \
+ $(Q)tar -cf - -C $O 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)
+
+install-sdk:
$(Q)$(call rte_mkdir, $(DESTDIR)$(includedir))
- $(Q)tar -chf - -C $(RTE_OUTPUT) include | \
+ $(Q)tar -chf - -C $O 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 $(RTE_SDK)/{mk,scripts} $(DESTDIR)$(sdkdir)
$(Q)$(call rte_mkdir,$(DESTDIR)$(targetdir))
- $(Q)cp -a $(RTE_OUTPUT)/.config$(DESTDIR)$(targetdir)
+ $(Q)cp -a $O/.config $(DESTDIR)$(targetdir)
$(Q)$(call rte_symlink, $(DESTDIR)$(includedir),
$(DESTDIR)$(targetdir)/include)
$(Q)$(call rte_symlink, $(DESTDIR)$(libdir),
$(DESTDIR)$(targetdir)/lib)
- @echo Installation in $(DESTDIR)$(prefix)/ complete
-endif
diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk
index 533afe9..2424dce 100644
--- a/mk/rte.sdkroot.mk
+++ b/mk/rte.sdkroot.mk
@@ -97,6 +97,8 @@ test fast_test ring_test mempool_test perf_test coverage:
install:
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk pre_install
$(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
+install-%:
+ $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@
.PHONY: doc help
doc: doc-all
--
2.5.2
[dpdk-dev] [PATCH v2 00/12] standard make install
Hi Thomas, In general looks good :), I'm going to test this serie and sounds good the feedback from other developers, maybe I'm going to send a version number 9 in order to get a good way together :) Thanks :) Mario. From: Thomas Monjalon [thomas.monja...@6wind.com] Sent: Thursday, December 03, 2015 5:34 AM To: Panu Matilainen; Arevalo, Mario Alfredo C Cc: dev at dpdk.org; olivier.matz at 6wind.com; Richardson, Bruce Subject: Re: [PATCH v2 00/12] standard make install 2015-12-03 15:26, Panu Matilainen: > On 12/03/2015 07:01 AM, Thomas Monjalon wrote: > > Following the recent discussions, this is a proposal to have a standard > > installation process while keeping compatibility with most of the old > > behaviours. > > > > v2 changes: > > - fix default build dir > > - RTE_TARGET subdir in $(sdkdir). > > - better kerneldir defaults > > - fix dpdk_nic_bind symlink > > - always install doc if generated > > - doc > > - pkg/dpdk.spec > > > > Except for the minor nit about examples location (one could bikeshed on > things like these forever), seems fine to me and quick-n-dirty > conversion of my own spec didn't reveal any nasty surprises. > > It also appears more comprehensive and integrated with other workflows > than the competing patches so FWIW, you have my ACK :) Thank you. I'm going to send a v3. Mario, what is your opinion about this series?
[dpdk-dev] [PATCH v8 00/11] Add installation rules for dpdk files.
Thank you, I'm going to take note about it for a version number 9 :) Thanks. Mario. From: Panu Matilainen [pmati...@redhat.com] Sent: Wednesday, December 02, 2015 1:33 AM To: Arevalo, Mario Alfredo C; dev at dpdk.org Cc: Venegas Munoz, Jos C Subject: Re: [dpdk-dev] [PATCH v8 00/11] Add installation rules for dpdk files. On 12/01/2015 09:39 PM, Mario Carrillo wrote: > DPDK package lacks of a mechanism to install libraries, headers > applications, kernel modules and sdk files to a file system tree. > This patch set allows to install files based on the next > proposal: > http://www.freedesktop.org/software/systemd/man/file-hierarchy.html > > v8: > > When "make install" is invoked if "T" variable is defined, > the installation process will have the current > behaviour, else "install-fhs" rule will be called. > > Using rules support is possible to do the next steps: > > make config T= > make > make > > Modify the makefile target to specify the files > that will be installed using a rule: > > * make install-bin (install app files)(dafault path > bindir=$(exec_prefix)/bin). > > * make install-headers (install headers)(dafault path > includedir=$(prefix)/include/dpdk). > > * make install-lib (install libraries)(dafault path > libdir=$(exec_prefix)/lib). > > * make install-doc (install documentation)(dafault path > docdir=$(datarootdir)/doc/dpdk). > > * make install-mod (install modules)(dafault path if RTE_EXEC_ENV=linuxapp > then > kerneldir=/lib/modules/$(uname -r)/extra/drivers/dpdk else > kerneldir=/boot/modules). > > * make install-sdk (install headers, makefiles, scripts,examples and > config files) (default path sdkdir=$(datadir)/share/dpdk). > > * make install-fhs (install libraries, modules, app files, tools and > documentation). > > * make install (if T is defined current behaviour, else it will call > install-fhs rule). > > The following defaults apply: > > prefix=/usr/local > exec_prefix=$(prefix) > datarootdir=$(prefix)/share > > All path variables can be overridden and all targets can use the "DESTDIR" > variable. > > Furthermore this information is added to documentation. Overall, does what it promises. One point I just realized from comparing with Thomas' variant is that this by default installs documentation sources, ie the raw .rst files and does not include any "compiled" formats even if they exist. It might be better to leave docs out by default as Thomas' version does. One way of achieving that is only install docs if $(RTE_OUTPUT)/doc, and only install anything in that directory. That way you have to request doc generation specifically with "make doc" first (which has quite some build-dependencies so you might not always wnat it), and only the compiled docs get installed. Or something like that. - Panu -
[dpdk-dev] [PATCH v7 00/11] Add installation rules for dpdk files.
Hi Thomas, Thank you for your answer, John Mcnamara gave feedback about documentation in this version (7) and I'm going to send a version number 8 with new changes about documentation, it would be amazing if you could take a look it :) thank you for your attention. Mario. From: Thomas Monjalon [thomas.monja...@6wind.com] Sent: Tuesday, December 01, 2015 11:17 AM To: Arevalo, Mario Alfredo C Cc: dev at dpdk.org; olivier.matz at 6wind.com; miguel.bernal.marin at linux.intel.com; Venegas Munoz, Jos C; Richardson, Bruce; david.marchand at 6wind.com Subject: Re: [PATCH v7 00/11] Add installation rules for dpdk files. Hi Mario, Thanks for your work. There are some interesting ideas :) I'm going to send a patchset to establish the same kind of rules keeping the old install behaviour and allowing a standard one with the same name (install). The result would be closed to what pkg/dpdk.spec provides. Your review would be appreciated.
[dpdk-dev] [PATCH v7 11/11] doc: Add information about new installation rules
Hi John, Thank you so much for your comments about documentation patches, I have taken note for the next version :) Thanks. Mario. From: Mcnamara, John Sent: Tuesday, December 01, 2015 4:08 AM To: Arevalo, Mario Alfredo C; dev at dpdk.org Cc: Venegas Munoz, Jos C Subject: RE: [dpdk-dev] [PATCH v7 11/11] doc: Add information about new installation rules > -Original Message- > From: Mcnamara, John > Sent: Tuesday, December 1, 2015 11:12 AM > To: 'Mario Carrillo'; dev at dpdk.org > Cc: Venegas Munoz, Jos C > Subject: RE: [dpdk-dev] [PATCH v7 11/11] doc: Add information about new > installation rules > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Mario Carrillo > > Sent: Tuesday, December 1, 2015 12:53 AM > > To: dev at dpdk.org > > Cc: Venegas Munoz, Jos C > > Subject: [dpdk-dev] [PATCH v7 11/11] doc: Add information about new > > installation rules > > > > Information about variables and rules behaviour is added to > documentation. > > Hi, > > Thanks for the documentation. Some comments below. Hi, You also need to mark the v6 versions as Superseded: http://dpdk.org/dev/patchwork/project/dpdk/list/?submitter=Mario+Carrillo John. --
[dpdk-dev] [PATCH v6 06/10] mk: Add rule for installing sdk files
Thank you for your feedback Thomas, I'm going to take note for a version 6 patches :) Mario. From: Thomas Monjalon [thomas.monja...@6wind.com] Sent: Monday, November 30, 2015 8:20 AM To: Arevalo, Mario Alfredo C Cc: dev at dpdk.org; Venegas Munoz, Jos C Subject: Re: [dpdk-dev] [PATCH v6 06/10] mk: Add rule for installing sdk files Hi, 2015-11-10 11:07, Mario Carrillo: > Add hierarchy-file support to the DPDK makefiles, scripts, > examples, tools, config files and headers, > when invoking "make install-sdk" makefiles, scripts, > examples, tools, config files will be installed in: The tools are part of the runtime, not the sdk. > $(DESTDIR)/$(SDK_DIR) > and headers will be installed in: > $(DESTDIR)/$(INCLUDE_DIR) > where SDK_DIR=$(RTE_PREFIX)/share/dpdk, > INCLUDE_DIR=$(RTE_PREFIX)/include/dpdk > RTE_PREFIX=/usr/local by default, you can override RTE_PREFIX, SDK_DIR > and INCLUDE_DIR vars. > This hierarchy is based on: > http://www.freedesktop.org/software/systemd/man/file-hierarchy.html It would be better to follow the GNU standard to name the variables: https://www.gnu.org/prep/standards/html_node/Directory-Variables.html https://www.gnu.org/prep/standards/html_node/DESTDIR.html prefix ?= /usr/local exec_prefix ?= $(prefix) bindir ?= $(exec_prefix)/bin sbindir ?= $(exec_prefix)/sbin libdir ?= $(exec_prefix)/lib includedir ?= $(prefix)/include/dpdk datarootdir ?= $(prefix)/share docdir ?= $(datarootdir)/doc/dpdk datadir ?= $(datarootdir)/dpdk I would add: kerneldir ?= $(exec_prefix)/kmod sdkdir ?= $(datadir)
[dpdk-dev] [PATCH 7/7] mk: Add hierarchy-file support (linux mod)
Hi ferruh, thank you for your comments in this serie of patches :) , I have been working on different new patches version in order to improve them according to feedback from different developers, at this moment I have sent the version 6 I would like to know your point of view and the point of view from more developers about it :) this is the link where you can see the 6 version: http://dpdk.org/ml/archives/dev/2015-November/027988.html Thank you. Mario. From: dev [dev-bounces at dpdk.org] on behalf of Ferruh Yigit [ferruh.yi...@intel.com] Sent: Friday, November 27, 2015 8:01 AM To: Thomas Monjalon Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH 7/7] mk: Add hierarchy-file support (linux mod) On Fri, Nov 27, 2015 at 04:40:51PM +0100, Thomas Monjalon wrote: > 2015-09-22 09:56, Panu Matilainen: > > On 09/18/2015 11:33 PM, Mario Carrillo wrote: > > > +MOD_DIR := $(DESTDIR)/lib/modules > > > +KERNEL_DIR := $(shell uname -r)/extra > > > > Please don't assume one is always building for the running kernel. > > Defaulting around uname -r is perfectly reasonable, but there needs to > > be a way to override it from the cli. For example rte.vars.mk has this: > > > > # can be overriden by make command line or exported environment variable > > RTE_KERNELDIR ?= /lib/modules/$(shell uname -r)/build > > For info, the ?= operator is a way to give a default value after having > included other makefiles which may set a different value. > Both ?= and := (or simply =) are overriden by the command line. > Only "override VAR =" will not be overriden by the command line. > As far as I know only "?=" assignment overridden by command line. Basic experiment: # cat Makefile A ?= a B := b C = c all: @echo $(A) $(B) $(C) - # make a b c # A=x B=x C=x make x b c ferruh
[dpdk-dev] [PATCH v6 00/10] Add installation rules for dpdk files
Hi Bruce, First thank you for your help during this time, and you are right, the objective of this is try to have a more standard installation process, I have taken a look to your patches, and you rename targets as first step in order to improve the installation process, I have the same intentions, talking about my patch set, you can see different new targets in the makefile, this seem that is more complex, but the reason about it is for flexibility, you can install only relevant files for you that could be headers, libraries, makefiles, examples etc... in hierarchy paths by default and you can overridden these paths, however if you would like to install sdk files (install headers, makefiles, scripts,examples, tools and config files) you can use "install-sdk" or if you would like to install runtime files (libraries, modules, app files, nic bind files and documentation) "install-fhs" will be enough :) I mean, it's no necessary to use all targets by separate. this behavior can be obtained if you do not use "T" variable, if you use it you can get the previous behaviour in dpdk, this is for compatibility reasons. thank you for your comments and if you have more questions about this feel free to contact me :) Thank you so much. Mario. > -Original Message- > From: Richardson, Bruce > Sent: Wednesday, November 11, 2015 4:49 AM > To: Arevalo, Mario Alfredo C > Cc: Aaron Conole; dev at dpdk.org; Venegas Munoz, Jos C > Subject: Re: [dpdk-dev] [PATCH v6 00/10] Add installation rules for dpdk files > > On Tue, Nov 10, 2015 at 11:25:39PM +, Arevalo, Mario Alfredo C wrote: > > Hi Aaron, > > > > > > I have been working on series of patches in order to improve the > > installation process of dpdk, I sent my first version at sep 18. > > > > http://dpdk.org/ml/archives/dev/2015-September/023761.html > > > > I have been received feedback from different developers as Olivier, > > Bruce, Panu etc... and I have been taking note about it and I have > > been improving the patches in each serie, at this moment I haven't > > gotten a final answer, however I'm going to continue working. :) > > > > Mario. > > Thanks. > > Hi Mario, > > it would be good if you could share your opinions of the patchset that Aaron > linked to below, and how it might interact with or impact your patchset - or > if > you even think it's not worthwhile doing. There's been a worrying lack of > comment on that thread! > > On your patchset, I'm just not convinced that adding in a whole set of new > make targets is the best way to go here. It seems more like putting an extra > layer of complexity in without fixing the underlying problems [which to me is > the fact of "make install" being used in a non-standard way.] > > Regards, > /Bruce > > > > > From: Aaron Conole [aconole at redhat.com] > > Sent: Tuesday, November 10, 2015 9:18 AM > > To: Arevalo, Mario Alfredo C > > Cc: dev at dpdk.org; Venegas Munoz, Jos C; Richardson, Bruce > > Subject: Re: [dpdk-dev] [PATCH v6 00/10] Add installation rules for > > dpdk files > > > > Hi Mario, > > > > Mario Carrillo writes: > > > DPDK package lacks of a mechanism to install libraries, headers > > > applications, kernel modules and sdk files to a file system tree. > > > This patch set allows to install files based on the next > > > proposal: > > > http://www.freedesktop.org/software/systemd/man/file- > hierarchy.html > > > > I'm not sure what this patch holds, given the following proposal: > > > > http://dpdk.org/ml/archives/dev/2015-November/02.html > > > > -Aaron > >
[dpdk-dev] [PATCH v6 00/10] Add installation rules for dpdk files
Hi Aaron, I have been working on series of patches in order to improve the installation process of dpdk, I sent my first version at sep 18. http://dpdk.org/ml/archives/dev/2015-September/023761.html I have been received feedback from different developers as Olivier, Bruce, Panu etc... and I have been taking note about it and I have been improving the patches in each serie, at this moment I haven't gotten a final answer, however I'm going to continue working. :) Mario. Thanks. From: Aaron Conole [acon...@redhat.com] Sent: Tuesday, November 10, 2015 9:18 AM To: Arevalo, Mario Alfredo C Cc: dev at dpdk.org; Venegas Munoz, Jos C; Richardson, Bruce Subject: Re: [dpdk-dev] [PATCH v6 00/10] Add installation rules for dpdk files Hi Mario, Mario Carrillo writes: > DPDK package lacks of a mechanism to install libraries, headers > applications, kernel modules and sdk files to a file system tree. > This patch set allows to install files based on the next > proposal: > http://www.freedesktop.org/software/systemd/man/file-hierarchy.html I'm not sure what this patch holds, given the following proposal: http://dpdk.org/ml/archives/dev/2015-November/02.html -Aaron
[dpdk-dev] dpdk proposal installation process
> -Original Message- > From: Richardson, Bruce > Sent: Thursday, October 22, 2015 9:57 AM > To: Panu Matilainen > Cc: Olivier MATZ; Arevalo, Mario Alfredo C; dev at dpdk.org > Subject: Re: [dpdk-dev] dpdk proposal installation process > > On Thu, Oct 22, 2015 at 08:55:41AM +0300, Panu Matilainen wrote: > > On 10/21/2015 10:15 PM, Olivier MATZ wrote: > > >Hi Mario, > > > > > >On 10/20/2015 11:17 AM, Bruce Richardson wrote: > > >>On Tue, Oct 20, 2015 at 12:21:00AM +, Arevalo, Mario Alfredo C > wrote: > > >>>Hi folks, > > >>> > > >>> Good day, this is a proposal in order to improve the dpdk > > >>>install process, I would like to know your point of view about the > > >>>next points according to previous conversations :) in order to create a > new patches version. > > >>> > > >>>1) I think the first thing that I have to be aware is > > >>>"compatibility", the new changes won't affect the current dpdk > behaviour. > > > > > >Yes. As I stated in a previous mail, I think nobody uses the current > > >"make install" without specifying T= as the default value is to build > > >and install for all targets. > > > > > >My suggestion is: > > > > > >- rename the previous "install" target. The name could probably > > > be "mbuild" (for multiple builds). Other ideas are welcome. > > > > > >- when "make install" is invoked with T= argument, call the mbuild > > > target to have the same behavior than before. This compat layer > > > could be removed in the future. > > > > > >- when "make install" is invoked without T=, it installs the fhs. > > > > Nice, this sounds like the best of both worlds. > > > > > > > >>>2) Create new makefile rules, these rules is going to install dpdk > > >>>files in default paths, however the linux distributions don't use > > >>>the same paths for their files, the linux distribution and the > > >>>architecture can be factor for different path as Panu commented in > > >>>previous conversations, he is right, then all variables could be > overridden, the variables names for the user can be included in > documentation. > > >>>Also an option could be a configuration file for paths, however I'm not > sure. > > > > > >I think having variables is ok. > > > > > >>>3) The default paths for dpdk in order to follow a hierarchy, > > >>>however the variable with those values can be overridden. > > >>> > > >>>-install-bin --> /usr/bin. > > >>>-install-headers --> /usr/include/dpdk > > >>>-install-lib --> /usr/lib64 > > > > > >I remember Panu suggested to have /usr/lib by default. > > >I also think /usr/lib a better default value: some distributions use > > >/usr/lib for 64 bits libs, but we never have 32 bits libs in > > >/usr/lib64. > > > > Yes, just stick /usr/lib there and be done with it, lib64 is not a > > good default for these very reasons. > > > > >>>-install-doc --> /usr/share/doc/dpdk > > >>>-install-mod--> if RTE_EXEC_ENV=linuxapp then > KERNEL_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk > > >>> else KERNEL_DIR=/boot/modules). > > > > > >I'm not sure KERNEL_DIR is the proper name. Maybe KMOD_DIR? > > > > > >>>-install-sdk --> /usr/share/dpdk and call install-headers ). > > >>>-install-fhs --> call install-libraries, install-mod, > > >>>install-bin and install- > doc (maybe install-headers) > > >>> > > >>>4) I'm going to take account all feedback about variables, paths etc for > the new version :). > > >>> > > >>>Thank you so much for your help. > > >>> > > >>> > > >>>Mario. > > >> > > >>Hi Mario, > > >> > > >>that seems like a lot of commands to add - are they all individually > needed? > > >> > > >>In terms of where things go, should the "usr" part not a) be > > >>configurable via a parameter, and b) default to "/usr/local" as > > >>that's where user-installed software from outside the packaging system
[dpdk-dev] dpdk proposal installation process
Hi folks, Good day, this is a proposal in order to improve the dpdk install process, I would like to know your point of view about the next points according to previous conversations :) in order to create a new patches version. 1) I think the first thing that I have to be aware is "compatibility", the new changes won't affect the current dpdk behaviour. 2) Create new makefile rules, these rules is going to install dpdk files in default paths, however the linux distributions don't use the same paths for their files, the linux distribution and the architecture can be factor for different path as Panu commented in previous conversations, he is right, then all variables could be overridden, the variables names for the user can be included in documentation. Also an option could be a configuration file for paths, however I'm not sure. 3) The default paths for dpdk in order to follow a hierarchy, however the variable with those values can be overridden. -install-bin --> /usr/bin. -install-headers --> /usr/include/dpdk -install-lib --> /usr/lib64 -install-doc --> /usr/share/doc/dpdk -install-mod--> if RTE_EXEC_ENV=linuxapp then KERNEL_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk else KERNEL_DIR=/boot/modules). -install-sdk --> /usr/share/dpdk and call install-headers ). -install-fhs --> call install-libraries, install-mod, install-bin and install-doc (maybe install-headers) 4) I'm going to take account all feedback about variables, paths etc for the new version :). Thank you so much for your help. Mario.
[dpdk-dev] [PATCH v4 5/7] mk: Add rule for installing documentation
Hi Olivier, Ooops I'm going to fix that :) Thanks. Mario. From: Olivier MATZ [olivier.m...@6wind.com] Sent: Friday, October 16, 2015 12:30 PM To: Arevalo, Mario Alfredo C; dev at dpdk.org Subject: Re: [PATCH v4 5/7] mk: Add rule for installing documentation Hi Mario, On 10/05/2015 10:20 PM, Mario Carrillo wrote: > Add hierarchy-file support to the DPDK documentation. > > When invoking "make install-doc" documentation files will > be installed in: $(DESTDIR)/$(DOC_DIR) where > DOC_DIR=$(DESTDIR)/usr/share/doc/dpdk by default. > > You can override DOC_DIR var. > This hierarchy is based on: > http://www.freedesktop.org/software/systemd/man/file-hierarchy.html > > Signed-off-by: Mario Carrillo > --- > mk/rte.sdkinstall.mk | 14 ++ > mk/rte.sdkroot.mk| 6 -- > 2 files changed, 18 insertions(+), 2 deletions(-) > > diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk > index 628d9fb..d917329 100644 > --- a/mk/rte.sdkinstall.mk > +++ b/mk/rte.sdkinstall.mk > @@ -44,12 +44,14 @@ T=* > ifneq (,$(wildcard $(BUILD_DIR)/build/.config)) > INCLUDE_DIR ?= /usr/include/dpdk > BIN_DIR ?= /usr/bin > +DOC_DIR ?= /usr/share/doc/dpdk > HSLINKS := $(wildcard $(RTE_OUTPUT)/include/*) > BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*)) > NIC_FILES := $(wildcard $(BUILD_DIR)/tools/*.py) > BINARY_FILES += $(NIC_FILES) > LIBS := $(wildcard $(RTE_OUTPUT)/lib/*) > MODULES := $(wildcard $(RTE_OUTPUT)/kmod/*) > +DOCS := $(wildcard $(BUILD_DIR)/doc/*) > include $(BUILD_DIR)/build/.config > RTE_ARCH := $(CONFIG_RTE_ARCH:"%"=%) > RTE_EXEC_ENV := $(CONFIG_RTE_EXEC_ENV:"%"=%) > @@ -148,6 +150,18 @@ install-mod: > echo installing: $$MOD; \ > done > # > +# install documentation in /usr/share/doc/dpdk > +# bu default, DOC_DIR can be overriden. > +# small typo here (bu -> by) Regards, Olivier
[dpdk-dev] [PATCH v4 1/7] mk: Add rule for installing headers
Hi Olivier, thank you for your feedback , more comments below :)
Thanks.
Mario.
From: Olivier MATZ [olivier.m...@6wind.com]
Sent: Friday, October 16, 2015 12:29 PM
To: Arevalo, Mario Alfredo C; dev at dpdk.org
Cc: Panu Matilainen
Subject: Re: [PATCH v4 1/7] mk: Add rule for installing headers
Hi Mario,
Thank you for this patch series, and thank you Panu for the
good comments on this series.
Please see some comments below.
On 10/05/2015 10:20 PM, Mario Carrillo wrote:
> Add hierarchy-file support to the DPDK headers.
>
> When invoking "make install-headers" headers will
> be installed in: $(DESTDIR)/$(INCLUDE_DIR)
> where INCLUDE_DIR=/usr/include/dpdk by default.
>
> You can override INCLUDE_DIR var.
> This hierarchy is based on:
> http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
>
> Signed-off-by: Mario Carrillo
> ---
> mk/rte.sdkinstall.mk | 18 +-
> mk/rte.sdkroot.mk| 4 ++--
> 2 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
> index 86c98a5..f016171 100644
> --- a/mk/rte.sdkinstall.mk
> +++ b/mk/rte.sdkinstall.mk
> @@ -41,6 +41,10 @@ endif
> # x86_64-native-*-gcc
> ifndef T
> T=*
> +ifneq (,$(wildcard $(BUILD_DIR)/build/.config))
What about using $(RTE_OUTPUT) here instead of $(BUILD_DIR)/build ?
With you patch, the following commands work:
make config T=x86_64-native-linuxapp-gcc
make -j32
make install-headers DESTDIR=install
Replacing all the occurences of $(BUILD_DIR)/build by $(RTE_OUTPUT)
would also make the following commands work:
make config T=x86_64-native-linuxapp-gcc O=build2
make -j32 O=build2
make install-headers O=build2 DESTDIR=install2
Note: the default value of RTE_OUTPUT is set to $(RTE_SRCDIR)/build
in mk/rte.sdkroot.mk
We also need to to replace other occurences of $(BUILD_DIR), please
see my comment on patch 2/7.
[Mario]: Yes, you right, I can replace it :)
> +INCLUDE_DIR ?= /usr/include/dpdk
> +HSLINKS := $(wildcard $(RTE_OUTPUT)/include/*)
> +endif
> endif
>
> #
> @@ -72,7 +76,19 @@ install: $(INSTALL_TARGETS)
> echo "Using local configuration"; \
> fi
> $(Q)$(MAKE) all O=$(BUILD_DIR)/$*
> -
> +#
> +# install headers in /usr/include/dpdk by default
> +# INCLUDE_DIR can be overridden.
> +#
> +.PHONY: install-headers
> +install-headers:
> + @echo == Installing headers;
> + @[ -d $(DESTDIR)/$(INCLUDE_DIR) ] || mkdir -p $(DESTDIR)/$(INCLUDE_DIR)
I think it's useless to do the [ -d $(DESTDIR)/$(INCLUDE_DIR) ] as the
'mkdir -p' will do it as well.
But maybe it could be useful to check:
[ "$${HSLINKS}" != "" ]
This would solve the issue described by Panu about the directories
created even if they are empty.
[Mario]: Sounds good, that can solve the problem.
> + @for HSLINK in ${HSLINKS}; do \
Not sure to understand what is the meaning of HSLINK?
HS = headers?
[Mario]: HSLINKS= headers links, in dpdk installation, it creates links to
headers, however for installation I would like
to get the headers paths and copy them to installation path, not create links
:) .
Regards,
Olivier
[dpdk-dev] [PATCH v4 0/7] Add instalation rules for dpdk files.
Hi, Good day, I was wondering if someone has any comment about it :) Thank you. Mario From: Arevalo, Mario Alfredo C Sent: Monday, October 05, 2015 1:19 PM To: dev at dpdk.org Cc: olivier.matz at 6wind.com; Arevalo, Mario Alfredo C Subject: [PATCH v4 0/7] Add instalation rules for dpdk files. DPDK package lacks of a mechanism to install libraries, headers applications, kernel modules and sdk files to a file system tree. This patch set allows to install files according to the next proposal: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html however this patch set does not affect the current dpdk behavior. Using rules support is possible to do the next steps: make config T=TARGET make make INSTALL-TARGET v4: Modify the makefile target to specify the files that will be installed using a rule: * make install-bin (install app files)(dafault path BIN_DIR=/usr/bin). * make install-headers (install headers)(dafault path INCLUDE_DIR=/usr/include/dpdk). * make install-lib (install libraries)(dafault path if the architecture is 64 bits is LIB_DIR=/usr/lib64 else LIB_DIR=/usr/lib). * make install-doc (install documentation)(dafault path DOC_DIR=/usr/share/doc/dpdk). * make install-mod (install modules)(dafault path if RTE_EXEC_ENV=linuxapp then KERNEL_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk else KERNEL_DIR=/boot/modules). * make install-sdk (install headers, makefiles, scripts,examples, tools and config files) (default path DATA_DIR=/usr/share/dpdk). * make install-fhs (install libraries, modules, app files, nic bind files and documentation). Also you can use the DESTDIR variable. All directory variables mentioned above can be overridden: (BIN_DIR, LIB_DIR, INCLUDE_DIR, DOC_DIR, KERNEL_DIR and DATA_DIR). v3: Modify the makefile target to specify the files that will be installed using a rule: make install-bin (install app files)(dafault path BIN_DIR=/usr/bin). make install-headers (install headers)(dafault path INCLUDE_DIR=/usr/include/dpdk). make install-lib (install libraries)(dafault path if the architecture is 64 bits is LIB_DIR=/usr/lib64 else LIB_DIR=/usr/lib). make install-sbin (install nic bind files)(dafault path SBIN_DIR=/usr/sbin). make install-doc (install documentation)(dafault path DOC_DIR=/usr/share/doc/dpdk). make install-mod (install modules)(dafault path if RTE_EXEC_ENV=linuxapp then KERNEL_DIR=/lib/modules/$(uname -r)/build else KERNEL_DIR=/boot/modules). make install-sdk (install headers, makefiles, scripts,examples, tools and config files) (default path DATA_DIR=/usr/share/dpdk). make install-fhs (install libraries, modules, app files, nic bind files and documentation). Also you can use the DESTDIR variable. All directory variables mentioned above can be overridden (BIN_DIR, LIB_DIR, INCLUDE_DIR, SBIN_DIR, DOC_DIR, KERNEL_DIR and DATA_DIR). v2: Modify the makefile target to specify the files that will be installed using a rule: make install-bin (install app files). make install-headers (install headers). make install-lib (install libraries). make install-sbin (install nic bind files). make install-doc (install documentation). make install-mod (install modules). make install-sdk (install headers, makefiles, scripts, examples, tools and config files). make install-fhs (install libraries, modules, app files, nic bind files and documentation). Also you can use the DESTDIR variable. v1: By adding a parameter H=1 (hierarchy-file) to makefile system, it is possible to do the next steps make config T=TARGET make make install H=1 and files will be installed on the proper directory. Also you can use the DESTDIR variable. Mario Carrillo (7): mk: Add rule for installing headers mk: Add rule for installing app files mk: Add rule for installing libraries mk: Add rule for installing modules mk: Add rule for installing documentation mk: Add rule for installing sdk files mk: Add rule for installing runtime files mk/rte.sdkinstall.mk | 115 ++- mk/rte.sdkroot.mk| 6 ++- 2 files changed, 118 insertions(+), 3 deletions(-) -- 2.1.0
[dpdk-dev] DPDK install behavior Question
Hi, Working with the patchset to include new features to make install, some questions I missed to ask before: for example if you use only "make install": "T" variable is going to get "*" value and the makefiles are going to build all TARGETS, Is it an expected behavior?, and if you use "make install T=TARGET" (e.g. make install T=x86_64-native-linuxapp-gcc) the makefiles are going to config, build and install dpdk, however the target just say "install", and is doing config and build again. is it and expected behavior too?. Thank you so much. Mario.
[dpdk-dev] [PATCH v3 8/8] mk: Add rule for installing runtime files
Anwser for [PATCH v3 8/8] mk: Add rule for installing runtime files Hi Panu, Thank you for taking time in this revision :),. In this patchset I?ve tried to keep current behavior (make install) untouched, I mean thye don't affect the current makefile rules and they work like "new features". For that reason, they were created as new rules. Now you can do the next. 1) make config T=TARGET (Create a build directory with config files according TARGET and directoy environment) 2) make (build dpdk binaries) and in this point, if you chose some new rule from serie of patches (install-sdk, install-doc, install-bin... etc) the files that were built in the last step will be installed in paths according this site http://www.freedesktop.org/software/systemd/man/file-hierarchy.html this just will be possibe if build/.config exist. 3) However if you use last rules, they should have the previos behavior before patches. example: make install T=x86_64-native-linuxapp-gcc then the makefiles are going to config, build and install dpdk in a directory using TARGET as a name. thanks. Mario. From: Panu Matilainen [pmati...@redhat.com] Sent: Friday, October 02, 2015 4:15 AM To: Arevalo, Mario Alfredo C; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v3 8/8] mk: Add rule for installing runtime files On 10/01/2015 03:11 AM, Mario Carrillo wrote: > Add hierarchy-file support to the DPDK libraries, modules, > binary files, nic bind files and documentation, > when invoking "make install-fhs" (filesystem hierarchy standard) > runtime files will be by default installed in: > $(DESTDIR)/$(BIN_DIR) where BIN_DIR=/usr/bin (binary files) > $(DESTDIR)/$(SBIN_DIR) where SBIN_DIR=/usr/sbin/dpdk_nic_bind (nic bind > files) > $(DESTDIR)/$(DOC_DIR) where DOC_DIR=/usr/share/doc/dpdk (documentation) > $(DESTDIR)/$(LIB_DIR) (libraries) > if the architecture is 64 bits then LIB_DIR=/usr/lib64 > else LIB_DIR=/usr/lib > $(DESTDIR)/$(KERNEL_DIR) (modules) > if RTE_EXEC_ENV=linuxapp then > KERNEL_DIR=/lib/modules/$(uname -r)/build > else KERNEL_DIR=/boot/modules > All directory variables mentioned above can be overridden. > This hierarchy is based on: > http://www.freedesktop.org/software/systemd/man/file-hierarchy.html > Hmm, I think there's a slight misunderstanding here. What I meant earlier by install-sdk and install-fhs is to preserve the current behavior of "make install" as "make install-sdk" and have "make install-fhs" behave like normal OSS app on "make install", which installs everything (both devel and runtime parts) This patch series eliminates the current behavior of "make install" entirely. I personally would not miss it at all, but there likely are people relying on it since its quite visibly documented and all. So I think the idea was to introduce a separate FHS-installation target and then deal with the notion of default behaviors etc separately. I guess it was already this way in v2 of the series, apologies for missing it there. - Panu -
[dpdk-dev] [PATCH v3 6/8] mk: Add rule for installing nic bind files
Hi, Panu and Bruce, sounds good your suggestion :) , then I'm going to change the patch for installing dpdk_nic_bind.py and cpu_layout.py in /usr/bin Thanks. Mario. From: Richardson, Bruce Sent: Friday, October 02, 2015 3:54 AM To: Panu Matilainen; Arevalo, Mario Alfredo C; dev at dpdk.org Subject: RE: [dpdk-dev] [PATCH v3 6/8] mk: Add rule for installing nic bind files > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Panu Matilainen > Sent: Friday, October 2, 2015 11:50 AM > To: Arevalo, Mario Alfredo C; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 6/8] mk: Add rule for installing nic > bind files > > On 10/01/2015 03:11 AM, Mario Carrillo wrote: > > Add hierarchy-file support to the DPDK nic bind files, when invoking > > "make install-sbin" nic bind files will be installed by default in: > > $(DESTDIR)/$(SBIN_DIR) where SBIN_DIR=/usr/sbin/dpdk_nic_bind by > > default, you can override SBIN_DIR var. > > This hierarchy is based on: > > http://www.freedesktop.org/software/systemd/man/file-hierarchy.html > > and dpdk spec file. > > > > Signed-off-by: Mario Carrillo > > --- > > mk/rte.sdkinstall.mk | 14 ++ > > mk/rte.sdkroot.mk| 4 ++-- > > 2 files changed, 16 insertions(+), 2 deletions(-) > > > > diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk index > > 5a2fd40..4eecf31 100644 > > --- a/mk/rte.sdkinstall.mk > > +++ b/mk/rte.sdkinstall.mk > > @@ -46,11 +46,13 @@ else > > INCLUDE_DIR ?= /usr/include/dpdk > > BIN_DIR ?= /usr/bin > > DOC_DIR ?= /usr/share/doc/dpdk > > +SBIN_DIR ?= /usr/sbin/dpdk_nic_bind > > HSLINKS := $(wildcard $(RTE_OUTPUT)/include/*) > > BINARY_FILES := $(patsubst %.map,,$(wildcard $(RTE_OUTPUT)/app/*)) > > LIBS := $(wildcard $(RTE_OUTPUT)/lib/*) > > MODULES := $(wildcard $(RTE_OUTPUT)/kmod/*) > > DOCS := $(wildcard $(BUILD_DIR)/doc/*) > > +NIC_BIND_FILES := $(wildcard $(BUILD_DIR)/tools/*nic_bind.py) > > include $(BUILD_DIR)/build/.config > > RTE_ARCH := $(CONFIG_RTE_ARCH:"%"=%) > > RTE_EXEC_ENV := $(CONFIG_RTE_EXEC_ENV:"%"=%) @@ -161,6 +163,18 @@ > > install-doc: > > echo installing: $$DOC; \ > > done > > # > > +# install nic bind files in /usr/sbin/dpdk_nic_bind # by default > > +SBIN_DIR can be overridden. > > +# > > This creates an out-of-path directory /usr/sbin/dpdk_nic_bind/ in which > the dpdk_nic_bind.py is installed. Besides not being a very accessible > location, the FHS explicitly forbids creation of subdirectories below > /usr/[s]bin. > > SBIN_DIR should be /usr/sbin unless overridden, but OTOH I think this > could go into /usr/bin just as well, the split is fairly ambiguous anyway > (I mean, testpmd is not something a regular user is going to run > either) > > In addition, if dpdk_nic_bind.py is installed then perhaps the > cpu_layout.py utility should be installed too? > > - Panu - I think there are better utilities available for determining the core layout that cpu_layout.py. "lstopo", for one, is much more powerful. Do we want/need to keep our own script around for that? /Bruce
[dpdk-dev] [PATCH v3 4/8] mk: Add rule for installing modules
Hi, Panu, perfect thank you for your feedback, I going to change that path by /lib/modules/$(uname -r)/extra/ in my patch. Thanks. Mario. From: Panu Matilainen [pmati...@redhat.com] Sent: Friday, October 02, 2015 3:38 AM To: Arevalo, Mario Alfredo C; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v3 4/8] mk: Add rule for installing modules On 10/01/2015 03:11 AM, Mario Carrillo wrote: > Add hierarchy-file support to the DPDK modules, > when invoking "make install-mod" modules will be > installed in: $(DESTDIR)/$(KERNEL_DIR) > if RTE_EXEC_ENV=linuxapp then > KERNEL_DIR=/lib/modules/$(uname -r)/build /lib/modules/$(uname -r)/build is the path you need when *building* external kernel modules, you dont want to install anything there. The default install path for the kernel modules should be somewhere within /lib/modules/$(uname -r)/extra/, but dunno what the recommended naming/placing within that is. Sorry for not catching this earlier, - Panu -
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
Hi, Thanks you for your feedback, I?ll send a version 2 based on last comments. Thanks, Mario From: Olivier MATZ [olivier.m...@6wind.com] Sent: Tuesday, September 22, 2015 7:40 AM To: Panu Matilainen; Arevalo, Mario Alfredo C; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/7] Add hierarchical support to make install Hi, On 09/22/2015 12:14 PM, Panu Matilainen wrote: > In my packaging of DPDK I ended up providing both: headers, libraries > etc in the normal system paths, and then a separate dpdk-sdk directory > holding the SDK-parts like mk bits and symlinking to the libs and > headers as needed, so that you can actually point RTE_SDK to that > dpdk-sdk dir and be able to build apps against the thing. Great, it didn't know that. >> My question is: do we want to keep the current install behavior for >> compatibility or not? Should we consider this makefile directive as >> an API? People may use it, and we should at least ask us it it should >> follow a sort of API deprecation process like we do for the code. >> That's why I talked about 2 new commands and deprecate the old one. > > I'd be surprised if somebody somewhere isn't relying on the current > specific behavior, given its explicitly documented and all. Whether it > needs to stay, and whether it needs to stay as the default ... I > wouldn't miss it, but its a question for those using and depending on it > really. Ok. So if nobody else complains, I have no objection to change the default behavior of "make install" to this which indeed looks more usual and distribution-friendly. In this case we may remove the old one, it's probably better than having a H=1 option. Regards, Olivier
