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 0E4548DA3 for ; Tue, 22 Sep 2015 12:36:36 +0200 (CEST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 0806F341AC2; Tue, 22 Sep 2015 10:36:35 +0000 (UTC) Received: from dhcp195.koti.laiskiainen.org (vpn1-6-117.ams2.redhat.com [10.36.6.117]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8MAaXKR011997; Tue, 22 Sep 2015 06:36:34 -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> <56012A12.5030909@redhat.com> From: Panu Matilainen Message-ID: <56012F31.1080800@redhat.com> Date: Tue, 22 Sep 2015 13:36:33 +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: <56012A12.5030909@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 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:36:36 -0000 On 09/22/2015 01:14 PM, Panu Matilainen wrote: > 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. ...so... Talking about "runtime" misses the point, it'd be more like: - install-sdk (for current dpdk specific sdk hierarchy) - install-fhs (for filesystem hierarchy standard) Getting the latter implemented would be the first step (which is what these patches are about, even if the details differ). Changing default behavior is a kind of different question (that I dragged into the picture, sorry for mixing it up).