[dpdk-dev] [PATCH v3 8/8] mk: Add rule for installing runtime files

[Jan Blunck]

On Fri, Oct 2, 2015 at 12:15 PM, Panu Matilainen <pmatilai at redhat.com> wrote:
> On 10/01/2015 03:11 AM, Mario Carrillo wrote:
>>
>> Add hierarchy-file support to the DPDK libraries, modules,
>> binary files, nic bind files and documentation,
>> when invoking "make install-fhs" (filesystem hierarchy standard)
>> runtime files will be by default installed in:
>> $(DESTDIR)/$(BIN_DIR) where BIN_DIR=/usr/bin (binary files)
>> $(DESTDIR)/$(SBIN_DIR) where SBIN_DIR=/usr/sbin/dpdk_nic_bind (nic bind
>> files)
>> $(DESTDIR)/$(DOC_DIR) where DOC_DIR=/usr/share/doc/dpdk (documentation)
>> $(DESTDIR)/$(LIB_DIR)  (libraries)
>> if the architecture is 64 bits then LIB_DIR=/usr/lib64
>> else LIB_DIR=/usr/lib
>> $(DESTDIR)/$(KERNEL_DIR) (modules)
>> if RTE_EXEC_ENV=linuxapp then
>> KERNEL_DIR=/lib/modules/$(uname -r)/build
>> else KERNEL_DIR=/boot/modules
>> All directory variables mentioned above can be overridden.
>> This hierarchy is based on:
>> http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
>>
>
> Hmm, I think there's a slight misunderstanding here.
>
> What I meant earlier by install-sdk and install-fhs is to preserve the
> current behavior of "make install" as "make install-sdk" and have "make
> install-fhs" behave like normal OSS app on "make install", which installs
> everything (both devel and runtime parts)

>From my point of view it would make sense let 'make install' do the
right thing from
a user perspective (application, library, distribution). The standard
workflow of 'make install'
is well known and supported by many build environments.

One way that could work is to detect the fact that the SDK files are
already installed (e.g.
via $RTE_SDK != $(pwd) ) and in that case skipping the install of them.

Thanks,
Jan

> This patch series eliminates the current behavior of "make install"
> entirely. I personally would not miss it at all, but there likely are people
> relying on it since its quite visibly documented and all. So I think the
> idea was to introduce a separate FHS-installation target and then deal with
> the notion of default behaviors etc separately.
>
> I guess it was already this way in v2 of the series, apologies for missing
> it there.
>
>         - Panu -