Note that Python modules are never built because Python is an interpreted language.  

If it actually possible for waf to do this, you would want something like this:

     applications (PB)

to denote Python Bindings (PB) as what was built.

Why would the user need to know that Python bindings are built or not for a module?

I think that this information in the waf output just makes it more confusing to the users and requires more documentation plus changes to the existing documentation.

(In reply to comment #1)
> Note that Python modules are never built because Python is an interpreted
> language.  
> 
> If it actually possible for waf to do this, you would want something like this:
> 
>      applications (PB)
> 
> to denote Python Bindings (PB) as what was built.
> 
> Why would the user need to know that Python bindings are built or not for a
> module?
> 
> I think that this information in the waf output just makes it more confusing to
> the users and requires more documentation plus changes to the existing
> documentation.

So I am recommending that we leave the waf output as it is.

Here are steps to reproduce this:

Create an .ns3rc in ns-3-dev as follows:

#! /usr/bin/env python

# A list of the modules that will be enabled when ns-3 is run.
# Modules that depend on the listed modules will be enabled also.
#
# All modules can be enabled by choosing 'all_modules'.
modules_enabled = ['core','network','applications','internet','config-store','tools','stats','bridge','point-to-point']

# Set this equal to true if you want examples to be run.
examples_enabled = True

# Set this equal to true if you want tests to be run.
tests_enabled = True

-----

then after the build, waf announces:

Modules built:
applications              bridge                    config-store             
core                      internet                  mpi                      
network                   point-to-point            stats                    
tools                    

Modules not built:
click                     openflow              

The following will be found in build/bindings/python/ns:

applications.so
bridge.so
config_store.so
_core.so
internet.so
network.so
point_to_point.so
stats.so
tools.so

but there is an additional library built for C++:


libns3-dev-applications-debug.so
libns3-dev-bridge-debug.so
libns3-dev-config-store-debug.so
libns3-dev-core-debug.so
libns3-dev-internet-debug.so
libns3-dev-mpi-debug.so
libns3-dev-network-debug.so
libns3-dev-point-to-point-debug.so
libns3-dev-stats-debug.so
libns3-dev-tools-debug.so

i.e. the mpi C++ library was built automatically because of a dependency, but not the python equivalent.  I think this is what the user complaint was about (I can't find the original complaint about this).

I think it kind of makes sense to denote when Py(In reply to comment #1)
> Note that Python modules are never built because Python is an interpreted
> language.  
> 
> If it actually possible for waf to do this, you would want something like this:
> 
>      applications (PB)
> 
> to denote Python Bindings (PB) as what was built.

I would favor the reverse: when Python bindings are available, print just the module name, else note that python bindings are missing. E.g.:
    core
    network
    applications
    mpi (no python bindings)


> Why would the user need to know that Python bindings are built or not for a
> module?

Before a user committing to writing a simulation in Python instead of C++, he needs to know that Python bindings are available.

> 
> I think that this information in the waf output just makes it more confusing to
> the users and requires more documentation plus changes to the existing
> documentation.

If the change is like I propose above, it is self-explanatory, I think.

Created attachment 1388 [details]
patch

this patch adds (no python) at the end of each module if it has no python bindings yet.

Bug closed.

ns-3-dev changeset:  5a610391f3f1s