[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