From: "Wiles, Keith" <keith.wiles@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] mk: add makefile extention support
Date: Thu, 3 Mar 2016 17:53:33 +0000 [thread overview]
Message-ID: <DCC4DA7B-8B54-482E-882A-6F9CD9C465D3@intel.com> (raw)
In-Reply-To: <1963758.vYVLsiL7TI@xps13>
>2016-03-03 14:55, Wiles, Keith:
>> >>2016-02-28 21:47, Wiles, Keith:
>> >>> >Hi,
>> >>> >
>> >>> >2016-02-09 11:35, Keith Wiles:
>> >>> >> Adding support to the build system to allow for Makefile.XXX
>> >>> >> extention to a subtree, which already has Makefiles. These
>> >>> >> Makefiles could be from the autotools and others places. Using
>> >>> >> the Makefile extention RTE_MKFILE_SUFFIX in a makefile subtree
>> >>> >> using 'export RTE_MKFILE_SUFFIX=.XXX' to use Makefile.XXX in
>> >>> >> that subtree.
>> >>> >>
>> >>> >> The main reason I needed this feature was to integrate a autotool
>> >>> >> open source projects with DPDK and keep the original Makefiles.
>> >>> >
>> >>> >Sorry I fail to understand why it is needed.
>> >>> >Are you trying to add autotool in DPDK? I don't think it is a good approach.
>> >>> >The DPDK must provide a pkgconfig interface to be integrated anywhere.
>> >>>
>> >>> I was not trying to add autotools to DPDK. On a number of times I wanted to integrate a open source project(s) with DPDK and use DPDK’s build system, but because the open source project already contained Makefile files you can not use DPDK build system without modify or moving the original Makefile files. Using this method I can just add a exported variable and supply my own Makefile.XXX files.
>> >>>
>> >>> One case was building FreeBSD source, but I did not want to modify FreeBSD Makefiles (or reply on previous built Makefiles as they would not work on Linux anyway) as I was pulling the source down from freebsd.org repo. Using a patch to add the Makefiles with a different suffix allows me to build FreeBSD using DPDK, without having to modify or own the FreeBSD source. I have had this problem a number of times with open source code I did not want to modify, but just build within DPDK build system and adding the support for a different suffix to DPDK provided a clean way. The change does not effect the correct build system and just allows someone to define a new suffix for a given subtree in the code.
>> >>
>> >>Why would you like to have another project inside the DPDK files tree?
>> >>If you want to integrate the lib inside an existing project, the solution
>> >>is pkgconfig.
>> >
>> >The goal for me was to use DPDK build system for that project, instead of using autotools or some other makefile system. In the case of FreeBSD code, the FreeBSD build system requires FreeBSD tools to be built as the ‘make’ and the Makefiles are very different on a Linux machine.
>>
>> Does anyone find this patch useful, I would hate to see this one die as it does not effect the current builds, but adds support for using DPDK build system without having to modify or move the existing Makefiles.
>
>I would hate making the build system even more complicated to use it
>for something which is not its role.
>It opens the door to feature requests which are clearly out of its scope.
Ok, Thanks I will change the status in patchwork to rejected.
>
>
Regards,
Keith
prev parent reply other threads:[~2016-03-03 17:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-09 17:35 Keith Wiles
2016-02-24 15:22 ` Wiles, Keith
2016-02-28 21:00 ` Thomas Monjalon
2016-02-28 21:47 ` Wiles, Keith
2016-02-29 8:21 ` Thomas Monjalon
2016-02-29 14:12 ` Wiles, Keith
2016-03-03 14:55 ` Wiles, Keith
2016-03-03 16:33 ` Thomas Monjalon
2016-03-03 17:53 ` Wiles, Keith [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DCC4DA7B-8B54-482E-882A-6F9CD9C465D3@intel.com \
--to=keith.wiles@intel.com \
--cc=dev@dpdk.org \
--cc=thomas.monjalon@6wind.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).