Bug 1602 - waf build can break due to file collisions in higher-level directory
waf build can break due to file collisions in higher-level directory
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: build system
ns-3.16
All All
: P5 normal
Assigned To: Gustavo J. A. M. Carneiro
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-17 11:01 UTC by Tom Henderson
Modified: 2013-03-18 02:06 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Henderson 2013-03-17 11:01:08 UTC
Felipe Perrone discovered this, reported it to waf developers, who bounced it back to us:

http://code.google.com/p/waf/issues/detail?id=1269

It has caused subtle failures for a few users.
Comment 1 Gustavo J. A. M. Carneiro 2013-03-17 11:16:44 UTC
Note, for me this only happens if the file named `list' appears in the directory immediately above ns-3-dev, not if it is any place else.

What I see is:

[633/707] cxx: utils/test-runner.cc -> build/utils/test-runner.cc.1.o
15:10:07 runner ['/usr/bin/g++', '-O0', '-ggdb', '-g3', '-Wall', '-Werror', '-Wno-error=deprecated-declarations', '-fstrict-aliasing', '-Wstrict-aliasing', '-pthread', '-Ibuild', '-I.', '-I.', '-I/home/gjc/projects/ns3/ns-3-allinone', '-DNS3_ASSERT_ENABLE', '-DNS3_LOG_ENABLE', '-DHAVE_PACKET_H=1', '-DHAVE_IF_TUN_H=1', '../utils/test-runner.cc', '-c', '-o', 'utils/test-runner.cc.1.o']
In file included from ./ns3/test.h:27:0,
                 from ../utils/test-runner.cc:19:
/home/gjc/projects/ns3/ns-3-allinone/list:1:1: error: ‘asdfhasjdhfsj’ does not name a type
In file included from ../utils/test-runner.cc:19:0:
./ns3/test.h:823:48: error: ‘numeric_limits’ is not a member of ‘std’
./ns3/test.h:823:68: error: expected primary-expression before ‘double’
./ns3/test.h:823:68: error: expected ‘,’ or ‘...’ before ‘double’

It is quite obvious that this would happen due to the '-I/home/gjc/projects/ns3/ns-3-allinone' option.  It has nothing to do with waf, and is due to the gcc include path.  So Thomas Nagy is right, it is not a waf bug.

A quick glance at the wscript and this appears to be the culprit:

def create_ns3_program(bld, name, dependencies=('core',)):
    [...]
    program.includes = "# #/.."

Here, the character '#' represents the project root dir, so #/.. is the directory above.
Comment 2 Tom Henderson 2013-03-18 02:06:39 UTC
fixed in 13b3ddbaac67; hopefully no side effects will pop up.  Thanks Gustavo!