[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
Hi, Thanks you for your feedback, I?ll send a version 2 based on last comments. Thanks, Mario From: Olivier MATZ [olivier.m...@6wind.com] Sent: Tuesday, September 22, 2015 7:40 AM To: Panu Matilainen; Arevalo, Mario Alfredo C; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/7] Add hierarchical support to make install 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
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
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
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
On 09/22/2015 01:14 PM, Panu Matilainen wrote:
> On 09/22/2015 12:00 PM, Olivier MATZ wrote:
>> 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.
>
> Oh, ok.
>
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.
>
> "make install" usually installs everything, including headers,
> documentation etc on top of binaries and libraries. Thats more or less
> what the patches here do. For packaging purposes they're usually split
> up to different sub-packages and in the make-system there usually are
> separate targets for the individual elements like install-doc.
>
> The notion of SDK in DPDK is something entirely different from how the
> average OSS project is used in development of other software. Some
> projects like pktgen-dpdk rely on the SDK structure, mk snippets and
> scripts and all, others like openvswitch try to deal with it more like
> it was any old OSS citizen.
...so...
Talking about "runtime" misses the point, it'd be more like:
- install-sdk (for current dpdk specific sdk hierarchy)
- install-fhs (for filesystem hierarchy standard)
Getting the latter implemented would be the first step (which is what
these patches are about, even if the details differ). Changing default
behavior is a kind of different question (that I dragged into the
picture, sorry for mixing it up).
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
On 09/22/2015 12:00 PM, Olivier MATZ wrote:
> 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.
Oh, ok.
>>> 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.
"make install" usually installs everything, including headers,
documentation etc on top of binaries and libraries. Thats more or less
what the patches here do. For packaging purposes they're usually split
up to different sub-packages and in the make-system there usually are
separate targets for the individual elements like install-doc.
The notion of SDK in DPDK is something entirely different from how the
average OSS project is used in development of other software. Some
projects like pktgen-dpdk rely on the SDK structure, mk snippets and
scripts and all, others like openvswitch try to deal with it more like
it was any old OSS citizen.
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.
>
> 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.
- Panu -
>
> Regards,
> Olivier
>
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
On 09/22/2015 11:00 AM, Olivier MATZ wrote:
> Hi,
>
> On 09/22/2015 08:29 AM, Panu Matilainen wrote:
>> On 09/18/2015 11:33 PM, Mario Carrillo wrote:
>>> DPDK package lacks of a mechanism to install libraries, headers
>>> applications and kernel modules to a file system tree.
>>>
>>> This patch set allows to install files according to the next
>>> proposal:
>>> http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
>>>
>>> By adding a parameter H=1 (hierarchy-file) to makefile system, it is
>>> possible to do the next steps
>>>
>>> make config T=TARGET
>>> make
>>> make install H=1
>>>
>>> and files will be installed on the proper directory. Also you can use
>>> the DESTDIR variable.
>>
>> Thanks for working on this!
>>
>> My 5c is that I'd rather see "make install" do the right thing (as in,
>> behave like a normal OSS project) by default instead of requiring some
>> obscure additional parameter (which almost nobody will then find) to
>> activate it.
>
> 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.
> 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.
- Panu -
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
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
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
Hi Mario, On 09/18/2015 10:33 PM, Mario Carrillo wrote: > DPDK package lacks of a mechanism to install libraries, headers > applications and kernel modules to a file system tree. > > This patch set allows to install files according to the next > proposal: > http://www.freedesktop.org/software/systemd/man/file-hierarchy.html > > By adding a parameter H=1 (hierarchy-file) to makefile system, it is > possible to do the next steps > > make config T=TARGET > make > make install H=1 The current "install" target is not designed to work on one build directory. Instead, it takes as a parameter a list of config templates, and the build directory is the name of the target. Today, we have: make install T="*-native-linuxapp-gcc" is somehow equivalent to: make config T=i686-native-linuxapp-gcc O=i686-native-linuxapp-gcc make O=i686-native-linuxapp-gcc make config T=x86_32-native-linuxapp-gcc O=x86_32-native-linuxapp-gcc make O=x86_32-native-linuxapp-gcc make config T=x86_64-native-linuxapp-gcc O=x86_64-native-linuxapp-gcc make O=x86_64-native-linuxapp-gcc The "install H=1" directive you are adding seems to implicitly be working on a build directory (modifiable with O=), which is the case for the "make" command but not for the current "make install". I'm in favor of having different command names for installing a binary sdk and for installing the runtime libs in the hierarchical file system, this to avoid having different behaviors for the same name. Regards, Olivier
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
Hi,
On 09/22/2015 08:29 AM, Panu Matilainen wrote:
> On 09/18/2015 11:33 PM, Mario Carrillo wrote:
>> DPDK package lacks of a mechanism to install libraries, headers
>> applications and kernel modules to a file system tree.
>>
>> This patch set allows to install files according to the next
>> proposal:
>> http://www.freedesktop.org/software/systemd/man/file-hierarchy.html
>>
>> By adding a parameter H=1 (hierarchy-file) to makefile system, it is
>> possible to do the next steps
>>
>> make config T=TARGET
>> make
>> make install H=1
>>
>> and files will be installed on the proper directory. Also you can use
>> the DESTDIR variable.
>
> Thanks for working on this!
>
> My 5c is that I'd rather see "make install" do the right thing (as in,
> behave like a normal OSS project) by default instead of requiring some
> obscure additional parameter (which almost nobody will then find) to
> activate it.
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".
>From what I understand, what Mario wants to add is a "install runtime
libraries" directive.
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.
Regards,
Olivier
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
On 09/18/2015 11:33 PM, Mario Carrillo wrote: > DPDK package lacks of a mechanism to install libraries, headers > applications and kernel modules to a file system tree. > > This patch set allows to install files according to the next > proposal: > http://www.freedesktop.org/software/systemd/man/file-hierarchy.html > > By adding a parameter H=1 (hierarchy-file) to makefile system, it is > possible to do the next steps > > make config T=TARGET > make > make install H=1 > > and files will be installed on the proper directory. Also you can use > the DESTDIR variable. Thanks for working on this! My 5c is that I'd rather see "make install" do the right thing (as in, behave like a normal OSS project) by default instead of requiring some obscure additional parameter (which almost nobody will then find) to activate it. - Panu -
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
On Tue, Sep 22, 2015 at 11:00:08AM +0200, Olivier MATZ wrote:
> 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.
>
No, build requirements and mechanisms should not be considered part of the API.
There might be other reasons to keep them consistent (and there may be here),
but we don't need to proect the build mechanism, as API is meant to allow
backward compatibility for applications, and the build details are orthogonal to
that.
Neil
> Regards,
> Olivier
>
[dpdk-dev] [PATCH 0/7] Add hierarchical support to make install
DPDK package lacks of a mechanism to install libraries, headers applications and kernel modules to a file system tree. This patch set allows to install files according to the next proposal: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html By adding a parameter H=1 (hierarchy-file) to makefile system, it is possible to do the next steps make config T=TARGET make make install H=1 and files will be installed on the proper directory. Also you can use the DESTDIR variable. Mario Carrillo (7): mk: Add hierarchy-file support mk: Add hierarchy-file support (sbin) mk: Add hierarchy-file support (doc) mk: Add hierarchy-file support (app) mk: Add hierarchy-file support (include) mk: Add hierarchy-file support (lib) mk: Add hierarchy-file support (linux mod) mk/internal/rte.install-post.mk | 15 +++- mk/rte.app.mk | 8 +++ mk/rte.lib.mk | 16 + mk/rte.module.mk| 8 +++ mk/rte.sdkinstall.mk| 52 + 5 files changed, 98 insertions(+), 1 deletion(-) -- 2.1.0
