[Ns-developers] build system proposal

[Gustavo Carneiro]

2008/10/7 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>

> 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).


Why are you planning to remove the nice user friendly configuration tests in
waf and instead make waf invoke an external command to check those things?
Besides reinventing the wheel, then we need to create a protocol between
../install.py and the waf script, so that the waf build system disables
components with missing dependencies.

I thought this 'allinone' directory was an extra layer on top of ns-3-dev?
If you start crippling the waf configuration detection then ns-3-dev will
essentially become interlocked with ns-3-allinone, which is something I
think is a very bad idea.

IMHO all external dependencies detection should still be present inside
ns-3-dev, for those that do not want to use 'allinone'.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert