[Ns-developers] build system proposal

[Gustavo Carneiro]

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.

One way to cope with this problem is to keep the pybdingen detection in the
ns-3-dev wscript, except that it will just disable python if pybindgen is
too old and not try to download anything.  Also the download.py script would
have to peek into ns-3-dev/bindings/python/wscript and grab the value of
REQUIRED_PYBINDGEN_VERSION, since it is a bad idea to have "constants"
defined in two different places at the same time.

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