DPDK patches and discussions
 help / color / mirror / Atom feed
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: Sun, 28 Feb 2016 21:47:23 +0000	[thread overview]
Message-ID: <F4EF8442-81AD-40D7-B6DA-DFC9D27F07DB@intel.com> (raw)
In-Reply-To: <1976319.EWLy02CyDg@xps13>

>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.

>


Regards,
Keith





  reply	other threads:[~2016-02-28 21:47 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 [this message]
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

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=F4EF8442-81AD-40D7-B6DA-DFC9D27F07DB@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).