From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas.monjalon@6wind.com>
Subject: Re: [PATCH 03/10] mk: install a standard cutomizable tree
Date: Wed, 02 Dec 2015 12:25:26 +0100
Message-ID: <1789607.LxQySkSOJm@xps13>
References: <1449028676-19232-1-git-send-email-thomas.monjalon@6wind.com>
 <1449028676-19232-4-git-send-email-thomas.monjalon@6wind.com>
 <565EC77B.6060807@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org
To: Panu Matilainen <pmatilai@redhat.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51])
 by dpdk.org (Postfix) with ESMTP id 9CA088D86
 for <dev@dpdk.org>; Wed,  2 Dec 2015 12:26:36 +0100 (CET)
Received: by wmvv187 with SMTP id v187so249953316wmv.1
 for <dev@dpdk.org>; Wed, 02 Dec 2015 03:26:36 -0800 (PST)
In-Reply-To: <565EC77B.6060807@redhat.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

2015-12-02 12:27, Panu Matilainen:
> On 12/02/2015 05:57 AM, Thomas Monjalon wrote:
> > The old installed tree was static and always had .config, includes and
> > libs in a RTE_TARGET subdirectory. There is no such directory anymore in
> > an installed SDK. So the top directory is checked.
> > But RTE_TARGET can still be used, especially to build an app with a
> > compiled but not installed SDK.
> > That's why both cases are looked for RTE_SDK_BIN.
[...]
> > The old usage of an installed SDK is:
> >      make -C examples/helloworld RTE_SDK=$(readlink -m $DESTDIR) \
> >           RTE_TARGET=x86_64-native-linuxapp-gcc
> > RTE_TARGET can be specified but is useless now with an installed SDK.
> > The RTE_SDK directory must now point to a different path depending of
> > the installation.
[...]
> > +	$(Q)$(call rte_mkdir,                            $(DESTDIR)$(sdkdir))
> > +	$(Q)cp -a               $(BUILD_DIR)/.config     $(DESTDIR)$(sdkdir)
> > +	$(Q)cp -a               $(RTE_SDK)/{mk,scripts}  $(DESTDIR)$(sdkdir)
> > +	$(Q)$(call rte_symlink, $(DESTDIR)$(includedir), $(DESTDIR)$(sdkdir)/include)
> > +	$(Q)$(call rte_symlink, $(DESTDIR)$(libdir),     $(DESTDIR)$(sdkdir)/lib)
> 
> $(prefix)/share is supposed to be shareable across different 
> architectures. Most of the content here is, but at least the lib symlink 
> and .config file are not.

The case you want to address is multilib 32/x32/64, right?

> One option is to install .config and the symlinks within $(sdkdir)/$(T) 
> directories, then it can be shared across architectures because each 
> lives in their own directory. Another possibility is moving the whole 
> sdk directory into a subdir in $(libdir), but that misses the 
> opportunity to share across architectures (whether anybody actually 
> cares is a whole other question :)

Yes, I tried to remove the use of RTE_TARGET when building an example.
But we can keep it with a subdirectory in $(sdkdir).

> $(sdkdir)/lib -> $(libdir) symlink seems reasonable when installing to 
> an empty staging root, but on a real-world installation it'd point to 
> /usr/lib(something) which has hundreds or thousands of other unrelated 
> libraries. My memory is hazy on details but I think this caused an 
> actual problem with something because I ended up $(sdkdir)/lib an actual 
> directory populated with symlinks to the individual DPDK libraries.

I don't see the problem.
I suggest to keep it and see how to fix it if an issue is raised.