[Ns-developers] build system proposal

[Mathieu Lacage]

On Tue, 2008-10-07 at 12:05 +0100, Gustavo Carneiro wrote:
> 2008/10/7 Gustavo Carneiro <gjcarneiro at gmail.com>
> 
> >
> >
> > 2008/10/7 Tom Henderson <tomh at tomh.org>
> >
> > Mathieu Lacage wrote:
> >>
> >>> comments below,
> >>>
> >>> On Tue, 2008-09-30 at 16:36 +0000, Tom Henderson wrote:
> >>>
> >>>  ns-3-allinone/
> >>>>             download.py
> >>>>             install.py
> >>>>
> >>>> After invoking download.py, it would look something like this:
> >>>>
> >>>> ns-3-allinone/
> >>>>             ns-3-dev/
> >>>>             pybindgen-dev/
> >>>>             nsc-dev/
> >>>>             ns-3-dev-ref-traces/
> >>>>             download.py
> >>>>             install.py
> >>>>
> >>>> At any time when invoked later, download.py will synchronize all
> >>>> repos, or if passed an argument or set of arguments, will synchronize
> >>>> all of
> >>>> the named repos only.  Note:  Craig has suggested that maybe a separate
> >>>> script called "sync.py" or something like that could be used to do the
> >>>> later synchronization, and not reuse "download.py".
> >>>>
> >>>
> >>>
> >>> I would support instead making download.py require a mandatory argument.
> >>>
> >>> ./download.py --> do nothing, print help output.
> >>> ./download.py all --> download everything
> >>> ./download.py nsc --> download nsc
> >>> ./download.py nsc ns-3 --> download nsc and ns-3.
> >>>
> >>>  To update ns-3-dev, a developer in the ns-3-dev directory may either:
> >>>> i) hg pull (as usual)
> >>>> ii) ../sync.py ns-3-dev  (same outcome as i)
> >>>> iii) ../sync.py in which case everything is synchronized
> >>>>
> >>>
> >>> I would suggest again "../sync.py all" to avoid spurious unwanted
> >>> updates.
> >>>
> >>> Mathieu
> >>>
> >>>
> >> Any other comments on this proposal?  If not, we'll take steps to
> >> implement it with Mathieu's additional suggestion.
> >
> >
> > Just one comment.  I really _really_ think you should rename install.py to
> > build.py.  "Installation" usually means something completely different than
> > what you want this script to do.  I don't care if NS 2 has an install
> > script, if NS 3 is not to be system installed then we shouldn't call the
> > script install.
> >
> > Otherwise it sounds fine in principle.  Well, just a couple more of
> > details: 1. I would make the allinone dist a python/shell script instead of
> > waf wscript (otherwise waf might get confused, god knows it's not hard, by
> > the nested waf project), 2. I'm not sure how easy it will be to figure out
> > the version of each external component to rename the folders for the
> > allinone dist.
> >
> 
> OK, I have one more comment.  Right now, when I make pybindgen support
> something new I can rescan the header files and commit the ns3_module_*.py
> API definition files.  Since a newer pybindgen is required to "understand"
> the new features being requested, I also change the requested pybindgen
> version.  This means that a unknowing developer will try to build ns-3-dev
> and then waf will automatically reconfigure the project, notice the too old
> pybindgen, and try to update pybindgen.  If the new allinone build system
> does not take care of this problem then I'm afraid we will see occasional
> build problems where people blame pybindgen and I have to tell them to
> update pybindgen.

The current proposal should deal with this problem by delegating the
version checking to the 'install' script. i.e., the waf script in
ns-3-dev should check that the current environment has the correct
version of all programs by running ../install check. (use a different
name for the script if you wish).

Mathieu