Hi, On 09/22/2015 12:14 PM, Panu Matilainen wrote: > In my packaging of DPDK I ended up providing both: headers, libraries > etc in the normal system paths, and then a separate dpdk-sdk directory > holding the SDK-parts like mk bits and symlinking to the libs and > headers as needed, so that you can actually point RTE_SDK to that > dpdk-sdk dir and be able to build apps against the thing.
Great, it didn't know that. >> My question is: do we want to keep the current install behavior for >> compatibility or not? Should we consider this makefile directive as >> an API? People may use it, and we should at least ask us it it should >> follow a sort of API deprecation process like we do for the code. >> That's why I talked about 2 new commands and deprecate the old one. > > I'd be surprised if somebody somewhere isn't relying on the current > specific behavior, given its explicitly documented and all. Whether it > needs to stay, and whether it needs to stay as the default ... I > wouldn't miss it, but its a question for those using and depending on it > really. Ok. So if nobody else complains, I have no objection to change the default behavior of "make install" to this which indeed looks more usual and distribution-friendly. In this case we may remove the old one, it's probably better than having a H=1 option. Regards, Olivier
