Bug 378

I'm proposing to mark this as INVALID, since Gustavo pointed out to me yesterday that it already does so correctly for ns-3.2.  I'm not sure whether there is a problem; this thread led me to believe that there is a problem for ns-3 released versions:
http://mailman.isi.edu/pipermail/ns-developers/2008-September/004763.html

This started when I tried to do an RC for ns-3.2 and the build system downloaded the development release of nsc using mercurial.  There was a bug in that version of nsc that made the build fail.

Sam wanted to make sure that the build system looked for the released version of nsc and not the development version.

Does our build system always look for an nsc released version, or does it still look in the development tree in somce cases?  That was the real issue, I think.

(In reply to comment #2)
> This started when I tried to do an RC for ns-3.2 and the build system
> downloaded the development release of nsc using mercurial.  There was a bug in
> that version of nsc that made the build fail.
> 
> Sam wanted to make sure that the build system looked for the released version
> of nsc and not the development version.
> 
> Does our build system always look for an nsc released version, or does it still
> look in the development tree in somce cases?  That was the real issue, I think.
> 


Quoting a snippet from what Gustavo sent me:

    if not os.path.exists('.hg'):
        nsc_download ()
    elif not os.path.exists("nsc"):
        nsc_clone()
    else:
        nsc_update()

Basically it uses mercurial for nsc if ns-3 itself is using mercurial, and downloads using the tarball if working from a released ns-3. "


I tested this on ns-3.2 release, on machine ns-regression (which has mercurial installed) and it downloaded the tarball.

I think the other issue of whether ns-3-dev works from a development version of nsc is outside of the scope of the ns-3.2.1 release, and is part of the overall build system discussion.

OK, I think the build system is fine as-is for the current release. However, I'd like the next release to depend on the current version of NSC - this hasn't changed for a couple of weeks now and will be the version that is used by most right now.

I'm releasing nsc-0.4.1 now; this fixes some 32-bit/64-bit issues and is generally better tested than the previous version.

I'd like to make ns-3 depend on nsc tarballs by default, but I accept that that is probably an issue for the build system rework, not the interim ns-3 release.