From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id EF4A59E5 for ; Tue, 22 Sep 2015 10:34:32 +0200 (CEST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 4B3C2AD00A; Tue, 22 Sep 2015 08:34:32 +0000 (UTC) Received: from dhcp195.koti.laiskiainen.org (vpn1-6-117.ams2.redhat.com [10.36.6.117]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8M8YUiM020882; Tue, 22 Sep 2015 04:34:31 -0400 To: Olivier MATZ , Mario Carrillo , dev@dpdk.org References: <1442608390-12537-1-git-send-email-mario.alfredo.c.arevalo@intel.com> <5600F549.20000@redhat.com> <56010A91.5020607@6wind.com> From: Panu Matilainen Message-ID: <56011296.7060502@redhat.com> Date: Tue, 22 Sep 2015 11:34:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <56010A91.5020607@6wind.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Subject: Re: [dpdk-dev] [PATCH 0/7] Add hierarchical support to make install X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 08:34:33 -0000 On 09/22/2015 11:00 AM, Olivier MATZ wrote: > Hi, > > On 09/22/2015 08:29 AM, Panu Matilainen wrote: >> On 09/18/2015 11:33 PM, Mario Carrillo wrote: >>> DPDK package lacks of a mechanism to install libraries, headers >>> applications and kernel modules 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 >>> >>> 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. >> >> Thanks for working on this! >> >> My 5c is that I'd rather see "make install" do the right thing (as in, >> behave like a normal OSS project) by default instead of requiring some >> obscure additional parameter (which almost nobody will then find) to >> activate it. > > Actually, the current "install" directive means: install all stuff > required to build a project for the specified targets (example: > x86_64-native-linuxapp-gcc). > > If we just do "make install T=${target}", the target is installed > into the current SDK source. Adding DESTDIR will install the binary > DPDK in a new directory. Example: > > make -j32 T="*-native-linuxapp-gcc" DESTDIR=/tmp/binary-dpdk install > > In both cases, the result can be used to build an application (like > the one found in examples) using the the DPDK framework. So, the current > "install" directive should be understood as "install binary sdk". I know. What it now does is the very problem being addressed :) The current behavior is just so alien to the rest of the OSS world it actually creates an extra barrier of entry to the project. Besides that, it forces people to manually do the cp/mv dance instead - witness %install in pkg/dpdk.spec. It also unnecessarily rebuilds stuff when it should be just copying. > From what I understand, what Mario wants to add is a "install runtime > libraries" directive. Its not limited to runtime libraries, it installs headers and such too. The point, AFAICS, is have "make install" do what people actually expect it to do - a system-wide installation. Principle of least surprise and all. > > I agree that using H=1 is maybe not the clearest solution. What about > renaming the "install" directive to: > - install-sdk > - install-runtime > > It would help to keep the current behavior of "install" for some time, > marking it as deprecated. Nothing wrong with having separate targets for installing runtime- and sdk-specific bits, but thats not the point here. - Panu -