DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier MATZ <olivier.matz@6wind.com>
To: "Arevalo, Mario Alfredo C" <mario.alfredo.c.arevalo@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] dpdk proposal installation process
Date: Wed, 21 Oct 2015 21:15:02 +0200	[thread overview]
Message-ID: <5627E436.2050106@6wind.com> (raw)
In-Reply-To: <20151020091728.GA17840@bricha3-MOBL3>

Hi Mario,

On 10/20/2015 11:17 AM, Bruce Richardson wrote:
> On Tue, Oct 20, 2015 at 12:21:00AM +0000, Arevalo, Mario Alfredo C wrote:
>> Hi folks,
>>
>>       Good day, this is a proposal in order to improve the dpdk install process,
>> I would like to know your point of view about the next points according to
>> previous conversations :) in order to create a new patches version.
>>
>> 1) I think the first thing that I have to be aware is "compatibility", the
>> new changes won't affect the current dpdk behaviour.

Yes. As I stated in a previous mail, I think nobody uses the current
"make install" without specifying T= as the default value is to build
and install for all targets.

My suggestion is:

- rename the previous "install" target. The name could probably
  be "mbuild" (for multiple builds). Other ideas are welcome.

- when "make install" is invoked with T= argument, call the mbuild
  target to have the same behavior than before. This compat layer
  could be removed in the future.

- when "make install" is invoked without T=, it installs the fhs.

>> 2) Create new makefile rules, these rules is going to install dpdk files in
>> default paths, however the linux distributions don't use the same paths for their
>> files, the linux distribution and the architecture can be factor for different
>> path as Panu commented in previous conversations, he is right, then all variables
>> could be overridden, the variables names for the user can be included in documentation.
>> Also an option could be a configuration file for paths, however I'm not sure.

I think having variables is ok.

>> 3) The default paths for dpdk in order to follow a hierarchy, however the variable
>> with those values can be overridden.
>>
>> -install-bin          --> /usr/bin.
>> -install-headers  --> /usr/include/dpdk
>> -install-lib           --> /usr/lib64

I remember Panu suggested to have /usr/lib by default.
I also think /usr/lib a better default value: some distributions
use /usr/lib for 64 bits libs, but we never have 32 bits libs in
/usr/lib64.

>> -install-doc         --> /usr/share/doc/dpdk
>> -install-mod        --> if RTE_EXEC_ENV=linuxapp then KERNEL_DIR=/lib/modules/$(uname -r)/extra/drivers/dpdk
>>                                 else KERNEL_DIR=/boot/modules).

I'm not sure KERNEL_DIR is the proper name. Maybe KMOD_DIR?

>> -install-sdk         --> /usr/share/dpdk and call install-headers ).
>> -install-fhs          --> call install-libraries, install-mod, install-bin and install-doc (maybe install-headers)
>>
>> 4) I'm going to take account all feedback about variables, paths etc for the new version :).
>>
>> Thank you so much for your help.
>>
>>
>> Mario.
> 
> Hi Mario,
> 
> that seems like a lot of commands to add - are they all individually needed?
> 
> In terms of where things go, should the "usr" part not a) be configurable via
> a parameter, and b) default to "/usr/local" as that's where user-installed
> software from outside the packaging system normally gets put.

A PREFIX variable would do the job.
About the default to /usr or /usr/local, I agree that /usr/local looks
more usual, and I don't think it's a problem for packaging as soon as
it can be overridden.


Regards,
Olivier

  reply	other threads:[~2015-10-21 19:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <6594B51DBE477C48AAE23675314E6C460F1B724F@fmsmsx107.amr.corp.intel.com>
2015-10-20  9:17 ` Bruce Richardson
2015-10-21 19:15   ` Olivier MATZ [this message]
2015-10-22  5:55     ` Panu Matilainen
2015-10-22 14:57       ` Bruce Richardson
2015-10-26 16:18         ` Arevalo, Mario Alfredo C
2015-10-27 14:25           ` [dpdk-dev] compile and install using configure-make-make_install Bruce Richardson
2015-10-27 14:25             ` [dpdk-dev] [RFC-PATCH 1/2] gen-build-mk: add "make install" option to build dir Bruce Richardson
2015-10-27 14:25             ` [dpdk-dev] [RFC-PATCH 2/2] add example configure script Bruce Richardson
2015-11-03  7:35             ` [dpdk-dev] compile and install using configure-make-make_install Panu Matilainen
2015-11-03 10:16               ` Bruce Richardson
2015-11-27 11:50           ` [dpdk-dev] dpdk proposal installation process Thomas Monjalon
2015-11-27 13:16         ` Marc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5627E436.2050106@6wind.com \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    --cc=mario.alfredo.c.arevalo@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).