[dpdk-dev] dpdk proposal installation process

[Marc]

On 22 October 2015 at 16:57, Bruce Richardson <bruce.richardson at intel.com>
wrote:

> On Thu, Oct 22, 2015 at 08:55:41AM +0300, Panu Matilainen wrote:
> > On 10/21/2015 10:15 PM, Olivier MATZ wrote:
> > >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.
> >
> > Nice, this sounds like the best of both worlds.
> >
> > >
> > >>>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.
> >
> > Yes, just stick /usr/lib there and be done with it, lib64 is not a good
> > default for these very reasons.
> >
> > >>>-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.
> >
> > Yeah, PREFIX support would be nice, and defaulting that to /usr/local
> would
> > be the right thing.
> >
> >       - Panu -
> >
> > >
> > >
> > >Regards,
> > >Olivier
> > >
> >
>
> Can I throw a completely different suggestion into the mix?
>
> Can we make use of the fact that make config creates a directory called
> "build"
> by default. Then running "make" alone in that directory does the expected
> behaviour of a compile of the whole sdk. How about having "make install"
> in the
> build directory behave like a generic "make install" call for other
> packages?
>
> I'm imagining the following sequence of steps to install:
>
>         ./configure --machine=[default|native|other]
>                 # configure is a simple script that just calls "make
> config T=..."
>         cd build
>

Why not the inverse, configure in the folder where you build so that you
have all the compilation environment in the target folder  (as in
autoconf+automake and as of now in DPDK). You can have easily parallel
builds in different folders.



>         make
>         make install
>

If you want this workflow, why not directly using autoconf + maybe the
config file there is now (since there are a ton of parameters)? Putting
general configuration parameters into configure.ac and leave the rest to
the config files.

The PREFIX and installation of files is something that automake+autoconf
solves too (probably without libtool for DPDK).

In any case, for install-fhs, I would name it install-all, to make it
consistent with typical autotools build envs, which is what users are used
to.

Marc



> Thoughts?
>
> /Bruce
>