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
make
make install
Thoughts?
/Bruce
