[dpdk-dev] [PATCH] mk: add makefile extention support

2016-03-03 Thread Wiles, Keith
>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






[dpdk-dev] [PATCH] mk: add makefile extention support

2016-03-03 Thread Thomas Monjalon
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.



[dpdk-dev] [PATCH] mk: add makefile extention support

2016-03-03 Thread 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.

Thanks
++Keith
>>
>
>
>Regards,
>Keith
>
>
>
>
>


Regards,
Keith






[dpdk-dev] [PATCH] mk: add makefile extention support

2016-02-29 Thread 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.
>


Regards,
Keith






[dpdk-dev] [PATCH] mk: add makefile extention support

2016-02-29 Thread Thomas Monjalon
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.


[dpdk-dev] [PATCH] mk: add makefile extention support

2016-02-28 Thread Thomas Monjalon
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.


[dpdk-dev] [PATCH] mk: add makefile extention support

2016-02-28 Thread 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.

>


Regards,
Keith






[dpdk-dev] [PATCH] mk: add makefile extention support

2016-02-09 Thread 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.

Signed-off-by: Keith Wiles 
---
 mk/internal/rte.extvars.mk |  2 +-
 mk/rte.bsdmodule.mk|  6 +++---
 mk/rte.extsubdir.mk|  2 +-
 mk/rte.module.mk   |  6 +++---
 mk/rte.sdkbuild.mk | 10 +-
 mk/rte.sdkconfig.mk|  6 +++---
 mk/rte.sdkdepdirs.mk   | 10 +-
 mk/rte.sdkgcov.mk  |  2 +-
 mk/rte.sdktest.mk  |  2 +-
 mk/rte.subdir.mk   | 14 +++---
 10 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/mk/internal/rte.extvars.mk b/mk/internal/rte.extvars.mk
index 040d39f..3361551 100644
--- a/mk/internal/rte.extvars.mk
+++ b/mk/internal/rte.extvars.mk
@@ -48,7 +48,7 @@ ifeq ("$(origin M)", "command line")
 RTE_EXTMK := $(abspath $(M))
 endif
 endif
-RTE_EXTMK ?= $(RTE_SRCDIR)/Makefile
+RTE_EXTMK ?= $(RTE_SRCDIR)/Makefile$(RTE_MKFILE_SUFFIX)
 export RTE_EXTMK

 # RTE_SDK_BIN must point to .config, include/ and lib/.
diff --git a/mk/rte.bsdmodule.mk b/mk/rte.bsdmodule.mk
index 86b92ff..e8a504a 100644
--- a/mk/rte.bsdmodule.mk
+++ b/mk/rte.bsdmodule.mk
@@ -80,7 +80,7 @@ build: _postbuild

 # build module
 $(MODULE).ko: $(SRCS_LINKS)
-   $(Q)if [ ! -f $(notdir Makefile) ]; then ln -nfs $(SRCDIR)/Makefile . ; 
fi
+   $(Q)if [ ! -f $(notdir Makefile)$(RTE_MKFILE_SUFFIX) ]; then ln -nfs 
$(SRCDIR)/Makefile$(RTE_MKFILE_SUFFIX) . ; fi
$(Q)if [ ! -f $(notdir BSDmakefile) ]; then ln -nfs 
$(SRCDIR)/BSDmakefile . ; fi
$(Q)MAKEFLAGS= $(BSDMAKE)

@@ -100,11 +100,11 @@ clean: _postclean
 # do a make clean and remove links
 .PHONY: doclean
 doclean:
-   $(Q)if [ ! -f $(notdir Makefile) ]; then ln -nfs $(SRCDIR)/Makefile . ; 
fi
+   $(Q)if [ ! -f $(notdir Makefile$(RTE_MKFILE_SUFFIX)) ]; then ln -nfs 
$(SRCDIR)/Makefile$(RTE_MKFILE_SUFFIX) . ; fi
$(Q)$(MAKE) -C $(RTE_KERNELDIR) M=$(CURDIR) O=$(RTE_KERNELDIR) clean
$(Q)$(foreach FILE,$(SRCS-y) $(SRCS-n) $(SRCS-),\
if [ -h $(notdir $(FILE)) ]; then rm -f $(notdir $(FILE)) ; fi 
;)
-   $(Q)if [ -h $(notdir Makefile) ]; then rm -f $(notdir Makefile) ; fi
+   $(Q)if [ -h $(notdir Makefile$(RTE_MKFILE_SUFFIX)) ]; then rm -f 
$(notdir Makefile$(RTE_MKFILE_SUFFIX)) ; fi
$(Q)rm -f $(_BUILD_TARGETS) $(_INSTALL_TARGETS) $(_CLEAN_TARGETS) \
$(INSTALL-FILES-all)

diff --git a/mk/rte.extsubdir.mk b/mk/rte.extsubdir.mk
index f50f006..55d4e16 100644
--- a/mk/rte.extsubdir.mk
+++ b/mk/rte.extsubdir.mk
@@ -45,7 +45,7 @@ clean: $(DIRS-y)
 $(DIRS-y):
@echo "== $@"
$(Q)$(MAKE) -C $(@) \
-   M=$(CURDIR)/$(@)/Makefile \
+   M=$(CURDIR)/$(@)/Makefile$(RTE_MKFILE_SUFFIX) \
O=$(BASE_OUTPUT)/$(CUR_SUBDIR)/$(@)/$(RTE_TARGET) \
BASE_OUTPUT=$(BASE_OUTPUT) \
CUR_SUBDIR=$(CUR_SUBDIR)/$(@) \
diff --git a/mk/rte.module.mk b/mk/rte.module.mk
index 53ed4fe..6477bbe 100644
--- a/mk/rte.module.mk
+++ b/mk/rte.module.mk
@@ -76,7 +76,7 @@ build: _postbuild

 # build module
 $(MODULE).ko: $(SRCS_LINKS)
-   @if [ ! -f $(notdir Makefile) ]; then ln -nfs $(SRCDIR)/Makefile . ; fi
+   @if [ ! -f $(notdir Makefile$(RTE_MKFILE_SUFFIX)) ]; then ln -nfs 
$(SRCDIR)/Makefile$(RTE_MKFILE_SUFFIX) . ; fi
@$(MAKE) -C $(RTE_KERNELDIR) M=$(CURDIR) O=$(RTE_KERNELDIR) \
CC="$(KERNELCC)" CROSS_COMPILE=$(CROSS) V=$(if $V,1,0)

@@ -97,11 +97,11 @@ clean: _postclean
 # do a make clean and remove links
 .PHONY: doclean
 doclean:
-   @if [ ! -f $(notdir Makefile) ]; then ln -nfs $(SRCDIR)/Makefile . ; fi
+   @if [ ! -f $(notdir Makefile$(RTE_MKFILE_SUFFIX)) ]; then ln -nfs 
$(SRCDIR)/Makefile$(RTE_MKFILE_SUFFIX) . ; fi
$(Q)$(MAKE) -C $(RTE_KERNELDIR) M=$(CURDIR) O=$(RTE_KERNELDIR) clean
@$(foreach FILE,$(SRCS-y) $(SRCS-n) $(SRCS-),\
if [ -h $(notdir $(FILE)) ]; then rm -f $(notdir $(FILE)) ; fi 
;)
-   @if [ -h $(notdir Makefile) ]; then rm -f $(notdir Makefile) ; fi
+   @if [ -h $(notdir Makefile$(RTE_MKFILE_SUFFIX)) ]; then rm -f $(notdir 
Makefile$(RTE_MKFILE_SUFFIX)) ; fi
@rm -f $(_BUILD_TARGETS) $(_INSTALL_TARGETS) $(_CLEAN_TARGETS) \
$(INSTALL-FILES-all)

diff --git a/mk/rte.sdkbuild.mk b/mk/rte.sdkbuild.mk
index 85f603c..3860843 100644
--- a/mk/rte.sdkbuild.mk
+++ b/mk/rte.sdkbuild.mk
@@ -76,15 +76,15 @@ clean: $(CLEANDIRS)
 $(ROOTDIRS-y):
@[ -d $(BUILDDIR)/$@ ] || mkdir -p $(BUILDDIR)/$@
@echo "== Build $@"
-   $(Q)$(MAKE) S=$@ -f $(RTE_SRCDIR)/$@/Makefile -C $(BUILDDIR)/$@ all
+