[Ns-developers] build system proposal

Tom Henderson tomh at tomh.org
Tue Oct 7 07:16:07 PDT 2008


Gustavo Carneiro wrote:

> 
>      > 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.
> 
>     Yes, but, it's called a 'compromise' to get something simple working for
>     a vast majority of people given the set of requirements tom set forth
>     (no network access during ./waf, etc.).
> 
> 
> OK, Tom has his requirements, but can I propose an additional 
> requirement?  I would like ns-3-dev to keep detecting optional 
> components and be fully functional as before, aside from the downloading 
> from the network part.  My proposal is that:
> 
>   1. ns-3-dev is able to build itself without outside scripts and detect 
> all the components that it needs, also without outside help;
>   2. ns-3-dev no longer downloads anything from the network, 
> ns-3-allinon will take care of it;
>   3. ns-3-allinon can download components from the network, and also can 
> coordinate build of optional components plus ns-3-dev itself.
> 
> I don't remember exactly Tom's requirements, but I suspect they will be 
> preserved in this strategy?

Gustavo,
I'm fine with your suggestion; it doesn't conflict with my goals.  I 
think that it means that version mismatch would just be detected when 
ns-3-dev was built.

Here is a summary of what I am after:
1) released version is self contained and requires no further downloads, 
and there is an allinone build script that will build pieces in the 
right order.
   -- note that this goes against a previous goal of mine to keep 
regression traces outside of the downloaded release tarball, since in 
ns-2, the size of these compressed traces dwarfs the code itself. 
However, we are talking now about a 2MB vs 1MB download, so at this 
point in ns-3 development, it seems better to me to just make things as 
easy as possible for newcomers.

2) development version also works in offline mode; in this case, if 
there are pieces that are not synchronized or stale (bindings, traces, 
nsc), waf will successfully build the core of ns-3 and will disable 
support for the incompatible feature, or will preserve it and just 
generate a warning that things are out of sync.
   -- in particular, regression should continue to run even if the 
traces are detected as stale; it would just print out a warning to try 
to sync at the next opportunity

3) nothing is downloaded or sync'ed automatically as part of the ns-3 
build process

4) user knows whether he or she is working from a development version or 
a released version, and if a released version, know which version, by 
inspection of the directory and directory names

- Tom


More information about the Ns-developers mailing list