[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install

Olivier MATZ olivier.matz at 6wind.com
Tue Sep 22 11:00:08 CEST 2015


Hi,

On 09/22/2015 10:34 AM, Panu Matilainen wrote:
> On 09/22/2015 11:00 AM, Olivier MATZ wrote:
>> Actually, the current "install" directive means: install all stuff
>> required to build a project for the specified targets (example:
>> x86_64-native-linuxapp-gcc).
>>
>> If we just do "make install T=${target}", the target is installed
>> into the current SDK source. Adding DESTDIR will install the binary
>> DPDK in a new directory. Example:
>>
>>   make -j32 T="*-native-linuxapp-gcc" DESTDIR=/tmp/binary-dpdk install
>>
>> In both cases, the result can be used to build an application (like
>> the one found in examples) using the the DPDK framework. So, the current
>> "install" directive should be understood as "install binary sdk".
> 
> I know. What it now does is the very problem being addressed :)
> 
> The current behavior is just so alien to the rest of the OSS world it
> actually creates an extra barrier of entry to the project. Besides that,
> it forces people to manually do the cp/mv dance instead - witness
> %install in pkg/dpdk.spec. It also unnecessarily rebuilds stuff when it
> should be just copying.

I agree, I was just trying to summarize what the "install" does
right now, I don't say it's the proper behavior.


>>  From what I understand, what Mario wants to add is a "install runtime
>> libraries" directive.
> 
> Its not limited to runtime libraries, it installs headers and such too.
> The point, AFAICS, is have "make install" do what people actually expect
> it to do - a system-wide installation. Principle of least surprise and all.
> 
>>
>> I agree that using H=1 is maybe not the clearest solution. What about
>> renaming the "install" directive to:
>>    - install-sdk
>>    - install-runtime
>>
>> It would help to keep the current behavior of "install" for some time,
>> marking it as deprecated.
> 
> Nothing wrong with having separate targets for installing runtime- and
> sdk-specific bits, but thats not the point here.

Hmm I think it is.

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.

Regards,
Olivier


More information about the dev mailing list