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 >
