[dpdk-dev] [PATCH 03/10] mk: install a standard cutomizable tree

[Panu Matilainen]

On 12/02/2015 01:25 PM, Thomas Monjalon wrote:
> 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?

That, plus modern Debian/Ubuntu supports multiarch, not just -lib.

And then there's the pedantic side, ie to be in line with the FHS 
definition: 
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA

>
>> 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).

Just realized my suggestion $(sdkdir)/$(T) would not cut it because if 
T= is specified then this installation method wont be invoked at all :D

So yeah, RTE_TARGET. Or perhaps just RTE_ARCH. Dunno if there's actual 
added value to having the whole target string there, but I wont mind either.

>
>> $(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.

The problem probably had to do with something external, like compiling 
OVS or pktgen, but ... this is too hand-wavy to worry about right now. 
Just wanted to mention it because I dont think I added the extra 
complexity in packaging just for fun.

	- Panu -