* [dpdk-dev] [PATCH] reserve 'make install' for future use @ 2015-11-06 10:24 Bruce Richardson 2015-11-06 10:24 ` [dpdk-dev] [PATCH] mk: rename 'make install' to 'make sdk' Bruce Richardson 2015-11-06 12:57 ` [dpdk-dev] [PATCH] reserve 'make install' for future use Bruce Richardson 0 siblings, 2 replies; 16+ messages in thread From: Bruce Richardson @ 2015-11-06 10:24 UTC (permalink / raw) To: dev There has been some discussion on the list about various ways to get DPDK more standardised in how it compiles and how it can be installed into a system as a set of binaries. One of the issues we face in that is that the 'make install' command is used in DPDK to compile a copy of the SDK but not to place the resultant binaries in the filesystem like other packages do. In order to allow us to have the option to use 'make install' in its common meaning in a future release we need to replace it in our packages, and allow some time for the change to a new command to bed-in. This patchset therefore proposed to change "make install" to "make sdk" [and "make uninstall" to "make clean-sdk"]. Using the old commands now prints out an error message informing the user to use the new versions. These new commands are ones that made sense to me - I'm happy enough to change them for something else people feel is more appropriate. The key point here is to move away from using "make install". I would ask that if general agreement on this can be reached that such a change be considered for 2.2, even though it is late in the day, as "freeing up" the make install command will potentially take multiple releases as not everyone is on the latest version, and so waiting till 2.3 to make a change will push out any future re-use of a "make install" command by 4 months. Regards, /Bruce Bruce Richardson (1): mk: rename 'make install' to 'make sdk' doc/guides/freebsd_gsg/build_dpdk.rst | 16 ++--- doc/guides/linux_gsg/build_dpdk.rst | 22 +++--- doc/guides/nics/intel_vf.rst | 2 +- doc/guides/prog_guide/dev_kit_root_make_help.rst | 18 ++--- doc/guides/sample_app_ug/tep_termination.rst | 3 +- doc/guides/sample_app_ug/vhost.rst | 3 +- doc/guides/testpmd_app_ug/build_app.rst | 2 +- doc/guides/xen/pkt_switch.rst | 2 +- mk/rte.sdk.mk | 88 ++++++++++++++++++++++++ mk/rte.sdkinstall.mk | 87 ----------------------- mk/rte.sdkroot.mk | 13 +++- scripts/gen-build-mk.sh | 2 +- 12 files changed, 133 insertions(+), 125 deletions(-) create mode 100644 mk/rte.sdk.mk delete mode 100644 mk/rte.sdkinstall.mk -- 2.5.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [dpdk-dev] [PATCH] mk: rename 'make install' to 'make sdk' 2015-11-06 10:24 [dpdk-dev] [PATCH] reserve 'make install' for future use Bruce Richardson @ 2015-11-06 10:24 ` Bruce Richardson 2015-11-06 12:57 ` [dpdk-dev] [PATCH] reserve 'make install' for future use Bruce Richardson 1 sibling, 0 replies; 16+ messages in thread From: Bruce Richardson @ 2015-11-06 10:24 UTC (permalink / raw) To: dev Since 'make install' is the standard command for installing packages into the filesystem of a system - generally in /usr/local/ - it's use to trigger compilation of the DPDK SDK was both confusing and preventing a "true" 'make install' command from being implemented. As a first step to improving our build and install system, this patch renames the 'make install' and 'make uninstall' commands to 'make sdk' and 'make clean-sdk' respectively. Signed-off-by: Bruce Richardson <bruce.richardson@intel.com> --- doc/build-sdk-quick.txt | 4 +- doc/guides/freebsd_gsg/build_dpdk.rst | 16 ++--- doc/guides/linux_gsg/build_dpdk.rst | 22 +++--- doc/guides/nics/intel_vf.rst | 2 +- doc/guides/prog_guide/dev_kit_root_make_help.rst | 18 ++--- doc/guides/rel_notes/deprecation.rst | 4 ++ doc/guides/rel_notes/release_2_2.rst | 7 ++ doc/guides/sample_app_ug/tep_termination.rst | 3 +- doc/guides/sample_app_ug/vhost.rst | 3 +- doc/guides/testpmd_app_ug/build_app.rst | 2 +- doc/guides/xen/pkt_switch.rst | 2 +- mk/rte.sdk.mk | 88 ++++++++++++++++++++++++ mk/rte.sdkinstall.mk | 87 ----------------------- mk/rte.sdkroot.mk | 13 +++- scripts/gen-build-mk.sh | 2 +- tools/setup.sh | 6 +- 16 files changed, 149 insertions(+), 130 deletions(-) create mode 100644 mk/rte.sdk.mk delete mode 100644 mk/rte.sdkinstall.mk diff --git a/doc/build-sdk-quick.txt b/doc/build-sdk-quick.txt index bf18b48..c91b664 100644 --- a/doc/build-sdk-quick.txt +++ b/doc/build-sdk-quick.txt @@ -5,8 +5,8 @@ Build commands all same as build (default rule) build build in a configured directory clean remove files but keep configuration - install build many targets (wildcard allowed) and install in DESTDIR - uninstall remove all installed targets + sdk build many targets (wildcard allowed) in DESTDIR + clean-sdk remove all built targets examples build examples for given targets (T=) examples_clean clean examples for given targets (T=) Build variables diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst b/doc/guides/freebsd_gsg/build_dpdk.rst index 8eff599..d03dfe3 100644 --- a/doc/guides/freebsd_gsg/build_dpdk.rst +++ b/doc/guides/freebsd_gsg/build_dpdk.rst @@ -114,7 +114,7 @@ user. For the installation of the DPDK, the default options were used. make config -recursive command until no more dialogs are seen. -Install the DPDK and Browse Sources +Prepare the DPDK and Browse Sources ----------------------------------- First, uncompress the archive and move to the DPDK source directory: @@ -136,8 +136,8 @@ The DPDK is composed of several directories: * config, tools, scripts, mk: Framework-related makefiles, scripts and configuration -Installation of the DPDK Target Environments --------------------------------------------- +Compiling the DPDK SDK for a Target Environment +----------------------------------------------- The format of a DPDK target is: @@ -168,23 +168,23 @@ directory in the form of: on which it is built. For more information on this setting, and its possible values, see the *DPDK Programmers Guide*. -To install and make the target, use "gmake install T=<target>". +To make the target, use "gmake sdk T=<target>". For example to compile for FreeBSD* use: .. code-block:: console - gmake install T=x86_64-native-bsdapp-clang + gmake sdk T=x86_64-native-bsdapp-clang .. note:: If the compiler binary to be used does not correspond to that given in the TOOLCHAIN part of the target, the compiler command may need to be explicitly specified. For example, if compiling for gcc, where the gcc binary is called - gcc4.8, the command would need to be "gmake install T=<target> CC=gcc4.8". + gcc4.8, the command would need to be "gmake sdk T=<target> CC=gcc4.8". -Browsing the Installed DPDK Environment Target ----------------------------------------------- +Browsing the Compiled DPDK SDK +------------------------------ Once a target is created, it contains all the libraries and header files for the DPDK environment that are required to build customer applications. diff --git a/doc/guides/linux_gsg/build_dpdk.rst b/doc/guides/linux_gsg/build_dpdk.rst index 2680e66..13230f9 100644 --- a/doc/guides/linux_gsg/build_dpdk.rst +++ b/doc/guides/linux_gsg/build_dpdk.rst @@ -35,8 +35,8 @@ Compiling the DPDK Target from Source Parts of this process can also be done using the setup script described in Chapter 6 of this document. -Install the DPDK and Browse Sources ------------------------------------ +Prepare DPDK and Browse Sources +------------------------------- First, uncompress the archive and move to the uncompressed DPDK source directory: @@ -59,8 +59,8 @@ The DPDK is composed of several directories: * config, tools, scripts, mk: Framework-related makefiles, scripts and configuration -Installation of DPDK Target Environments ----------------------------------------- +Compile DPDK SDK for a Target Environment +----------------------------------------- The format of a DPDK target is: @@ -96,31 +96,31 @@ Also, verify the compiler's installation directory since the path may be differe source /opt/intel/bin/iccvars.sh intel64 source /opt/intel/bin/iccvars.sh ia32 -To install and make targets, use the make install T=<target> command in the top-level DPDK directory. +To install and make targets, use the make sdk T=<target> command in the top-level DPDK directory. For example, to compile a 64-bit target using icc, run: .. code-block:: console - make install T=x86_64-native-linuxapp-icc + make sdk T=x86_64-native-linuxapp-icc To compile a 32-bit build using gcc, the make command should be: .. code-block:: console - make install T=i686-native-linuxapp-gcc + make sdk T=i686-native-linuxapp-gcc To compile all 64-bit targets using gcc, use: .. code-block:: console - make install T=x86_64*gcc + make sdk T=x86_64*gcc To compile all 64-bit targets using both gcc and icc, use: .. code-block:: console - make install T=x86_64-* + make sdk T=x86_64-* .. note:: @@ -152,8 +152,8 @@ The user may also make modifications to the compile-time DPDK configuration by e In addition, the make clean command can be used to remove any existing compiled files for a subsequent full, clean rebuild of the code. -Browsing the Installed DPDK Environment Target ----------------------------------------------- +Browsing the Compiled DPDK SDK +------------------------------ Once a target is created it contains all libraries, including poll-mode drivers, and header files for the DPDK environment that are required to build customer applications. In addition, the test and testpmd applications are built under the build/app directory, which may be used for testing. diff --git a/doc/guides/nics/intel_vf.rst b/doc/guides/nics/intel_vf.rst index db86c64..01bd641 100644 --- a/doc/guides/nics/intel_vf.rst +++ b/doc/guides/nics/intel_vf.rst @@ -512,7 +512,7 @@ The setup procedure is as follows: .. code-block:: console - make install T=x86_64-native-linuxapp-gcc + make sdk T=x86_64-native-linuxapp-gcc ./x86_64-native-linuxapp-gcc/app/testpmd -c f -n 4 -- -i #. Finally, access the Guest OS using vncviewer with the localhost:5900 port and check the lspci command output in the Guest OS. diff --git a/doc/guides/prog_guide/dev_kit_root_make_help.rst b/doc/guides/prog_guide/dev_kit_root_make_help.rst index e522c12..c84874e 100644 --- a/doc/guides/prog_guide/dev_kit_root_make_help.rst +++ b/doc/guides/prog_guide/dev_kit_root_make_help.rst @@ -102,15 +102,15 @@ The default output directory is build. make lib/librte_eal_clean O=mybuild -Install Targets ---------------- +SDK Compilation Targets +----------------------- -* Install +* sdk Build the DPDK binary. Actually, this builds each supported target in a separate directory. The name of each directory is the name of the target. - The name of the targets to install can be optionally specified using T=mytarget. + The name of the targets to build can be optionally specified using T=mytarget. The target name can contain wildcard \* characters. The list of available targets are in $(RTE_SDK)/config (remove the defconfig\_ prefix). @@ -118,11 +118,11 @@ Install Targets .. code-block:: console - make install T=x86_64-* + make sdk T=x86_64-* -* Uninstall +* clean-sdk - Remove installed target directories. + Remove previously built target directories. Test Targets ------------ @@ -140,7 +140,7 @@ Test Targets * testall - Launch automatic tests for all installed target directories (after a make install). + Launch automatic tests for all installed target directories (after a make sdk). The name of the targets to test can be optionally specified using T=mytarget. The target name can contain wildcard (\*) characters. The list of available targets are in $(RTE_SDK)/config (remove the defconfig\_ prefix). @@ -265,4 +265,4 @@ For example: .. code-block:: console - make install T=x86_64-native-linuxapp-gcc make -C examples/<theapp> + make sdk T=x86_64-native-linuxapp-gcc make -C examples/<theapp> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 549ecb9..9e31073 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -8,6 +8,10 @@ API and ABI deprecation notices are to be posted here. Deprecation Notices ------------------- +* The commands "make install" and "make uninstall" used to build, and clean up + the DPDK SDK have been renamed in this release to "make sdk" and "make + sdk-clean" respectively. + * The following fields have been deprecated in rte_eth_stats: ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss, tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst index 59dda59..1c879e3 100644 --- a/doc/guides/rel_notes/release_2_2.rst +++ b/doc/guides/rel_notes/release_2_2.rst @@ -196,6 +196,13 @@ Known Issues ------------ +Build Changes +------------- + +* The commands "make install" and "make uninstall" to build and subsequently + clean-up the DPDK SDK have been renamed to "make sdk" and "make sdk-clean" in + this release. + API Changes ----------- diff --git a/doc/guides/sample_app_ug/tep_termination.rst b/doc/guides/sample_app_ug/tep_termination.rst index 6beb6f6..ac1fcc7 100644 --- a/doc/guides/sample_app_ug/tep_termination.rst +++ b/doc/guides/sample_app_ug/tep_termination.rst @@ -162,8 +162,7 @@ Compiling the Sample Code .. code-block:: console cd ${RTE_SDK} - make config ${RTE_TARGET} - make install ${RTE_TARGET} + make sdk ${RTE_TARGET} cd ${RTE_SDK}/examples/tep_termination make diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst index ceeaf52..4c7ae22 100644 --- a/doc/guides/sample_app_ug/vhost.rst +++ b/doc/guides/sample_app_ug/vhost.rst @@ -334,8 +334,7 @@ Compiling the Sample Code .. code-block:: console cd ${RTE_SDK} - make config ${RTE_TARGET} - make install ${RTE_TARGET} + make sdk ${RTE_TARGET} cd ${RTE_SDK}/examples/vhost make diff --git a/doc/guides/testpmd_app_ug/build_app.rst b/doc/guides/testpmd_app_ug/build_app.rst index 7f32a7c..a5b4837 100644 --- a/doc/guides/testpmd_app_ug/build_app.rst +++ b/doc/guides/testpmd_app_ug/build_app.rst @@ -52,7 +52,7 @@ The basic compilation steps are: .. code-block:: console - make install T=$RTE_TARGET + make sdk T=$RTE_TARGET The compiled application will be located at: diff --git a/doc/guides/xen/pkt_switch.rst b/doc/guides/xen/pkt_switch.rst index 3a6fc47..48a4475 100644 --- a/doc/guides/xen/pkt_switch.rst +++ b/doc/guides/xen/pkt_switch.rst @@ -295,7 +295,7 @@ Building and Running the Switching Backend .. code-block:: console - make install T=x86_64-native-linuxapp-gcc + make sdk T=x86_64-native-linuxapp-gcc #. Ensure that RTE_SDK and RTE_TARGET are correctly set. Build the switching example: diff --git a/mk/rte.sdk.mk b/mk/rte.sdk.mk new file mode 100644 index 0000000..7372733 --- /dev/null +++ b/mk/rte.sdk.mk @@ -0,0 +1,88 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of Intel Corporation nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +# Build directory is given with O= +ifdef O +BUILD_DIR=$(O) +else +BUILD_DIR=. +endif + +# Targets to install can be specified in command line. It can be a +# target name or a name containing jokers "*". Example: +# x86_64-native-*-gcc +ifndef T +T=* +endif + +# +# sdk: build sdk for all supported targets +# +SDK_CONFIGS := $(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\ + $(wildcard $(RTE_SRCDIR)/config/defconfig_$(T))) +SDK_TARGETS := $(addsuffix _sdkbuild,\ + $(filter-out %~,$(SDK_CONFIGS))) + +.PHONY: sdk sdkbuild +sdk: sdkbuild +sdkbuild: $(SDK_TARGETS) + +%_sdkbuild: + @echo ================== Building $* + $(Q)if [ ! -f $(BUILD_DIR)/$*/.config ]; then \ + $(MAKE) config T=$* O=$(BUILD_DIR)/$*; \ + elif cmp -s $(BUILD_DIR)/$*/.config.orig $(BUILD_DIR)/$*/.config; then \ + $(MAKE) config T=$* O=$(BUILD_DIR)/$*; \ + else \ + if [ -f $(BUILD_DIR)/$*/.config.orig ] ; then \ + tmp_build=$(BUILD_DIR)/$*/.config.tmp; \ + $(MAKE) config T=$* O=$$tmp_build; \ + if ! cmp -s $(BUILD_DIR)/$*/.config.orig $$tmp_build/.config ; then \ + echo "Conflict: local config and template config have both changed"; \ + exit 1; \ + fi; \ + fi; \ + echo "Using local configuration"; \ + fi + $(Q)$(MAKE) all O=$(BUILD_DIR)/$* + +# +# clean-sdk: remove all built sdk +# +CLEAN_SDK_TARGETS := $(addsuffix _clean_sdk,\ + $(filter-out %~,$(SDK_CONFIGS))) + +.PHONY: clean-sdk +clean-sdk: $(CLEAN_SDK_TARGETS) + +%_clean_sdk: + @echo ================== Cleaning $* + $(Q)rm -rf $(BUILD_DIR)/$* diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk deleted file mode 100644 index 86c98a5..0000000 --- a/mk/rte.sdkinstall.mk +++ /dev/null @@ -1,87 +0,0 @@ -# BSD LICENSE -# -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. -# All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of Intel Corporation nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -# Build directory is given with O= -ifdef O -BUILD_DIR=$(O) -else -BUILD_DIR=. -endif - -# Targets to install can be specified in command line. It can be a -# target name or a name containing jokers "*". Example: -# x86_64-native-*-gcc -ifndef T -T=* -endif - -# -# install: build sdk for all supported targets -# -INSTALL_CONFIGS := $(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\ - $(wildcard $(RTE_SRCDIR)/config/defconfig_$(T))) -INSTALL_TARGETS := $(addsuffix _install,\ - $(filter-out %~,$(INSTALL_CONFIGS))) - -.PHONY: install -install: $(INSTALL_TARGETS) - -%_install: - @echo ================== Installing $* - $(Q)if [ ! -f $(BUILD_DIR)/$*/.config ]; then \ - $(MAKE) config T=$* O=$(BUILD_DIR)/$*; \ - elif cmp -s $(BUILD_DIR)/$*/.config.orig $(BUILD_DIR)/$*/.config; then \ - $(MAKE) config T=$* O=$(BUILD_DIR)/$*; \ - else \ - if [ -f $(BUILD_DIR)/$*/.config.orig ] ; then \ - tmp_build=$(BUILD_DIR)/$*/.config.tmp; \ - $(MAKE) config T=$* O=$$tmp_build; \ - if ! cmp -s $(BUILD_DIR)/$*/.config.orig $$tmp_build/.config ; then \ - echo "Conflict: local config and template config have both changed"; \ - exit 1; \ - fi; \ - fi; \ - echo "Using local configuration"; \ - fi - $(Q)$(MAKE) all O=$(BUILD_DIR)/$* - -# -# uninstall: remove all built sdk -# -UNINSTALL_TARGETS := $(addsuffix _uninstall,\ - $(filter-out %~,$(INSTALL_CONFIGS))) - -.PHONY: uninstall -uninstall: $(UNINSTALL_TARGETS) - -%_uninstall: - @echo ================== Uninstalling $* - $(Q)rm -rf $(BUILD_DIR)/$* diff --git a/mk/rte.sdkroot.mk b/mk/rte.sdkroot.mk index e8423b0..7f451d5 100644 --- a/mk/rte.sdkroot.mk +++ b/mk/rte.sdkroot.mk @@ -98,8 +98,17 @@ testall: $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdktestall.mk $@ .PHONY: install uninstall -install uninstall: - $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@ +#install uninstall: +# $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdkinstall.mk $@ +install: + $(Q)echo "'make install' is deprecated. Use 'make sdk' instead" + +uninstall: + $(Q)echo "'make uninstall' is deprecated. Use 'make clean-sdk' instead" + +.PHONY: sdk clean-sdk +sdk clean-sdk: + $(Q)$(MAKE) -f $(RTE_SDK)/mk/rte.sdk.mk $@ .PHONY: doc help doc: doc-all diff --git a/scripts/gen-build-mk.sh b/scripts/gen-build-mk.sh index 5c12813..37ec771 100755 --- a/scripts/gen-build-mk.sh +++ b/scripts/gen-build-mk.sh @@ -46,7 +46,7 @@ echo "endif" echo echo "MAKEFLAGS += --no-print-directory" echo -echo "all:" +echo "all sdk:" echo " @\$(MAKE) -C $1 O=$2" echo echo "%::" diff --git a/tools/setup.sh b/tools/setup.sh index 5a8b2f3..eb7a461 100755 --- a/tools/setup.sh +++ b/tools/setup.sh @@ -80,7 +80,7 @@ setup_icc() } # -# Sets RTE_TARGET and does a "make install". +# Sets RTE_TARGET and does a "make sdk". # setup_target() { @@ -97,7 +97,7 @@ setup_target() fi fi if [ "$QUIT" == "0" ] ; then - make install T=${RTE_TARGET} + make sdk T=${RTE_TARGET} fi echo "------------------------------------------------------------------------------" echo " RTE_TARGET exported as $RTE_TARGET" @@ -109,7 +109,7 @@ setup_target() # uninstall_targets() { - make uninstall + make clean-sdk } # -- 2.5.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-06 10:24 [dpdk-dev] [PATCH] reserve 'make install' for future use Bruce Richardson 2015-11-06 10:24 ` [dpdk-dev] [PATCH] mk: rename 'make install' to 'make sdk' Bruce Richardson @ 2015-11-06 12:57 ` Bruce Richardson 2015-11-06 13:04 ` Thomas Monjalon 1 sibling, 1 reply; 16+ messages in thread From: Bruce Richardson @ 2015-11-06 12:57 UTC (permalink / raw) To: dev So, any thoughts or comments on this? There has been lots of discussion in this general area but nothing yet going into the release to try and improve the situation. Are we just going to kick the problem down the road to the 2.3 release? /Bruce On Fri, Nov 06, 2015 at 10:24:13AM +0000, Bruce Richardson wrote: > There has been some discussion on the list about various ways to get DPDK more > standardised in how it compiles and how it can be installed into a system as > a set of binaries. > > One of the issues we face in that is that the 'make install' command is used in > DPDK to compile a copy of the SDK but not to place the resultant binaries in the > filesystem like other packages do. In order to allow us to have the option to > use 'make install' in its common meaning in a future release we need to replace > it in our packages, and allow some time for the change to a new command to bed-in. > > This patchset therefore proposed to change "make install" to "make sdk" [and > "make uninstall" to "make clean-sdk"]. Using the old commands now prints out > an error message informing the user to use the new versions. > > These new commands are ones that made sense to me - I'm happy enough to change > them for something else people feel is more appropriate. The key point here is > to move away from using "make install". > > I would ask that if general agreement on this can be reached that such a change > be considered for 2.2, even though it is late in the day, as "freeing up" the > make install command will potentially take multiple releases as not everyone is > on the latest version, and so waiting till 2.3 to make a change will push out > any future re-use of a "make install" command by 4 months. > > Regards, > /Bruce > > Bruce Richardson (1): > mk: rename 'make install' to 'make sdk' > > doc/guides/freebsd_gsg/build_dpdk.rst | 16 ++--- > doc/guides/linux_gsg/build_dpdk.rst | 22 +++--- > doc/guides/nics/intel_vf.rst | 2 +- > doc/guides/prog_guide/dev_kit_root_make_help.rst | 18 ++--- > doc/guides/sample_app_ug/tep_termination.rst | 3 +- > doc/guides/sample_app_ug/vhost.rst | 3 +- > doc/guides/testpmd_app_ug/build_app.rst | 2 +- > doc/guides/xen/pkt_switch.rst | 2 +- > mk/rte.sdk.mk | 88 ++++++++++++++++++++++++ > mk/rte.sdkinstall.mk | 87 ----------------------- > mk/rte.sdkroot.mk | 13 +++- > scripts/gen-build-mk.sh | 2 +- > 12 files changed, 133 insertions(+), 125 deletions(-) > create mode 100644 mk/rte.sdk.mk > delete mode 100644 mk/rte.sdkinstall.mk > > -- > 2.5.0 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-06 12:57 ` [dpdk-dev] [PATCH] reserve 'make install' for future use Bruce Richardson @ 2015-11-06 13:04 ` Thomas Monjalon 2015-11-24 16:54 ` Bruce Richardson 0 siblings, 1 reply; 16+ messages in thread From: Thomas Monjalon @ 2015-11-06 13:04 UTC (permalink / raw) To: Bruce Richardson; +Cc: dev 2015-11-06 12:57, Bruce Richardson: > So, any thoughts or comments on this? There has been lots of discussion in this > general area but nothing yet going into the release to try and improve the situation. > > Are we just going to kick the problem down the road to the 2.3 release? I plan to check these patches in the coming days for an integration in 2.2. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-06 13:04 ` Thomas Monjalon @ 2015-11-24 16:54 ` Bruce Richardson 2015-11-25 8:48 ` Panu Matilainen 0 siblings, 1 reply; 16+ messages in thread From: Bruce Richardson @ 2015-11-24 16:54 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: > 2015-11-06 12:57, Bruce Richardson: > > So, any thoughts or comments on this? There has been lots of discussion in this > > general area but nothing yet going into the release to try and improve the situation. > > > > Are we just going to kick the problem down the road to the 2.3 release? > > I plan to check these patches in the coming days for an integration in 2.2. > Anything further on this? Any thoughts from anyone else about this whole area of a saner build/install system for DPDK and the various patches floating around. /Bruce ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-24 16:54 ` Bruce Richardson @ 2015-11-25 8:48 ` Panu Matilainen 2015-11-27 17:33 ` Thomas Monjalon 0 siblings, 1 reply; 16+ messages in thread From: Panu Matilainen @ 2015-11-25 8:48 UTC (permalink / raw) To: Bruce Richardson, Thomas Monjalon; +Cc: dev On 11/24/2015 06:54 PM, Bruce Richardson wrote: > On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: >> 2015-11-06 12:57, Bruce Richardson: >>> So, any thoughts or comments on this? There has been lots of discussion in this >>> general area but nothing yet going into the release to try and improve the situation. >>> >>> Are we just going to kick the problem down the road to the 2.3 release? >> >> I plan to check these patches in the coming days for an integration in 2.2. >> > Anything further on this? > Any thoughts from anyone else about this whole area of a saner build/install > system for DPDK and the various patches floating around. Well, it seems we wont have a sane "make install" in 2.2 yet, but this is at least a step in the right direction so +1 from me. - Panu - ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-25 8:48 ` Panu Matilainen @ 2015-11-27 17:33 ` Thomas Monjalon 2015-11-30 11:08 ` Richardson, Bruce 2015-11-30 12:26 ` Panu Matilainen 0 siblings, 2 replies; 16+ messages in thread From: Thomas Monjalon @ 2015-11-27 17:33 UTC (permalink / raw) To: Panu Matilainen, Bruce Richardson; +Cc: dev 2015-11-25 10:48, Panu Matilainen: > On 11/24/2015 06:54 PM, Bruce Richardson wrote: > > On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: > >> 2015-11-06 12:57, Bruce Richardson: > >>> So, any thoughts or comments on this? There has been lots of discussion in this > >>> general area but nothing yet going into the release to try and improve the situation. > >>> > >>> Are we just going to kick the problem down the road to the 2.3 release? > >> > >> I plan to check these patches in the coming days for an integration in 2.2. > >> > > Anything further on this? > > Any thoughts from anyone else about this whole area of a saner build/install > > system for DPDK and the various patches floating around. > > Well, it seems we wont have a sane "make install" in 2.2 yet, but this > is at least a step in the right direction so +1 from me. Why is it a step in the right direction? We just need to install the files in a different hierarchy and adapt the makefiles to be able to compile an application while keeping the RTE_SDK variable to specify the root directory (previously built thanks to DESTDIR). As the hierarchy could be tuned, we need more variables, e.g.: DPDK_INC_DIR (default = RTE_SDK/include/dpdk) DPDK_LIB_DIR (default = RTE_SDK/lib) While doing it, we can have a specific handling of T= to keep compatibility with the current (old) syntax. What have I missed? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-27 17:33 ` Thomas Monjalon @ 2015-11-30 11:08 ` Richardson, Bruce 2015-11-30 11:27 ` Thomas Monjalon 2015-11-30 12:26 ` Panu Matilainen 1 sibling, 1 reply; 16+ messages in thread From: Richardson, Bruce @ 2015-11-30 11:08 UTC (permalink / raw) To: Thomas Monjalon, Panu Matilainen; +Cc: dev > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, November 27, 2015 5:33 PM > To: Panu Matilainen <pmatilai@redhat.com>; Richardson, Bruce > <bruce.richardson@intel.com> > Cc: dev@dpdk.org; olivier.matz@6wind.com > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > 2015-11-25 10:48, Panu Matilainen: > > On 11/24/2015 06:54 PM, Bruce Richardson wrote: > > > On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: > > >> 2015-11-06 12:57, Bruce Richardson: > > >>> So, any thoughts or comments on this? There has been lots of > > >>> discussion in this general area but nothing yet going into the > release to try and improve the situation. > > >>> > > >>> Are we just going to kick the problem down the road to the 2.3 > release? > > >> > > >> I plan to check these patches in the coming days for an integration > in 2.2. > > >> > > > Anything further on this? > > > Any thoughts from anyone else about this whole area of a saner > > > build/install system for DPDK and the various patches floating around. > > > > Well, it seems we wont have a sane "make install" in 2.2 yet, but this > > is at least a step in the right direction so +1 from me. > > Why is it a step in the right direction? > > We just need to install the files in a different hierarchy and adapt the > makefiles to be able to compile an application while keeping the RTE_SDK > variable to specify the root directory (previously built thanks to > DESTDIR). > As the hierarchy could be tuned, we need more variables, e.g.: > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > DPDK_LIB_DIR (default = RTE_SDK/lib) > > While doing it, we can have a specific handling of T= to keep > compatibility with the current (old) syntax. > > What have I missed? > I'm not sure our existing "make install" is suitable for use for this, without having it heavily overloaded. The existing T= behavior has support for wildcards and compiling multiple instances at the same time - something that won't work with a scheme to actually install DPDK throughout the filesystem hierarchy. Having it sometimes behave as now, and sometimes behave as a standard make install is a bad idea IMHO, as it confuses things. Having lots of extra environment variables is also not a great idea, to my mind. My opinion is that we should rename our existing "make install" to something more suitable - my patch suggestion was "make sdk" but it could be "make target" or something else if people prefer. Once that is done, we can then look to implement a proper "make install" command that works in a standard way, perhaps alongside a configure script of some description. For an easy enough solution, I would look to apply this patch to create "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a "make install" command that works in the build dir. That way: * you can have existing behavior using "make sdk T=<target>" * you can have standard(ish) configure/make/make install behavior using: make config T=<target> cd build make make install and the "make config" step can subsequently be wrapped in a configure script to eliminate the need to know what the best target to use is, etc. /Bruce ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-30 11:08 ` Richardson, Bruce @ 2015-11-30 11:27 ` Thomas Monjalon 2015-11-30 11:41 ` Richardson, Bruce 0 siblings, 1 reply; 16+ messages in thread From: Thomas Monjalon @ 2015-11-30 11:27 UTC (permalink / raw) To: Richardson, Bruce; +Cc: dev 2015-11-30 11:08, Richardson, Bruce: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > Why is it a step in the right direction? > > > > We just need to install the files in a different hierarchy and adapt the > > makefiles to be able to compile an application while keeping the RTE_SDK > > variable to specify the root directory (previously built thanks to > > DESTDIR). > > As the hierarchy could be tuned, we need more variables, e.g.: > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > While doing it, we can have a specific handling of T= to keep > > compatibility with the current (old) syntax. > > > > What have I missed? > > > > > I'm not sure our existing "make install" is suitable for use for this, without having it heavily overloaded. The existing T= behavior has support for wildcards and compiling multiple instances at the same time - something that won't work with a scheme to actually install DPDK throughout the filesystem hierarchy. Having it sometimes behave as now, and sometimes behave as a standard make install is a bad idea IMHO, as it confuses things. Having lots of extra environment variables is also not a great idea, to my mind. Yes I agree. I forgot to mention it, but in my idea, we can drop the support for multiple targets. So the T= compatibility would be only a shortcut to do "make config" and name the build directory based on the template name. About the environment variables: An application requires CFLAGS and LDFLAGS (at least). The standard way to provide them is pkgconfig (not implemented yet). For applications using the DPDK makefiles, the only input is RTE_SDK. When allowing more tuning in paths, we need more variables when using the DPDK makefiles to build an application. > My opinion is that we should rename our existing "make install" to something more suitable - my patch suggestion was "make sdk" but it could be "make target" or something else if people prefer. Once that is done, we can then look to implement a proper "make install" command that works in a standard way, perhaps alongside a configure script of some description. I think we don't need to rename or move some code. Just drop and replace some of them. The configure script is a great idea but it is a totally different idea. I do not think that installation and configuration should be related. Please let's consider "make install" first. > For an easy enough solution, I would look to apply this patch to create "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a "make install" command that works in the build dir. That way: > * you can have existing behavior using "make sdk T=<target>" > * you can have standard(ish) configure/make/make install behavior using: > make config T=<target> > cd build > make > make install > and the "make config" step can subsequently be wrapped in a configure script to eliminate the need to know what the best target to use is, etc. As Panu commented, I do not think it is a good idea to have different behaviours inside and outside of the build directory. I would even say that this embedded makefile is only confusing and should be dropped. We need to have *one* right building methods, not to bring more confusion. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-30 11:27 ` Thomas Monjalon @ 2015-11-30 11:41 ` Richardson, Bruce 2015-11-30 11:49 ` Bruce Richardson 0 siblings, 1 reply; 16+ messages in thread From: Richardson, Bruce @ 2015-11-30 11:41 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Monday, November 30, 2015 11:27 AM > To: Richardson, Bruce <bruce.richardson@intel.com> > Cc: Panu Matilainen <pmatilai@redhat.com>; dev@dpdk.org; > olivier.matz@6wind.com > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > 2015-11-30 11:08, Richardson, Bruce: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > Why is it a step in the right direction? > > > > > > We just need to install the files in a different hierarchy and adapt > > > the makefiles to be able to compile an application while keeping the > > > RTE_SDK variable to specify the root directory (previously built > > > thanks to DESTDIR). > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > While doing it, we can have a specific handling of T= to keep > > > compatibility with the current (old) syntax. > > > > > > What have I missed? > > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > without having it heavily overloaded. The existing T= behavior has support > for wildcards and compiling multiple instances at the same time - > something that won't work with a scheme to actually install DPDK > throughout the filesystem hierarchy. Having it sometimes behave as now, > and sometimes behave as a standard make install is a bad idea IMHO, as it > confuses things. Having lots of extra environment variables is also not a > great idea, to my mind. > > Yes I agree. > I forgot to mention it, but in my idea, we can drop the support for > multiple targets. So the T= compatibility would be only a shortcut to do > "make config" and name the build directory based on the template name. > > About the environment variables: > An application requires CFLAGS and LDFLAGS (at least). The standard way to > provide them is pkgconfig (not implemented yet). > For applications using the DPDK makefiles, the only input is RTE_SDK. > When allowing more tuning in paths, we need more variables when using the > DPDK makefiles to build an application. > > > My opinion is that we should rename our existing "make install" to > something more suitable - my patch suggestion was "make sdk" but it could > be "make target" or something else if people prefer. Once that is done, we > can then look to implement a proper "make install" command that works in a > standard way, perhaps alongside a configure script of some description. > > I think we don't need to rename or move some code. > Just drop and replace some of them. > > The configure script is a great idea but it is a totally different idea. > I do not think that installation and configuration should be related. > Please let's consider "make install" first. > > > For an easy enough solution, I would look to apply this patch to create > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > "make install" command that works in the build dir. That way: > > * you can have existing behavior using "make sdk T=<target>" > > * you can have standard(ish) configure/make/make install behavior using: > > make config T=<target> > > cd build > > make > > make install > > and the "make config" step can subsequently be wrapped in a configure > script to eliminate the need to know what the best target to use is, etc. > > As Panu commented, I do not think it is a good idea to have different > behaviours inside and outside of the build directory. > I would even say that this embedded makefile is only confusing and should > be dropped. > We need to have *one* right building methods, not to bring more confusion. I disagree. I don't think we can have *one* right building method, because to do so means completely throwing away our existing methods of building DPDK and using sample applications. That general method, using RTE_SDK and RTE_TARGET needs to be supported for some time for those projects already familiar with it and using it. As well as this, we also need a sane way of building DPDK inside the "build" directory, and having a "make install" target that installs the libraries and headers inside /usr/local (or whatever was specified as $prefix). With regards to different behavior, since different targets are provided, I don't see it as a problem. In the root directory, "make config" and "make sdk" are provided for backward compatibility. Inside the build directory you have your standard "make" and "make install" commands. Since the command set is very limited, it's easy enough to print a suitable error when the wrong command is used in the wrong place. Yes, I would like the ideal state where we have one set of build commands that are run from just one location. However, I don't think we can get to that objective without going through a transition phase where we support both old and new options. /Bruce ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-30 11:41 ` Richardson, Bruce @ 2015-11-30 11:49 ` Bruce Richardson 2015-11-30 14:26 ` Thomas Monjalon 0 siblings, 1 reply; 16+ messages in thread From: Bruce Richardson @ 2015-11-30 11:49 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev On Mon, Nov 30, 2015 at 11:41:32AM +0000, Richardson, Bruce wrote: > > > > -----Original Message----- > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > Sent: Monday, November 30, 2015 11:27 AM > > To: Richardson, Bruce <bruce.richardson@intel.com> > > Cc: Panu Matilainen <pmatilai@redhat.com>; dev@dpdk.org; > > olivier.matz@6wind.com > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > > > 2015-11-30 11:08, Richardson, Bruce: > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > Why is it a step in the right direction? > > > > > > > > We just need to install the files in a different hierarchy and adapt > > > > the makefiles to be able to compile an application while keeping the > > > > RTE_SDK variable to specify the root directory (previously built > > > > thanks to DESTDIR). > > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > > > While doing it, we can have a specific handling of T= to keep > > > > compatibility with the current (old) syntax. > > > > > > > > What have I missed? > > > > > > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > > without having it heavily overloaded. The existing T= behavior has support > > for wildcards and compiling multiple instances at the same time - > > something that won't work with a scheme to actually install DPDK > > throughout the filesystem hierarchy. Having it sometimes behave as now, > > and sometimes behave as a standard make install is a bad idea IMHO, as it > > confuses things. Having lots of extra environment variables is also not a > > great idea, to my mind. > > > > Yes I agree. > > I forgot to mention it, but in my idea, we can drop the support for > > multiple targets. So the T= compatibility would be only a shortcut to do > > "make config" and name the build directory based on the template name. > > > > About the environment variables: > > An application requires CFLAGS and LDFLAGS (at least). The standard way to > > provide them is pkgconfig (not implemented yet). > > For applications using the DPDK makefiles, the only input is RTE_SDK. > > When allowing more tuning in paths, we need more variables when using the > > DPDK makefiles to build an application. > > > > > My opinion is that we should rename our existing "make install" to > > something more suitable - my patch suggestion was "make sdk" but it could > > be "make target" or something else if people prefer. Once that is done, we > > can then look to implement a proper "make install" command that works in a > > standard way, perhaps alongside a configure script of some description. > > > > I think we don't need to rename or move some code. > > Just drop and replace some of them. > > > > The configure script is a great idea but it is a totally different idea. > > I do not think that installation and configuration should be related. > > Please let's consider "make install" first. > > > > > For an easy enough solution, I would look to apply this patch to create > > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > > "make install" command that works in the build dir. That way: > > > * you can have existing behavior using "make sdk T=<target>" > > > * you can have standard(ish) configure/make/make install behavior using: > > > make config T=<target> > > > cd build > > > make > > > make install > > > and the "make config" step can subsequently be wrapped in a configure > > script to eliminate the need to know what the best target to use is, etc. > > > > As Panu commented, I do not think it is a good idea to have different > > behaviours inside and outside of the build directory. > > I would even say that this embedded makefile is only confusing and should > > be dropped. > > We need to have *one* right building methods, not to bring more confusion. > > I disagree. I don't think we can have *one* right building method, because to > do so means completely throwing away our existing methods of building DPDK > and using sample applications. That general method, using RTE_SDK and RTE_TARGET > needs to be supported for some time for those projects already familiar with it > and using it. > As well as this, we also need a sane way of building DPDK inside the "build" > directory, and having a "make install" target that installs the libraries > and headers inside /usr/local (or whatever was specified as $prefix). > > With regards to different behavior, since different targets are provided, I > don't see it as a problem. In the root directory, "make config" and "make sdk" > are provided for backward compatibility. Inside the build directory you have > your standard "make" and "make install" commands. Since the command set is > very limited, it's easy enough to print a suitable error when the wrong > command is used in the wrong place. By way of follow-up to my own email, I'd also state that I would indeed prefer not to have different targets in different places, and that ideally you would do configure/make/make-install from the root directory. The reason I suggested having "make install" work inside the build directory is because of our existing use of "make install" for something different in the root directory. This is also the reason I sent out this patch. By renaming the "make install" command in 2.2, we give ourselves the option in future releases of adding in a new "make install" command that behaves as we want, without having to worry about conflict with a legacy make install. That is why I feel this one patch should go in - it opens up more options for us in future releases. It's not an end in itself. :-) /Bruce > > Yes, I would like the ideal state where we have one set of build commands that > are run from just one location. However, I don't think we can get to that objective > without going through a transition phase where we support both old and new options. > > /Bruce > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-30 11:49 ` Bruce Richardson @ 2015-11-30 14:26 ` Thomas Monjalon 2015-12-04 15:57 ` Thomas Monjalon 0 siblings, 1 reply; 16+ messages in thread From: Thomas Monjalon @ 2015-11-30 14:26 UTC (permalink / raw) To: Bruce Richardson; +Cc: dev 2015-11-30 11:49, Bruce Richardson: > On Mon, Nov 30, 2015 at 11:41:32AM +0000, Richardson, Bruce wrote: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > Sent: Monday, November 30, 2015 11:27 AM > > > To: Richardson, Bruce <bruce.richardson@intel.com> > > > Cc: Panu Matilainen <pmatilai@redhat.com>; dev@dpdk.org; > > > olivier.matz@6wind.com > > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > > > > > 2015-11-30 11:08, Richardson, Bruce: > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > > Why is it a step in the right direction? > > > > > > > > > > We just need to install the files in a different hierarchy and adapt > > > > > the makefiles to be able to compile an application while keeping the > > > > > RTE_SDK variable to specify the root directory (previously built > > > > > thanks to DESTDIR). > > > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > > > > > While doing it, we can have a specific handling of T= to keep > > > > > compatibility with the current (old) syntax. > > > > > > > > > > What have I missed? > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > > > without having it heavily overloaded. The existing T= behavior has support > > > for wildcards and compiling multiple instances at the same time - > > > something that won't work with a scheme to actually install DPDK > > > throughout the filesystem hierarchy. Having it sometimes behave as now, > > > and sometimes behave as a standard make install is a bad idea IMHO, as it > > > confuses things. Having lots of extra environment variables is also not a > > > great idea, to my mind. > > > > > > Yes I agree. > > > I forgot to mention it, but in my idea, we can drop the support for > > > multiple targets. So the T= compatibility would be only a shortcut to do > > > "make config" and name the build directory based on the template name. > > > > > > About the environment variables: > > > An application requires CFLAGS and LDFLAGS (at least). The standard way to > > > provide them is pkgconfig (not implemented yet). > > > For applications using the DPDK makefiles, the only input is RTE_SDK. > > > When allowing more tuning in paths, we need more variables when using the > > > DPDK makefiles to build an application. > > > > > > > My opinion is that we should rename our existing "make install" to > > > something more suitable - my patch suggestion was "make sdk" but it could > > > be "make target" or something else if people prefer. Once that is done, we > > > can then look to implement a proper "make install" command that works in a > > > standard way, perhaps alongside a configure script of some description. > > > > > > I think we don't need to rename or move some code. > > > Just drop and replace some of them. > > > > > > The configure script is a great idea but it is a totally different idea. > > > I do not think that installation and configuration should be related. > > > Please let's consider "make install" first. > > > > > > > For an easy enough solution, I would look to apply this patch to create > > > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > > > "make install" command that works in the build dir. That way: > > > > * you can have existing behavior using "make sdk T=<target>" > > > > * you can have standard(ish) configure/make/make install behavior using: > > > > make config T=<target> > > > > cd build > > > > make > > > > make install > > > > and the "make config" step can subsequently be wrapped in a configure > > > script to eliminate the need to know what the best target to use is, etc. > > > > > > As Panu commented, I do not think it is a good idea to have different > > > behaviours inside and outside of the build directory. > > > I would even say that this embedded makefile is only confusing and should > > > be dropped. > > > We need to have *one* right building methods, not to bring more confusion. > > > > I disagree. I don't think we can have *one* right building method, because to > > do so means completely throwing away our existing methods of building DPDK > > and using sample applications. That general method, using RTE_SDK and RTE_TARGET > > needs to be supported for some time for those projects already familiar with it > > and using it. We can keep it for some time while allowing other tree hierarchies. > > As well as this, we also need a sane way of building DPDK inside the "build" > > directory, and having a "make install" target that installs the libraries > > and headers inside /usr/local (or whatever was specified as $prefix). > > > > With regards to different behavior, since different targets are provided, I > > don't see it as a problem. In the root directory, "make config" and "make sdk" > > are provided for backward compatibility. Inside the build directory you have > > your standard "make" and "make install" commands. Since the command set is > > very limited, it's easy enough to print a suitable error when the wrong > > command is used in the wrong place. > > By way of follow-up to my own email, I'd also state that I would indeed prefer > not to have different targets in different places, and that ideally you would > do configure/make/make-install from the root directory. The reason I suggested > having "make install" work inside the build directory is because of our > existing use of "make install" for something different in the root directory. > This is also the reason I sent out this patch. By renaming the "make install" > command in 2.2, we give ourselves the option in future releases of adding in > a new "make install" command that behaves as we want, without having to worry > about conflict with a legacy make install. > > That is why I feel this one patch should go in - it opens up more options for > us in future releases. It's not an end in itself. :-) If we do not agree on something else (I'll try to submit some patches), yes your patch to introduce "make sdk" will be integrated. But I'd prefer avoiding to document a new command which will be deprecated when the new-new "make install" will be implemented. I think there is another solution (I may be wrong). > > Yes, I would like the ideal state where we have one set of build commands that > > are run from just one location. However, I don't think we can get to that objective > > without going through a transition phase where we support both old and new options. > > > > /Bruce ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-30 14:26 ` Thomas Monjalon @ 2015-12-04 15:57 ` Thomas Monjalon 2015-12-04 16:21 ` Richardson, Bruce 0 siblings, 1 reply; 16+ messages in thread From: Thomas Monjalon @ 2015-12-04 15:57 UTC (permalink / raw) To: Bruce Richardson; +Cc: dev 2015-11-30 15:26, Thomas Monjalon: > 2015-11-30 11:49, Bruce Richardson: > > On Mon, Nov 30, 2015 at 11:41:32AM +0000, Richardson, Bruce wrote: > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > Sent: Monday, November 30, 2015 11:27 AM > > > > To: Richardson, Bruce <bruce.richardson@intel.com> > > > > Cc: Panu Matilainen <pmatilai@redhat.com>; dev@dpdk.org; > > > > olivier.matz@6wind.com > > > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > > > > > > > 2015-11-30 11:08, Richardson, Bruce: > > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > > > Why is it a step in the right direction? > > > > > > > > > > > > We just need to install the files in a different hierarchy and adapt > > > > > > the makefiles to be able to compile an application while keeping the > > > > > > RTE_SDK variable to specify the root directory (previously built > > > > > > thanks to DESTDIR). > > > > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > > > > > > > While doing it, we can have a specific handling of T= to keep > > > > > > compatibility with the current (old) syntax. > > > > > > > > > > > > What have I missed? > > > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > > > > without having it heavily overloaded. The existing T= behavior has support > > > > for wildcards and compiling multiple instances at the same time - > > > > something that won't work with a scheme to actually install DPDK > > > > throughout the filesystem hierarchy. Having it sometimes behave as now, > > > > and sometimes behave as a standard make install is a bad idea IMHO, as it > > > > confuses things. Having lots of extra environment variables is also not a > > > > great idea, to my mind. > > > > > > > > Yes I agree. > > > > I forgot to mention it, but in my idea, we can drop the support for > > > > multiple targets. So the T= compatibility would be only a shortcut to do > > > > "make config" and name the build directory based on the template name. > > > > > > > > About the environment variables: > > > > An application requires CFLAGS and LDFLAGS (at least). The standard way to > > > > provide them is pkgconfig (not implemented yet). > > > > For applications using the DPDK makefiles, the only input is RTE_SDK. > > > > When allowing more tuning in paths, we need more variables when using the > > > > DPDK makefiles to build an application. > > > > > > > > > My opinion is that we should rename our existing "make install" to > > > > something more suitable - my patch suggestion was "make sdk" but it could > > > > be "make target" or something else if people prefer. Once that is done, we > > > > can then look to implement a proper "make install" command that works in a > > > > standard way, perhaps alongside a configure script of some description. > > > > > > > > I think we don't need to rename or move some code. > > > > Just drop and replace some of them. > > > > > > > > The configure script is a great idea but it is a totally different idea. > > > > I do not think that installation and configuration should be related. > > > > Please let's consider "make install" first. > > > > > > > > > For an easy enough solution, I would look to apply this patch to create > > > > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > > > > "make install" command that works in the build dir. That way: > > > > > * you can have existing behavior using "make sdk T=<target>" > > > > > * you can have standard(ish) configure/make/make install behavior using: > > > > > make config T=<target> > > > > > cd build > > > > > make > > > > > make install > > > > > and the "make config" step can subsequently be wrapped in a configure > > > > script to eliminate the need to know what the best target to use is, etc. > > > > > > > > As Panu commented, I do not think it is a good idea to have different > > > > behaviours inside and outside of the build directory. > > > > I would even say that this embedded makefile is only confusing and should > > > > be dropped. > > > > We need to have *one* right building methods, not to bring more confusion. > > > > > > I disagree. I don't think we can have *one* right building method, because to > > > do so means completely throwing away our existing methods of building DPDK > > > and using sample applications. That general method, using RTE_SDK and RTE_TARGET > > > needs to be supported for some time for those projects already familiar with it > > > and using it. > > We can keep it for some time while allowing other tree hierarchies. > > > > As well as this, we also need a sane way of building DPDK inside the "build" > > > directory, and having a "make install" target that installs the libraries > > > and headers inside /usr/local (or whatever was specified as $prefix). > > > > > > With regards to different behavior, since different targets are provided, I > > > don't see it as a problem. In the root directory, "make config" and "make sdk" > > > are provided for backward compatibility. Inside the build directory you have > > > your standard "make" and "make install" commands. Since the command set is > > > very limited, it's easy enough to print a suitable error when the wrong > > > command is used in the wrong place. > > > > By way of follow-up to my own email, I'd also state that I would indeed prefer > > not to have different targets in different places, and that ideally you would > > do configure/make/make-install from the root directory. The reason I suggested > > having "make install" work inside the build directory is because of our > > existing use of "make install" for something different in the root directory. > > This is also the reason I sent out this patch. By renaming the "make install" > > command in 2.2, we give ourselves the option in future releases of adding in > > a new "make install" command that behaves as we want, without having to worry > > about conflict with a legacy make install. > > > > That is why I feel this one patch should go in - it opens up more options for > > us in future releases. It's not an end in itself. :-) > > If we do not agree on something else (I'll try to submit some patches), > yes your patch to introduce "make sdk" will be integrated. > But I'd prefer avoiding to document a new command which will be deprecated > when the new-new "make install" will be implemented. > I think there is another solution (I may be wrong). > > > > Yes, I would like the ideal state where we have one set of build commands that > > > are run from just one location. However, I don't think we can get to that objective > > > without going through a transition phase where we support both old and new options. > > > > > > /Bruce The patch series for standard make install (http://dpdk.org/ml/archives/dev/2015-December/029416.html) demonstrates that it is possible to have a standard make install while keeping the old behaviour. So this patch is marked as rejected in patchwork. To avoid confusion, the name of the old "make install T=" could be renamed in a later release when the new install will be well known. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-12-04 15:57 ` Thomas Monjalon @ 2015-12-04 16:21 ` Richardson, Bruce 0 siblings, 0 replies; 16+ messages in thread From: Richardson, Bruce @ 2015-12-04 16:21 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, December 4, 2015 3:57 PM > To: Richardson, Bruce <bruce.richardson@intel.com> > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > 2015-11-30 15:26, Thomas Monjalon: > > 2015-11-30 11:49, Bruce Richardson: > > > On Mon, Nov 30, 2015 at 11:41:32AM +0000, Richardson, Bruce wrote: > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > > Sent: Monday, November 30, 2015 11:27 AM > > > > > To: Richardson, Bruce <bruce.richardson@intel.com> > > > > > Cc: Panu Matilainen <pmatilai@redhat.com>; dev@dpdk.org; > > > > > olivier.matz@6wind.com > > > > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for > > > > > future use > > > > > > > > > > 2015-11-30 11:08, Richardson, Bruce: > > > > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > > > > > > Why is it a step in the right direction? > > > > > > > > > > > > > > We just need to install the files in a different hierarchy > > > > > > > and adapt the makefiles to be able to compile an application > > > > > > > while keeping the RTE_SDK variable to specify the root > > > > > > > directory (previously built thanks to DESTDIR). > > > > > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > > > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > > > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > > > > > > > > > While doing it, we can have a specific handling of T= to > > > > > > > keep compatibility with the current (old) syntax. > > > > > > > > > > > > > > What have I missed? > > > > > > > > > > > > I'm not sure our existing "make install" is suitable for use > > > > > > for this, > > > > > without having it heavily overloaded. The existing T= behavior > > > > > has support for wildcards and compiling multiple instances at > > > > > the same time - something that won't work with a scheme to > > > > > actually install DPDK throughout the filesystem hierarchy. > > > > > Having it sometimes behave as now, and sometimes behave as a > > > > > standard make install is a bad idea IMHO, as it confuses things. > > > > > Having lots of extra environment variables is also not a great > idea, to my mind. > > > > > > > > > > Yes I agree. > > > > > I forgot to mention it, but in my idea, we can drop the support > > > > > for multiple targets. So the T= compatibility would be only a > > > > > shortcut to do "make config" and name the build directory based on > the template name. > > > > > > > > > > About the environment variables: > > > > > An application requires CFLAGS and LDFLAGS (at least). The > > > > > standard way to provide them is pkgconfig (not implemented yet). > > > > > For applications using the DPDK makefiles, the only input is > RTE_SDK. > > > > > When allowing more tuning in paths, we need more variables when > > > > > using the DPDK makefiles to build an application. > > > > > > > > > > > My opinion is that we should rename our existing "make > > > > > > install" to > > > > > something more suitable - my patch suggestion was "make sdk" but > > > > > it could be "make target" or something else if people prefer. > > > > > Once that is done, we can then look to implement a proper "make > > > > > install" command that works in a standard way, perhaps alongside a > configure script of some description. > > > > > > > > > > I think we don't need to rename or move some code. > > > > > Just drop and replace some of them. > > > > > > > > > > The configure script is a great idea but it is a totally different > idea. > > > > > I do not think that installation and configuration should be > related. > > > > > Please let's consider "make install" first. > > > > > > > > > > > For an easy enough solution, I would look to apply this patch > > > > > > to create > > > > > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to > > > > > have a "make install" command that works in the build dir. That > way: > > > > > > * you can have existing behavior using "make sdk T=<target>" > > > > > > * you can have standard(ish) configure/make/make install > behavior using: > > > > > > make config T=<target> > > > > > > cd build > > > > > > make > > > > > > make install > > > > > > and the "make config" step can subsequently be wrapped in a > > > > > > configure > > > > > script to eliminate the need to know what the best target to use > is, etc. > > > > > > > > > > As Panu commented, I do not think it is a good idea to have > > > > > different behaviours inside and outside of the build directory. > > > > > I would even say that this embedded makefile is only confusing > > > > > and should be dropped. > > > > > We need to have *one* right building methods, not to bring more > confusion. > > > > > > > > I disagree. I don't think we can have *one* right building method, > > > > because to do so means completely throwing away our existing > > > > methods of building DPDK and using sample applications. That > > > > general method, using RTE_SDK and RTE_TARGET needs to be supported > > > > for some time for those projects already familiar with it and using > it. > > > > We can keep it for some time while allowing other tree hierarchies. > > > > > > As well as this, we also need a sane way of building DPDK inside the > "build" > > > > directory, and having a "make install" target that installs the > > > > libraries and headers inside /usr/local (or whatever was specified > as $prefix). > > > > > > > > With regards to different behavior, since different targets are > > > > provided, I don't see it as a problem. In the root directory, "make > config" and "make sdk" > > > > are provided for backward compatibility. Inside the build > > > > directory you have your standard "make" and "make install" > > > > commands. Since the command set is very limited, it's easy enough > > > > to print a suitable error when the wrong command is used in the > wrong place. > > > > > > By way of follow-up to my own email, I'd also state that I would > > > indeed prefer not to have different targets in different places, and > > > that ideally you would do configure/make/make-install from the root > > > directory. The reason I suggested having "make install" work inside > > > the build directory is because of our existing use of "make install" > for something different in the root directory. > > > This is also the reason I sent out this patch. By renaming the "make > install" > > > command in 2.2, we give ourselves the option in future releases of > > > adding in a new "make install" command that behaves as we want, > > > without having to worry about conflict with a legacy make install. > > > > > > That is why I feel this one patch should go in - it opens up more > > > options for us in future releases. It's not an end in itself. :-) > > > > If we do not agree on something else (I'll try to submit some > > patches), yes your patch to introduce "make sdk" will be integrated. > > But I'd prefer avoiding to document a new command which will be > > deprecated when the new-new "make install" will be implemented. > > I think there is another solution (I may be wrong). > > > > > > Yes, I would like the ideal state where we have one set of build > > > > commands that are run from just one location. However, I don't > > > > think we can get to that objective without going through a > transition phase where we support both old and new options. > > > > > > > > /Bruce > > The patch series for standard make install > (http://dpdk.org/ml/archives/dev/2015-December/029416.html) > demonstrates that it is possible to have a standard make install while > keeping the old behaviour. > So this patch is marked as rejected in patchwork. > To avoid confusion, the name of the old "make install T=" could be renamed > in a later release when the new install will be well known. Ok, understood. /Bruce ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-27 17:33 ` Thomas Monjalon 2015-11-30 11:08 ` Richardson, Bruce @ 2015-11-30 12:26 ` Panu Matilainen 2015-11-30 14:19 ` Thomas Monjalon 1 sibling, 1 reply; 16+ messages in thread From: Panu Matilainen @ 2015-11-30 12:26 UTC (permalink / raw) To: Thomas Monjalon, Bruce Richardson; +Cc: dev On 11/27/2015 07:33 PM, Thomas Monjalon wrote: > 2015-11-25 10:48, Panu Matilainen: >> On 11/24/2015 06:54 PM, Bruce Richardson wrote: >>> On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: >>>> 2015-11-06 12:57, Bruce Richardson: >>>>> So, any thoughts or comments on this? There has been lots of discussion in this >>>>> general area but nothing yet going into the release to try and improve the situation. >>>>> >>>>> Are we just going to kick the problem down the road to the 2.3 release? >>>> >>>> I plan to check these patches in the coming days for an integration in 2.2. >>>> >>> Anything further on this? >>> Any thoughts from anyone else about this whole area of a saner build/install >>> system for DPDK and the various patches floating around. >> >> Well, it seems we wont have a sane "make install" in 2.2 yet, but this >> is at least a step in the right direction so +1 from me. > > Why is it a step in the right direction? Right direction as in, everybody seems to agree we want "make install" ultimately do the right thing. If we can't have it in 2.2 yet then a preparatory step is better than not having it. > We just need to install the files in a different hierarchy and adapt > the makefiles to be able to compile an application while keeping the > RTE_SDK variable to specify the root directory (previously built thanks > to DESTDIR). > As the hierarchy could be tuned, we need more variables, e.g.: > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > DPDK_LIB_DIR (default = RTE_SDK/lib) > > While doing it, we can have a specific handling of T= to keep compatibility > with the current (old) syntax. > > What have I missed? Perhaps its me who has missed the fact that 2.2 is still open for these kind of things. If it were up to me, I think I'd just apply Marios latest patch series (perhaps condence it somewhat) to get it over with, fine-tune later if/as necessary. This is veering to the side of bikeshedding real fast. BTW, one noteworthy point is that in all of these related threads, nobody absolutely nobody has spoken up for the current behavior of "make install". Which makes me wonder if anybody is actually using it, and whether all this is just worrying for nothing. - Panu - ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [dpdk-dev] [PATCH] reserve 'make install' for future use 2015-11-30 12:26 ` Panu Matilainen @ 2015-11-30 14:19 ` Thomas Monjalon 0 siblings, 0 replies; 16+ messages in thread From: Thomas Monjalon @ 2015-11-30 14:19 UTC (permalink / raw) To: Panu Matilainen; +Cc: dev 2015-11-30 14:26, Panu Matilainen: > On 11/27/2015 07:33 PM, Thomas Monjalon wrote: > > 2015-11-25 10:48, Panu Matilainen: > >> On 11/24/2015 06:54 PM, Bruce Richardson wrote: > >>> On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: > >>>> 2015-11-06 12:57, Bruce Richardson: > >>>>> So, any thoughts or comments on this? There has been lots of discussion in this > >>>>> general area but nothing yet going into the release to try and improve the situation. > >>>>> > >>>>> Are we just going to kick the problem down the road to the 2.3 release? > >>>> > >>>> I plan to check these patches in the coming days for an integration in 2.2. > >>>> > >>> Anything further on this? > >>> Any thoughts from anyone else about this whole area of a saner build/install > >>> system for DPDK and the various patches floating around. > >> > >> Well, it seems we wont have a sane "make install" in 2.2 yet, but this > >> is at least a step in the right direction so +1 from me. > > > > Why is it a step in the right direction? > > Right direction as in, everybody seems to agree we want "make install" > ultimately do the right thing. If we can't have it in 2.2 yet then a > preparatory step is better than not having it. Yes sure. We will have something in 2.2. The question is what :) > > What have I missed? > > Perhaps its me who has missed the fact that 2.2 is still open for these > kind of things. Yes we still have more than one week before closing the release. We can try some changes in the build system. > If it were up to me, I think I'd just apply Marios latest patch series > (perhaps condence it somewhat) to get it over with, fine-tune later > if/as necessary. This is veering to the side of bikeshedding real fast. > > BTW, one noteworthy point is that in all of these related threads, > nobody absolutely nobody has spoken up for the current behavior of "make > install". Which makes me wonder if anybody is actually using it, and > whether all this is just worrying for nothing. Yes we can break some old behaviours. The T= option should be easy to simulate in a single target case. ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-12-04 16:21 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-06 10:24 [dpdk-dev] [PATCH] reserve 'make install' for future use Bruce Richardson 2015-11-06 10:24 ` [dpdk-dev] [PATCH] mk: rename 'make install' to 'make sdk' Bruce Richardson 2015-11-06 12:57 ` [dpdk-dev] [PATCH] reserve 'make install' for future use Bruce Richardson 2015-11-06 13:04 ` Thomas Monjalon 2015-11-24 16:54 ` Bruce Richardson 2015-11-25 8:48 ` Panu Matilainen 2015-11-27 17:33 ` Thomas Monjalon 2015-11-30 11:08 ` Richardson, Bruce 2015-11-30 11:27 ` Thomas Monjalon 2015-11-30 11:41 ` Richardson, Bruce 2015-11-30 11:49 ` Bruce Richardson 2015-11-30 14:26 ` Thomas Monjalon 2015-12-04 15:57 ` Thomas Monjalon 2015-12-04 16:21 ` Richardson, Bruce 2015-11-30 12:26 ` Panu Matilainen 2015-11-30 14:19 ` Thomas Monjalon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).