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

[Bruce Richardson <bruce.richardson@intel.com>]

On Fri, Oct 02, 2015 at 02:15:29PM +0300, Panu Matilainen 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)
> 
> 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 -

I also think that having some way to get the old behaviour for those relying on
it would be good. Even though it's not ABI affecting, for those compiling from
source it would be nice to follow some sort of gradual deprecation process rather
than just changing everything in one go.

/Bruce