[Ns-developers] ns-3 modular build
gjcarneiro at gmail.com
Thu Oct 28 02:56:49 PDT 2010
On Thu, Oct 28, 2010 at 09:00, Mathieu Lacage <mathieu.lacage at inria.fr>wrote:
> On Thu, 2010-10-28 at 09:07 +0400, Pavel Boyko wrote:
> > I am not sure that this is a good idea. Requiring uniform build system
> > all NS-3 modules is not strange, after all you do require uniform coding
> > style, etc. Actually this infrastructure uniformity can distinguish NS-3
> > module from "just a library". This can simplify things essentially both
> > developers (I don't need to invent a build system for my module, just
> > paste the example) and users (I don't need to have all those exotic build
> > tools installed and don't need to understand their output when something
> > wrong).
> I think that there are two important things to keep in mind:
> - I believe (and I know that a certain number of serious ns-3
> users/developers I talked to feel the same) that using waf was a mistake
> and that we should aim long term for another tool, especially since
> gustavo will not be around forever to debug our biggest waf problems for
> us. I don't know what gustavo thinks about this nowadays but he was
> pretty sympathetic to this kind of statement when I last discussed this
> with him.
I do not regret moving to waf. It is at least better than the scons ns-3
was using at the time, which was very slow, with an additional python layer
on top that was too inflexible to customization.
Do I find waf painful? Yes. But is there a better alternative? I have
often thought about writing some new build tool from scratch, but time does
not allow it. Writing a new _complete_ build system is a very hard task. I
already wrote a python extension code generator from scratch, that was
Regarding jhbuild, it still relies on a build system underneath, so it is
not a complete build system.
> - we already depend on a number of external modules which use
> different build tools: it would be nice to integrate these modules
> within the ns-3 build process. (tom mentioned nsc but there are others,
> especially with the dce stuff)
Well, the download.py script in ns-3-allinone is a step in that direction.
NSC used to be built inside ns-3, but we abandoned that step for whatever
reason. Now it's build.py that does it.
> > > waf may be too painful to orchestrate everything; a dedicated python
> > may be better in the long run
> > I thought waf was "the dedicated python program" :))) You are going to
> > invent waf 2.
> The model I have in mind is something close to jhbuild (the gtk/gnome
> build script). In previous lives, I have witnessed people re-inventing
> the same functionality twice in two different projects and I know how
> useful these scripts are especially when you start trying to integrate
> multiple modules/packages together.
> Yes, there is a price to be paid here: giving up on using the same build
> tool for every module means we are going to lose some features but I
> believe that the gain in terms of modularity will more than offset this
> loss. i.e., right now, the monolithic build is killing us.
Maybe. I still think some default build system (waf) is needed for core
modules. And then I'm not sure what this build system will need to do to
allow this. Surely you don't mean that waf runs system("cd src/othermodule
&& make"), because then the build system becomes monolithic again...
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert
More information about the Ns-developers