06/06/2017 11:05, Jerin Jacob: > From: Jerin Jacob <jerin.ja...@caviumnetworks.com> > > From: Thomas Monjalon <tho...@monjalon.net> > > > 06/06/2017 09:02, Jerin Jacob: > > > > From: Thomas Monjalon <tho...@monjalon.net> > > > > > Please explain how it can help with a real example. > > > > > > > > We are evaluating on running DPDK on a nonstandard execution > > > > environment like > > > > bare metal where I would to keep all my execution environment specific > > > > change at following location. So that I can easy move around different > > > > version of DPDK without merge conflict. > > > > > > > > $(RTE_SDK)mk/exec-env/my-exec-env > > > > $(RTE_SDK)lib/librte_eal/my-exec-env > > > > > > > > I believe, The existing target like "exec-env-appinstall" in > > > > mk/exec-env/linuxapp/rte.app.mk, > > > > solves the same purpose. > > > > > > I do not understand. > > > If you want to add a new environment, why not just adding it? > > > > I do not understand it either. In exiting makefile infrastructure, > > How do you add an exec environment specific target(s) with out changing > > the common code? > > As disucssed in IRC, I will send the v2 with following changes, > - Change mk/exec-env/$(RTE_EXEC_ENV)/rte.extra.mk to > mk/exec-env/$(RTE_EXEC_ENV)/rte.custom.mk > - Remove empty files and include through -include
It will help defining some new local environments. However, in the general case, it is better to upstream environment changes and make everybody able to use it.