BakeIntegration - Revision history

Pdbarnes: add link to spack

2017-02-23T19:09:33Z

add link to spack

← Older revision		Revision as of 19:09, 23 February 2017
Line 214:		Line 214:
	How this relates to binary package distribution/preparation is TBD.		How this relates to binary package distribution/preparation is TBD.

	Whether we try to replace bake with something like [https://nixos.org/nixpkgs/manual/ nixpkgs] is TBD.		Whether we try to replace bake with something like [https://nixos.org/nixpkgs/manual/ nixpkgs] or [https://spack.readthedocs.io/en/latest/ spack] TBD.

Tomh: /* Executive summary */

2017-01-23T05:45:42Z

Executive summary

@@ Line 27: / Line 27: @@
 #* Routes Mobility Model
 #* (others TBD)
 = How bake is used now =

Tomh: /* Example */

2017-01-23T05:40:00Z

Example

← Older revision		Revision as of 05:40, 23 January 2017
Line 172:		Line 172:
	The next steps would be to actually configure the contributed modules to 'enabled' status, so that they are downloaded to the src/contrib directory when ./bake.py download is called.		The next steps would be to actually configure the contributed modules to 'enabled' status, so that they are downloaded to the src/contrib directory when ./bake.py download is called.

	We aim to support an API like this, ~~repurposing~~ the '-a' option to configure to support the adding of contributed modules. In general, we aim to not require (but still allow) users to specify the contributed module version, as follows:		We aim to support an API like this, using the '-e' option to configure to support the adding of contributed modules. In general, we aim to not require (but still allow) users to specify the contributed module version, as follows:

	./bake.py show /* should ~~show~~ an empty config */		./bake.py configure -c
			./bake.py show /* should result in an empty config */

	./bake.py configure -a routes-mobility-model		./bake.py configure -a routes-mobility-model
	Error: ~~no ns3 module configured~~		> Error: Module "routes-mobility-model" has unmet dependency: ns-3.27

	./bake.py configure -e ns-3.25 /* Now I have a base of ns-3.25 module, and I can add to it */		./bake.py configure -e ns-3.27 /* Now I have a base of ns-3.27 module, and I can add to it */

	./bake.py configure -a pybindgen /* add python bindings support */		./bake.py configure -e pybindgen /* add python bindings support */

	./bake.py configure -a routes-mobility-model /* add routes-mobility-model to build */		./bake.py configure -e routes-mobility-model /* add routes-mobility-model to build */
	~~./bake.py configure -a routes-mobility-model-1.0 /equivalent to the above~~ /

	./bake.py configure -~~a routes-mobility-model-1.1~~		./bake.py configure -e epidemic-prime
	~~Error: routes-mobility-model-1.1 not found for ns-3.25~~		Error: epidemic-prime not found for ns-3.27

	~~./bake.py configure -a~~ epidemic-prime
	Error: epidemic-prime not found for ns-3.25

	./bake.py configure -d routes-mobility-model /* remove routes-mobility-model from configuration */		./bake.py configure -d routes-mobility-model /* remove routes-mobility-model from configuration */
	~~./bake.py configure -a routes-mobility-model epidemic-routing /* add back routes-mobility-model, and also add epidemic */~~

	./bake.py show /* should show now that ns-3.~~25,~~ pybindgen~~, routes-mobility-model, and epidemic-routing~~ configured */		./bake.py show /* should show now that ns-3.27 and pybindgen are configured */

	~~The above set~~ of ~~commands should~~ be ~~equivalent also to the following simpler command~~:		Enabling of modules can also be done on a single statement:

	./bake.py configure -e ns-3.25 -a pybindgen routes-mobility-model epidemic-routing		./bake.py configure -e ns-3.25 -e pybindgen -e routes-mobility-model -e epidemic-routing

	= Open issues =		= Open issues =

Tomh: /* Executive summary */

2017-01-23T05:36:10Z

Executive summary

← Older revision		Revision as of 05:36, 23 January 2017
Line 15:		Line 15:
	#. ns-3 will add a 'contrib/' directory in parallel with 'src/'; contrib/ will be the landing spot for contributed modules		#. ns-3 will add a 'contrib/' directory in parallel with 'src/'; contrib/ will be the landing spot for contributed modules
	#* Patch pending in https://www.nsnam.org/bugzilla/show_bug.cgi?id=2630		#* Patch pending in https://www.nsnam.org/bugzilla/show_bug.cgi?id=2630
	#. contributed modules will be organized ~~as new modules~~ hosted somewhere on the web (tar archives, github, bitbucket, etc.)		#. contributed modules will be organized according to the standard module layout and hosted somewhere on the web (tar archives, github, bitbucket, etc.)
	#. a small bake XML configuration file will tell bake how to download the new module into contrib/, and will be available to express any other library dependencies. These XML files will be stored in 'bake/contrib' directory.		#. a small bake XML configuration file will tell bake how to download the new module into contrib/, and will be available to express any other library dependencies of the module. These XML files will be stored in 'bake/contrib' directory.
	#* Patch pending in https://www.nsnam.org/bugzilla/show_bug.cgi?id=2631		#* Patch pending in https://www.nsnam.org/bugzilla/show_bug.cgi?id=2631
	#. users will tailor their ~~contrib~~ module downloads using the bake tool; users will continue to tailor their ns-3 build using Waf		#. users will tailor their contributed module downloads using the bake tool; users will continue to tailor their ns-3 build using Waf
	#. modules will become more stand-alone, with ability to run Sphinx documentation and Doxygen on them independently.		#. modules will become more stand-alone, with ability to run Sphinx documentation and Doxygen on them independently.
	#* create-module.py program can migrate from src/ to contrib/ directory and extended to generate initial bake module XML		#* create-module.py program can migrate from src/ to contrib/ directory and extended to generate initial bake module XML

Tomh: /* Executive summary */

2017-01-23T05:34:33Z

Executive summary

← Older revision		Revision as of 05:34, 23 January 2017
Line 21:		Line 21:
	#. modules will become more stand-alone, with ability to run Sphinx documentation and Doxygen on them independently.		#. modules will become more stand-alone, with ability to run Sphinx documentation and Doxygen on them independently.
	#* create-module.py program can migrate from src/ to contrib/ directory and extended to generate initial bake module XML		#* create-module.py program can migrate from src/ to contrib/ directory and extended to generate initial bake module XML
	#. we will start with a small set of such modules for ns-3.27 initial release and add them throughout the year		#. we will start with a small set of such modules for ns-3.27 initial release and add them throughout the year. Tentative modules for ns-3.27:
			#* Magister's Satellite Network Simulator 3 (SNS3)
			#* UAN integration with World Ocean Simulation System (WOSS)
			#* SiFT routing
			#* Routes Mobility Model
			#* (others TBD)

	= How bake is used now =		= How bake is used now =

Tomh: /* Proposed changes for ns-3.26 */

2017-01-23T03:11:10Z

Proposed changes for ns-3.26

Show changes

Tomh: /* Executive summary */

2017-01-23T03:01:49Z

Executive summary

← Older revision		Revision as of 03:01, 23 January 2017
Line 14:		Line 14:

	#. ns-3 will add a 'contrib/' directory in parallel with 'src/'; contrib/ will be the landing spot for contributed modules		#. ns-3 will add a 'contrib/' directory in parallel with 'src/'; contrib/ will be the landing spot for contributed modules
			#* Patch pending in https://www.nsnam.org/bugzilla/show_bug.cgi?id=2630
	#. contributed modules will be organized as new modules hosted somewhere on the web (tar archives, github, bitbucket, etc.)		#. contributed modules will be organized as new modules hosted somewhere on the web (tar archives, github, bitbucket, etc.)
	#. a small bake XML configuration file will tell bake how to download the new module into contrib/, and will be available to express any other library dependencies. These XML files will be stored in 'bake/contrib' directory.		#. a small bake XML configuration file will tell bake how to download the new module into contrib/, and will be available to express any other library dependencies. These XML files will be stored in 'bake/contrib' directory.
			#* Patch pending in https://www.nsnam.org/bugzilla/show_bug.cgi?id=2631
	#. users will tailor their contrib module downloads using the bake tool; users will continue to tailor their ns-3 build using Waf		#. users will tailor their contrib module downloads using the bake tool; users will continue to tailor their ns-3 build using Waf
	#. modules will become more stand-alone, with ability to run Sphinx documentation and Doxygen on them independently.		#. modules will become more stand-alone, with ability to run Sphinx documentation and Doxygen on them independently.
	#. we will start with a small set of such modules for ns-3.27 and ~~aggressively~~ add them ~~during~~ the year		#* create-module.py program can migrate from src/ to contrib/ directory and extended to generate initial bake module XML
			#. we will start with a small set of such modules for ns-3.27 initial release and add them throughout the year

	= How bake is used now =		= How bake is used now =

Tomh: bake updates

2017-01-19T15:50:31Z

bake updates

← Older revision		Revision as of 15:50, 19 January 2017
Line 10:		Line 10:

	For the ns-3.27 release, we want to take the step towards making a number of contributed ns-3 modules readily available. We do not have time in this release cycle to create the perfect tool or transition away from bake to another build orchestration tool for ns-3.27, so we will prioritize getting something reasonably usable in place for ns-3.27, with as many modules enabled as we have time to do, and study later whether we want to make a bigger change such as moving to an externally supported build orchestration tool such as nixpkgs, or work on binary package management.		For the ns-3.27 release, we want to take the step towards making a number of contributed ns-3 modules readily available. We do not have time in this release cycle to create the perfect tool or transition away from bake to another build orchestration tool for ns-3.27, so we will prioritize getting something reasonably usable in place for ns-3.27, with as many modules enabled as we have time to do, and study later whether we want to make a bigger change such as moving to an externally supported build orchestration tool such as nixpkgs, or work on binary package management.

			= Executive summary =

			#. ns-3 will add a 'contrib/' directory in parallel with 'src/'; contrib/ will be the landing spot for contributed modules
			#. contributed modules will be organized as new modules hosted somewhere on the web (tar archives, github, bitbucket, etc.)
			#. a small bake XML configuration file will tell bake how to download the new module into contrib/, and will be available to express any other library dependencies. These XML files will be stored in 'bake/contrib' directory.
			#. users will tailor their contrib module downloads using the bake tool; users will continue to tailor their ns-3 build using Waf
			#. modules will become more stand-alone, with ability to run Sphinx documentation and Doxygen on them independently.
			#. we will start with a small set of such modules for ns-3.27 and aggressively add them during the year

	= How bake is used now =		= How bake is used now =

Tomh: /* Background and Motivation */

2017-01-19T15:42:04Z

Background and Motivation

← Older revision		Revision as of 15:42, 19 January 2017
Line 5:		Line 5:
	= Background and Motivation =		= Background and Motivation =

	Presently, ns-3 has a large backlog of contributed code, and the build of ns-3 can take very long, including modules that are not of interest to most users. We therefore want to move the project towards a more modular arrangement of 'core' modules and 'contributed' modules, and a more user-friendly way of tailoring the build of ns-3 to a specific user's needs. We need a build orchestration tool to facilitate this.		Presently, ns-3 has a large backlog of unmerged contributed code, and the build of ns-3 can take very long, including modules that are not of interest to most users. We therefore want to move the project towards a more modular arrangement of 'core' modules and 'contributed' modules, and a more user-friendly way of tailoring the build of ns-3 to a specific user's needs. We need a build orchestration tool to facilitate this.

	bake.py is a tool developed at INRIA to orchestrate the Direct Code Execution (DCE) build. It was developed with some goals of generality (e.g. ns-3-specific constructs were avoided), but in practice is only being used these days to build DCE. bake.py is a build orchestration tool, in that it is not a build tool like 'make' or 'Waf', but instead calls to those build tools to orchestrate a build of several libraries in a correct order. bake.py was developed because the available build orchestration tools examined at ~~that~~ time were ~~deemed~~ to be insufficient to meet the requirements.		bake.py is a tool developed at INRIA to orchestrate the Direct Code Execution (DCE) build. It was developed with some goals of generality (e.g. ns-3-specific constructs were avoided), but in practice is only being used these days to build DCE and some optional components of the ns-3-allinone build. bake.py is a build orchestration tool, in that it is not a build tool like 'make' or 'Waf', but instead calls to those build tools to orchestrate a build of several libraries in a correct order. bake.py was developed because the available build orchestration tools examined at the time of development were considered to be insufficient to meet the requirements.

	For the ns-3.26 release, we want to take the step towards making a number of contributed ns-3 modules readily available. We do not have time in this release cycle to create the perfect tool or transition away from bake to another build orchestration tool for ns-3.26, so we will prioritize getting something reasonably usable in place for ns-3.26, with as many modules enabled as we have time to do, and study later whether we want to make a bigger change such as moving to an externally supported build orchestration tool such as nixpkgs.		For the ns-3.27 release, we want to take the step towards making a number of contributed ns-3 modules readily available. We do not have time in this release cycle to create the perfect tool or transition away from bake to another build orchestration tool for ns-3.27, so we will prioritize getting something reasonably usable in place for ns-3.27, with as many modules enabled as we have time to do, and study later whether we want to make a bigger change such as moving to an externally supported build orchestration tool such as nixpkgs, or work on binary package management.

	= How bake is used now =		= How bake is used now =

Tomh: update bake goals for ns-3.26

2016-04-21T19:24:24Z

update bake goals for ns-3.26

Show changes