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 97E698D9E for ; Tue, 22 Sep 2015 12:14:44 +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 EF3352F90E4; Tue, 22 Sep 2015 10:14:43 +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 t8MAEgjH007600; Tue, 22 Sep 2015 06:14:43 -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> <56011296.7060502@redhat.com> <56011898.6090207@6wind.com> From: Panu Matilainen Message-ID: <56012A12.5030909@redhat.com> Date: Tue, 22 Sep 2015 13:14:42 +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: <56011898.6090207@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 10:14:45 -0000 On 09/22/2015 12:00 PM, Olivier MATZ wrote: > Hi, > > On 09/22/2015 10:34 AM, Panu Matilainen wrote: >> On 09/22/2015 11:00 AM, Olivier MATZ wrote: >>> 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. > > I agree, I was just trying to summarize what the "install" does > right now, I don't say it's the proper behavior. Oh, ok. >>> 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. > > Hmm I think it is. "make install" usually installs everything, including headers, documentation etc on top of binaries and libraries. Thats more or less what the patches here do. For packaging purposes they're usually split up to different sub-packages and in the make-system there usually are separate targets for the individual elements like install-doc. The notion of SDK in DPDK is something entirely different from how the average OSS project is used in development of other software. Some projects like pktgen-dpdk rely on the SDK structure, mk snippets and scripts and all, others like openvswitch try to deal with it more like it was any old OSS citizen. 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. > > 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. - Panu - > > Regards, > Olivier >