[dpdk-dev] [PATCH] reserve 'make install' for future use
2015-11-30 15:26, Thomas Monjalon: > 2015-11-30 11:49, Bruce Richardson: > > On Mon, Nov 30, 2015 at 11:41:32AM +, Richardson, Bruce wrote: > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > Sent: Monday, November 30, 2015 11:27 AM > > > > To: Richardson, Bruce > > > > Cc: Panu Matilainen ; dev at dpdk.org; > > > > olivier.matz at 6wind.com > > > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > > > > > > > 2015-11-30 11:08, Richardson, Bruce: > > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > > > Why is it a step in the right direction? > > > > > > > > > > > > We just need to install the files in a different hierarchy and adapt > > > > > > the makefiles to be able to compile an application while keeping the > > > > > > RTE_SDK variable to specify the root directory (previously built > > > > > > thanks to DESTDIR). > > > > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > > > > > > > While doing it, we can have a specific handling of T= to keep > > > > > > compatibility with the current (old) syntax. > > > > > > > > > > > > What have I missed? > > > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > > > > without having it heavily overloaded. The existing T= behavior has > > > > support > > > > for wildcards and compiling multiple instances at the same time - > > > > something that won't work with a scheme to actually install DPDK > > > > throughout the filesystem hierarchy. Having it sometimes behave as now, > > > > and sometimes behave as a standard make install is a bad idea IMHO, as > > > > it > > > > confuses things. Having lots of extra environment variables is also not > > > > a > > > > great idea, to my mind. > > > > > > > > Yes I agree. > > > > I forgot to mention it, but in my idea, we can drop the support for > > > > multiple targets. So the T= compatibility would be only a shortcut to do > > > > "make config" and name the build directory based on the template name. > > > > > > > > About the environment variables: > > > > An application requires CFLAGS and LDFLAGS (at least). The standard way > > > > to > > > > provide them is pkgconfig (not implemented yet). > > > > For applications using the DPDK makefiles, the only input is RTE_SDK. > > > > When allowing more tuning in paths, we need more variables when using > > > > the > > > > DPDK makefiles to build an application. > > > > > > > > > My opinion is that we should rename our existing "make install" to > > > > something more suitable - my patch suggestion was "make sdk" but it > > > > could > > > > be "make target" or something else if people prefer. Once that is done, > > > > we > > > > can then look to implement a proper "make install" command that works > > > > in a > > > > standard way, perhaps alongside a configure script of some description. > > > > > > > > I think we don't need to rename or move some code. > > > > Just drop and replace some of them. > > > > > > > > The configure script is a great idea but it is a totally different idea. > > > > I do not think that installation and configuration should be related. > > > > Please let's consider "make install" first. > > > > > > > > > For an easy enough solution, I would look to apply this patch to > > > > > create > > > > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > > > > "make install" command that works in the build dir. That way: > > > > > * you can have existing behavior using "make sdk T=" > > > > > * you can have standard(ish) configure/make/make install behavior > > > > > using: > > > > > make config T= > > > > > cd build > > > > > make > &g
[dpdk-dev] [PATCH] reserve 'make install' for future use
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, December 4, 2015 3:57 PM > To: Richardson, Bruce > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > 2015-11-30 15:26, Thomas Monjalon: > > 2015-11-30 11:49, Bruce Richardson: > > > On Mon, Nov 30, 2015 at 11:41:32AM +, Richardson, Bruce wrote: > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > > Sent: Monday, November 30, 2015 11:27 AM > > > > > To: Richardson, Bruce > > > > > Cc: Panu Matilainen ; dev at dpdk.org; > > > > > olivier.matz at 6wind.com > > > > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for > > > > > future use > > > > > > > > > > 2015-11-30 11:08, Richardson, Bruce: > > > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > > > > Why is it a step in the right direction? > > > > > > > > > > > > > > We just need to install the files in a different hierarchy > > > > > > > and adapt the makefiles to be able to compile an application > > > > > > > while keeping the RTE_SDK variable to specify the root > > > > > > > directory (previously built thanks to DESTDIR). > > > > > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > > > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > > > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > > > > > > > > > While doing it, we can have a specific handling of T= to > > > > > > > keep compatibility with the current (old) syntax. > > > > > > > > > > > > > > What have I missed? > > > > > > > > > > > > I'm not sure our existing "make install" is suitable for use > > > > > > for this, > > > > > without having it heavily overloaded. The existing T= behavior > > > > > has support for wildcards and compiling multiple instances at > > > > > the same time - something that won't work with a scheme to > > > > > actually install DPDK throughout the filesystem hierarchy. > > > > > Having it sometimes behave as now, and sometimes behave as a > > > > > standard make install is a bad idea IMHO, as it confuses things. > > > > > Having lots of extra environment variables is also not a great > idea, to my mind. > > > > > > > > > > Yes I agree. > > > > > I forgot to mention it, but in my idea, we can drop the support > > > > > for multiple targets. So the T= compatibility would be only a > > > > > shortcut to do "make config" and name the build directory based on > the template name. > > > > > > > > > > About the environment variables: > > > > > An application requires CFLAGS and LDFLAGS (at least). The > > > > > standard way to provide them is pkgconfig (not implemented yet). > > > > > For applications using the DPDK makefiles, the only input is > RTE_SDK. > > > > > When allowing more tuning in paths, we need more variables when > > > > > using the DPDK makefiles to build an application. > > > > > > > > > > > My opinion is that we should rename our existing "make > > > > > > install" to > > > > > something more suitable - my patch suggestion was "make sdk" but > > > > > it could be "make target" or something else if people prefer. > > > > > Once that is done, we can then look to implement a proper "make > > > > > install" command that works in a standard way, perhaps alongside a > configure script of some description. > > > > > > > > > > I think we don't need to rename or move some code. > > > > > Just drop and replace some of them. > > > > > > > > > > The configure script is a great idea but it is a totally different > idea. > > > > > I do not think that installation and configuration should be > related. > > > > > Please let's consider "make install" first. > > > > > > > > > > > For an easy enough solution, I would look to apply this patch > > > > > > to create > >
[dpdk-dev] [PATCH] reserve 'make install' for future use
2015-11-30 11:49, Bruce Richardson: > On Mon, Nov 30, 2015 at 11:41:32AM +, Richardson, Bruce wrote: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > Sent: Monday, November 30, 2015 11:27 AM > > > To: Richardson, Bruce > > > Cc: Panu Matilainen ; dev at dpdk.org; > > > olivier.matz at 6wind.com > > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > > > > > 2015-11-30 11:08, Richardson, Bruce: > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > > Why is it a step in the right direction? > > > > > > > > > > We just need to install the files in a different hierarchy and adapt > > > > > the makefiles to be able to compile an application while keeping the > > > > > RTE_SDK variable to specify the root directory (previously built > > > > > thanks to DESTDIR). > > > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > > > > > While doing it, we can have a specific handling of T= to keep > > > > > compatibility with the current (old) syntax. > > > > > > > > > > What have I missed? > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > > > without having it heavily overloaded. The existing T= behavior has support > > > for wildcards and compiling multiple instances at the same time - > > > something that won't work with a scheme to actually install DPDK > > > throughout the filesystem hierarchy. Having it sometimes behave as now, > > > and sometimes behave as a standard make install is a bad idea IMHO, as it > > > confuses things. Having lots of extra environment variables is also not a > > > great idea, to my mind. > > > > > > Yes I agree. > > > I forgot to mention it, but in my idea, we can drop the support for > > > multiple targets. So the T= compatibility would be only a shortcut to do > > > "make config" and name the build directory based on the template name. > > > > > > About the environment variables: > > > An application requires CFLAGS and LDFLAGS (at least). The standard way to > > > provide them is pkgconfig (not implemented yet). > > > For applications using the DPDK makefiles, the only input is RTE_SDK. > > > When allowing more tuning in paths, we need more variables when using the > > > DPDK makefiles to build an application. > > > > > > > My opinion is that we should rename our existing "make install" to > > > something more suitable - my patch suggestion was "make sdk" but it could > > > be "make target" or something else if people prefer. Once that is done, we > > > can then look to implement a proper "make install" command that works in a > > > standard way, perhaps alongside a configure script of some description. > > > > > > I think we don't need to rename or move some code. > > > Just drop and replace some of them. > > > > > > The configure script is a great idea but it is a totally different idea. > > > I do not think that installation and configuration should be related. > > > Please let's consider "make install" first. > > > > > > > For an easy enough solution, I would look to apply this patch to create > > > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > > > "make install" command that works in the build dir. That way: > > > > * you can have existing behavior using "make sdk T=" > > > > * you can have standard(ish) configure/make/make install behavior using: > > > > make config T= > > > > cd build > > > > make > > > > make install > > > > and the "make config" step can subsequently be wrapped in a configure > > > script to eliminate the need to know what the best target to use is, etc. > > > > > > As Panu commented, I do not think it is a good idea to have different > > > behaviours inside and outside of the build directory. > > > I would even say that this embedded makefile is only confusing and should > > > be dropped. > > > We need to have *one* right building methods, not
[dpdk-dev] [PATCH] reserve 'make install' for future use
2015-11-30 14:26, Panu Matilainen: > On 11/27/2015 07:33 PM, Thomas Monjalon wrote: > > 2015-11-25 10:48, Panu Matilainen: > >> On 11/24/2015 06:54 PM, Bruce Richardson wrote: > >>> On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: > 2015-11-06 12:57, Bruce Richardson: > > So, any thoughts or comments on this? There has been lots of discussion > > in this > > general area but nothing yet going into the release to try and improve > > the situation. > > > > Are we just going to kick the problem down the road to the 2.3 release? > > I plan to check these patches in the coming days for an integration in > 2.2. > > >>> Anything further on this? > >>> Any thoughts from anyone else about this whole area of a saner > >>> build/install > >>> system for DPDK and the various patches floating around. > >> > >> Well, it seems we wont have a sane "make install" in 2.2 yet, but this > >> is at least a step in the right direction so +1 from me. > > > > Why is it a step in the right direction? > > Right direction as in, everybody seems to agree we want "make install" > ultimately do the right thing. If we can't have it in 2.2 yet then a > preparatory step is better than not having it. Yes sure. We will have something in 2.2. The question is what :) > > What have I missed? > > Perhaps its me who has missed the fact that 2.2 is still open for these > kind of things. Yes we still have more than one week before closing the release. We can try some changes in the build system. > If it were up to me, I think I'd just apply Marios latest patch series > (perhaps condence it somewhat) to get it over with, fine-tune later > if/as necessary. This is veering to the side of bikeshedding real fast. > > BTW, one noteworthy point is that in all of these related threads, > nobody absolutely nobody has spoken up for the current behavior of "make > install". Which makes me wonder if anybody is actually using it, and > whether all this is just worrying for nothing. Yes we can break some old behaviours. The T= option should be easy to simulate in a single target case.
[dpdk-dev] [PATCH] reserve 'make install' for future use
On 11/27/2015 07:33 PM, Thomas Monjalon wrote: > 2015-11-25 10:48, Panu Matilainen: >> On 11/24/2015 06:54 PM, Bruce Richardson wrote: >>> On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: 2015-11-06 12:57, Bruce Richardson: > So, any thoughts or comments on this? There has been lots of discussion > in this > general area but nothing yet going into the release to try and improve > the situation. > > Are we just going to kick the problem down the road to the 2.3 release? I plan to check these patches in the coming days for an integration in 2.2. >>> Anything further on this? >>> Any thoughts from anyone else about this whole area of a saner build/install >>> system for DPDK and the various patches floating around. >> >> Well, it seems we wont have a sane "make install" in 2.2 yet, but this >> is at least a step in the right direction so +1 from me. > > Why is it a step in the right direction? Right direction as in, everybody seems to agree we want "make install" ultimately do the right thing. If we can't have it in 2.2 yet then a preparatory step is better than not having it. > We just need to install the files in a different hierarchy and adapt > the makefiles to be able to compile an application while keeping the > RTE_SDK variable to specify the root directory (previously built thanks > to DESTDIR). > As the hierarchy could be tuned, we need more variables, e.g.: > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > DPDK_LIB_DIR (default = RTE_SDK/lib) > > While doing it, we can have a specific handling of T= to keep compatibility > with the current (old) syntax. > > What have I missed? Perhaps its me who has missed the fact that 2.2 is still open for these kind of things. If it were up to me, I think I'd just apply Marios latest patch series (perhaps condence it somewhat) to get it over with, fine-tune later if/as necessary. This is veering to the side of bikeshedding real fast. BTW, one noteworthy point is that in all of these related threads, nobody absolutely nobody has spoken up for the current behavior of "make install". Which makes me wonder if anybody is actually using it, and whether all this is just worrying for nothing. - Panu -
[dpdk-dev] [PATCH] reserve 'make install' for future use
2015-11-30 11:08, Richardson, Bruce: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Why is it a step in the right direction? > > > > We just need to install the files in a different hierarchy and adapt the > > makefiles to be able to compile an application while keeping the RTE_SDK > > variable to specify the root directory (previously built thanks to > > DESTDIR). > > As the hierarchy could be tuned, we need more variables, e.g.: > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > While doing it, we can have a specific handling of T= to keep > > compatibility with the current (old) syntax. > > > > What have I missed? > > > > > I'm not sure our existing "make install" is suitable for use for this, > without having it heavily overloaded. The existing T= behavior has support > for wildcards and compiling multiple instances at the same time - something > that won't work with a scheme to actually install DPDK throughout the > filesystem hierarchy. Having it sometimes behave as now, and sometimes behave > as a standard make install is a bad idea IMHO, as it confuses things. Having > lots of extra environment variables is also not a great idea, to my mind. Yes I agree. I forgot to mention it, but in my idea, we can drop the support for multiple targets. So the T= compatibility would be only a shortcut to do "make config" and name the build directory based on the template name. About the environment variables: An application requires CFLAGS and LDFLAGS (at least). The standard way to provide them is pkgconfig (not implemented yet). For applications using the DPDK makefiles, the only input is RTE_SDK. When allowing more tuning in paths, we need more variables when using the DPDK makefiles to build an application. > My opinion is that we should rename our existing "make install" to something > more suitable - my patch suggestion was "make sdk" but it could be "make > target" or something else if people prefer. Once that is done, we can then > look to implement a proper "make install" command that works in a standard > way, perhaps alongside a configure script of some description. I think we don't need to rename or move some code. Just drop and replace some of them. The configure script is a great idea but it is a totally different idea. I do not think that installation and configuration should be related. Please let's consider "make install" first. > For an easy enough solution, I would look to apply this patch to create "make > sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a "make > install" command that works in the build dir. That way: > * you can have existing behavior using "make sdk T=" > * you can have standard(ish) configure/make/make install behavior using: > make config T= > cd build > make > make install > and the "make config" step can subsequently be wrapped in a configure > script to eliminate the need to know what the best target to use is, etc. As Panu commented, I do not think it is a good idea to have different behaviours inside and outside of the build directory. I would even say that this embedded makefile is only confusing and should be dropped. We need to have *one* right building methods, not to bring more confusion.
[dpdk-dev] [PATCH] reserve 'make install' for future use
On Mon, Nov 30, 2015 at 11:41:32AM +, Richardson, Bruce wrote: > > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Monday, November 30, 2015 11:27 AM > > To: Richardson, Bruce > > Cc: Panu Matilainen ; dev at dpdk.org; > > olivier.matz at 6wind.com > > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > > > 2015-11-30 11:08, Richardson, Bruce: > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > Why is it a step in the right direction? > > > > > > > > We just need to install the files in a different hierarchy and adapt > > > > the makefiles to be able to compile an application while keeping the > > > > RTE_SDK variable to specify the root directory (previously built > > > > thanks to DESTDIR). > > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > > > While doing it, we can have a specific handling of T= to keep > > > > compatibility with the current (old) syntax. > > > > > > > > What have I missed? > > > > > > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > > without having it heavily overloaded. The existing T= behavior has support > > for wildcards and compiling multiple instances at the same time - > > something that won't work with a scheme to actually install DPDK > > throughout the filesystem hierarchy. Having it sometimes behave as now, > > and sometimes behave as a standard make install is a bad idea IMHO, as it > > confuses things. Having lots of extra environment variables is also not a > > great idea, to my mind. > > > > Yes I agree. > > I forgot to mention it, but in my idea, we can drop the support for > > multiple targets. So the T= compatibility would be only a shortcut to do > > "make config" and name the build directory based on the template name. > > > > About the environment variables: > > An application requires CFLAGS and LDFLAGS (at least). The standard way to > > provide them is pkgconfig (not implemented yet). > > For applications using the DPDK makefiles, the only input is RTE_SDK. > > When allowing more tuning in paths, we need more variables when using the > > DPDK makefiles to build an application. > > > > > My opinion is that we should rename our existing "make install" to > > something more suitable - my patch suggestion was "make sdk" but it could > > be "make target" or something else if people prefer. Once that is done, we > > can then look to implement a proper "make install" command that works in a > > standard way, perhaps alongside a configure script of some description. > > > > I think we don't need to rename or move some code. > > Just drop and replace some of them. > > > > The configure script is a great idea but it is a totally different idea. > > I do not think that installation and configuration should be related. > > Please let's consider "make install" first. > > > > > For an easy enough solution, I would look to apply this patch to create > > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > > "make install" command that works in the build dir. That way: > > > * you can have existing behavior using "make sdk T=" > > > * you can have standard(ish) configure/make/make install behavior using: > > > make config T= > > > cd build > > > make > > > make install > > > and the "make config" step can subsequently be wrapped in a configure > > script to eliminate the need to know what the best target to use is, etc. > > > > As Panu commented, I do not think it is a good idea to have different > > behaviours inside and outside of the build directory. > > I would even say that this embedded makefile is only confusing and should > > be dropped. > > We need to have *one* right building methods, not to bring more confusion. > > I disagree. I don't think we can have *one* right building method, because to > do so means completely throwing away our existing methods of building DPDK > and using sample applications. That general method, using RTE_SDK and > RTE_TARGET > needs to be supported for some time for those projects already
[dpdk-dev] [PATCH] reserve 'make install' for future use
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, November 30, 2015 11:27 AM > To: Richardson, Bruce > Cc: Panu Matilainen ; dev at dpdk.org; > olivier.matz at 6wind.com > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > 2015-11-30 11:08, Richardson, Bruce: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > Why is it a step in the right direction? > > > > > > We just need to install the files in a different hierarchy and adapt > > > the makefiles to be able to compile an application while keeping the > > > RTE_SDK variable to specify the root directory (previously built > > > thanks to DESTDIR). > > > As the hierarchy could be tuned, we need more variables, e.g.: > > > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > > > DPDK_LIB_DIR (default = RTE_SDK/lib) > > > > > > While doing it, we can have a specific handling of T= to keep > > > compatibility with the current (old) syntax. > > > > > > What have I missed? > > > > > > > > > I'm not sure our existing "make install" is suitable for use for this, > without having it heavily overloaded. The existing T= behavior has support > for wildcards and compiling multiple instances at the same time - > something that won't work with a scheme to actually install DPDK > throughout the filesystem hierarchy. Having it sometimes behave as now, > and sometimes behave as a standard make install is a bad idea IMHO, as it > confuses things. Having lots of extra environment variables is also not a > great idea, to my mind. > > Yes I agree. > I forgot to mention it, but in my idea, we can drop the support for > multiple targets. So the T= compatibility would be only a shortcut to do > "make config" and name the build directory based on the template name. > > About the environment variables: > An application requires CFLAGS and LDFLAGS (at least). The standard way to > provide them is pkgconfig (not implemented yet). > For applications using the DPDK makefiles, the only input is RTE_SDK. > When allowing more tuning in paths, we need more variables when using the > DPDK makefiles to build an application. > > > My opinion is that we should rename our existing "make install" to > something more suitable - my patch suggestion was "make sdk" but it could > be "make target" or something else if people prefer. Once that is done, we > can then look to implement a proper "make install" command that works in a > standard way, perhaps alongside a configure script of some description. > > I think we don't need to rename or move some code. > Just drop and replace some of them. > > The configure script is a great idea but it is a totally different idea. > I do not think that installation and configuration should be related. > Please let's consider "make install" first. > > > For an easy enough solution, I would look to apply this patch to create > "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a > "make install" command that works in the build dir. That way: > > * you can have existing behavior using "make sdk T=" > > * you can have standard(ish) configure/make/make install behavior using: > > make config T= > > cd build > > make > > make install > > and the "make config" step can subsequently be wrapped in a configure > script to eliminate the need to know what the best target to use is, etc. > > As Panu commented, I do not think it is a good idea to have different > behaviours inside and outside of the build directory. > I would even say that this embedded makefile is only confusing and should > be dropped. > We need to have *one* right building methods, not to bring more confusion. I disagree. I don't think we can have *one* right building method, because to do so means completely throwing away our existing methods of building DPDK and using sample applications. That general method, using RTE_SDK and RTE_TARGET needs to be supported for some time for those projects already familiar with it and using it. As well as this, we also need a sane way of building DPDK inside the "build" directory, and having a "make install" target that installs the libraries and headers inside /usr/local (or whatever was specified as $prefix). With regards to different behavior, since different targets are provided, I don't see it as a problem. In the root directory, "make config" and "make sdk" are provided for backward compatibility. Inside the build directory you have your standard "make" and "make install" commands. Since the command set is very limited, it's easy enough to print a suitable error when the wrong command is used in the wrong place. Yes, I would like the ideal state where we have one set of build commands that are run from just one location. However, I don't think we can get to that objective without going through a transition phase where we support both old and new options. /Bruce
[dpdk-dev] [PATCH] reserve 'make install' for future use
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Friday, November 27, 2015 5:33 PM > To: Panu Matilainen ; Richardson, Bruce > > Cc: dev at dpdk.org; olivier.matz at 6wind.com > Subject: Re: [dpdk-dev] [PATCH] reserve 'make install' for future use > > 2015-11-25 10:48, Panu Matilainen: > > On 11/24/2015 06:54 PM, Bruce Richardson wrote: > > > On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: > > >> 2015-11-06 12:57, Bruce Richardson: > > >>> So, any thoughts or comments on this? There has been lots of > > >>> discussion in this general area but nothing yet going into the > release to try and improve the situation. > > >>> > > >>> Are we just going to kick the problem down the road to the 2.3 > release? > > >> > > >> I plan to check these patches in the coming days for an integration > in 2.2. > > >> > > > Anything further on this? > > > Any thoughts from anyone else about this whole area of a saner > > > build/install system for DPDK and the various patches floating around. > > > > Well, it seems we wont have a sane "make install" in 2.2 yet, but this > > is at least a step in the right direction so +1 from me. > > Why is it a step in the right direction? > > We just need to install the files in a different hierarchy and adapt the > makefiles to be able to compile an application while keeping the RTE_SDK > variable to specify the root directory (previously built thanks to > DESTDIR). > As the hierarchy could be tuned, we need more variables, e.g.: > DPDK_INC_DIR (default = RTE_SDK/include/dpdk) > DPDK_LIB_DIR (default = RTE_SDK/lib) > > While doing it, we can have a specific handling of T= to keep > compatibility with the current (old) syntax. > > What have I missed? > I'm not sure our existing "make install" is suitable for use for this, without having it heavily overloaded. The existing T= behavior has support for wildcards and compiling multiple instances at the same time - something that won't work with a scheme to actually install DPDK throughout the filesystem hierarchy. Having it sometimes behave as now, and sometimes behave as a standard make install is a bad idea IMHO, as it confuses things. Having lots of extra environment variables is also not a great idea, to my mind. My opinion is that we should rename our existing "make install" to something more suitable - my patch suggestion was "make sdk" but it could be "make target" or something else if people prefer. Once that is done, we can then look to implement a proper "make install" command that works in a standard way, perhaps alongside a configure script of some description. For an easy enough solution, I would look to apply this patch to create "make sdk" and also http://dpdk.org/dev/patchwork/patch/8076/ to have a "make install" command that works in the build dir. That way: * you can have existing behavior using "make sdk T=" * you can have standard(ish) configure/make/make install behavior using: make config T= cd build make make install and the "make config" step can subsequently be wrapped in a configure script to eliminate the need to know what the best target to use is, etc. /Bruce
[dpdk-dev] [PATCH] reserve 'make install' for future use
2015-11-25 10:48, Panu Matilainen: > On 11/24/2015 06:54 PM, Bruce Richardson wrote: > > On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: > >> 2015-11-06 12:57, Bruce Richardson: > >>> So, any thoughts or comments on this? There has been lots of discussion > >>> in this > >>> general area but nothing yet going into the release to try and improve > >>> the situation. > >>> > >>> Are we just going to kick the problem down the road to the 2.3 release? > >> > >> I plan to check these patches in the coming days for an integration in 2.2. > >> > > Anything further on this? > > Any thoughts from anyone else about this whole area of a saner build/install > > system for DPDK and the various patches floating around. > > Well, it seems we wont have a sane "make install" in 2.2 yet, but this > is at least a step in the right direction so +1 from me. Why is it a step in the right direction? We just need to install the files in a different hierarchy and adapt the makefiles to be able to compile an application while keeping the RTE_SDK variable to specify the root directory (previously built thanks to DESTDIR). As the hierarchy could be tuned, we need more variables, e.g.: DPDK_INC_DIR (default = RTE_SDK/include/dpdk) DPDK_LIB_DIR (default = RTE_SDK/lib) While doing it, we can have a specific handling of T= to keep compatibility with the current (old) syntax. What have I missed?
[dpdk-dev] [PATCH] reserve 'make install' for future use
On 11/24/2015 06:54 PM, Bruce Richardson wrote: > On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: >> 2015-11-06 12:57, Bruce Richardson: >>> So, any thoughts or comments on this? There has been lots of discussion in >>> this >>> general area but nothing yet going into the release to try and improve the >>> situation. >>> >>> Are we just going to kick the problem down the road to the 2.3 release? >> >> I plan to check these patches in the coming days for an integration in 2.2. >> > Anything further on this? > Any thoughts from anyone else about this whole area of a saner build/install > system for DPDK and the various patches floating around. Well, it seems we wont have a sane "make install" in 2.2 yet, but this is at least a step in the right direction so +1 from me. - Panu -
[dpdk-dev] [PATCH] reserve 'make install' for future use
On Fri, Nov 06, 2015 at 02:04:54PM +0100, Thomas Monjalon wrote: > 2015-11-06 12:57, Bruce Richardson: > > So, any thoughts or comments on this? There has been lots of discussion in > > this > > general area but nothing yet going into the release to try and improve the > > situation. > > > > Are we just going to kick the problem down the road to the 2.3 release? > > I plan to check these patches in the coming days for an integration in 2.2. > Anything further on this? Any thoughts from anyone else about this whole area of a saner build/install system for DPDK and the various patches floating around. /Bruce
[dpdk-dev] [PATCH] reserve 'make install' for future use
2015-11-06 12:57, Bruce Richardson: > So, any thoughts or comments on this? There has been lots of discussion in > this > general area but nothing yet going into the release to try and improve the > situation. > > Are we just going to kick the problem down the road to the 2.3 release? I plan to check these patches in the coming days for an integration in 2.2.
[dpdk-dev] [PATCH] reserve 'make install' for future use
So, any thoughts or comments on this? There has been lots of discussion in this general area but nothing yet going into the release to try and improve the situation. Are we just going to kick the problem down the road to the 2.3 release? /Bruce On Fri, Nov 06, 2015 at 10:24:13AM +, Bruce Richardson wrote: > There has been some discussion on the list about various ways to get DPDK more > standardised in how it compiles and how it can be installed into a system as > a set of binaries. > > One of the issues we face in that is that the 'make install' command is used > in > DPDK to compile a copy of the SDK but not to place the resultant binaries in > the > filesystem like other packages do. In order to allow us to have the option to > use 'make install' in its common meaning in a future release we need to > replace > it in our packages, and allow some time for the change to a new command to > bed-in. > > This patchset therefore proposed to change "make install" to "make sdk" [and > "make uninstall" to "make clean-sdk"]. Using the old commands now prints out > an error message informing the user to use the new versions. > > These new commands are ones that made sense to me - I'm happy enough to change > them for something else people feel is more appropriate. The key point here is > to move away from using "make install". > > I would ask that if general agreement on this can be reached that such a > change > be considered for 2.2, even though it is late in the day, as "freeing up" the > make install command will potentially take multiple releases as not everyone > is > on the latest version, and so waiting till 2.3 to make a change will push out > any future re-use of a "make install" command by 4 months. > > Regards, > /Bruce > > Bruce Richardson (1): > mk: rename 'make install' to 'make sdk' > > doc/guides/freebsd_gsg/build_dpdk.rst| 16 ++--- > doc/guides/linux_gsg/build_dpdk.rst | 22 +++--- > doc/guides/nics/intel_vf.rst | 2 +- > doc/guides/prog_guide/dev_kit_root_make_help.rst | 18 ++--- > doc/guides/sample_app_ug/tep_termination.rst | 3 +- > doc/guides/sample_app_ug/vhost.rst | 3 +- > doc/guides/testpmd_app_ug/build_app.rst | 2 +- > doc/guides/xen/pkt_switch.rst| 2 +- > mk/rte.sdk.mk| 88 > > mk/rte.sdkinstall.mk | 87 --- > mk/rte.sdkroot.mk| 13 +++- > scripts/gen-build-mk.sh | 2 +- > 12 files changed, 133 insertions(+), 125 deletions(-) > create mode 100644 mk/rte.sdk.mk > delete mode 100644 mk/rte.sdkinstall.mk > > -- > 2.5.0 >
[dpdk-dev] [PATCH] reserve 'make install' for future use
There has been some discussion on the list about various ways to get DPDK more standardised in how it compiles and how it can be installed into a system as a set of binaries. One of the issues we face in that is that the 'make install' command is used in DPDK to compile a copy of the SDK but not to place the resultant binaries in the filesystem like other packages do. In order to allow us to have the option to use 'make install' in its common meaning in a future release we need to replace it in our packages, and allow some time for the change to a new command to bed-in. This patchset therefore proposed to change "make install" to "make sdk" [and "make uninstall" to "make clean-sdk"]. Using the old commands now prints out an error message informing the user to use the new versions. These new commands are ones that made sense to me - I'm happy enough to change them for something else people feel is more appropriate. The key point here is to move away from using "make install". I would ask that if general agreement on this can be reached that such a change be considered for 2.2, even though it is late in the day, as "freeing up" the make install command will potentially take multiple releases as not everyone is on the latest version, and so waiting till 2.3 to make a change will push out any future re-use of a "make install" command by 4 months. Regards, /Bruce Bruce Richardson (1): mk: rename 'make install' to 'make sdk' doc/guides/freebsd_gsg/build_dpdk.rst| 16 ++--- doc/guides/linux_gsg/build_dpdk.rst | 22 +++--- doc/guides/nics/intel_vf.rst | 2 +- doc/guides/prog_guide/dev_kit_root_make_help.rst | 18 ++--- doc/guides/sample_app_ug/tep_termination.rst | 3 +- doc/guides/sample_app_ug/vhost.rst | 3 +- doc/guides/testpmd_app_ug/build_app.rst | 2 +- doc/guides/xen/pkt_switch.rst| 2 +- mk/rte.sdk.mk| 88 mk/rte.sdkinstall.mk | 87 --- mk/rte.sdkroot.mk| 13 +++- scripts/gen-build-mk.sh | 2 +- 12 files changed, 133 insertions(+), 125 deletions(-) create mode 100644 mk/rte.sdk.mk delete mode 100644 mk/rte.sdkinstall.mk -- 2.5.0
