scons error: Multiple ways to build the same target were specified

[WasabiFan]

I'm trying to follow the installation and getting started guides. I have a folder in which I've pasted the example project.xml and main.cpp from the getting started guide, and have also cloned the modm repo under modm-lib/. When I run scons, I get the following:

$ scons
scons: Reading SConscript files ...

scons: *** Multiple ways to build the same target were specified for: build/modm-multiple-ways-same-target-repro/release/modm-lib/ext/arm/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_bitreversal2.o  (from ['modm-lib/ext/arm/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_bitreversal2.S'] and from ['modm-lib/ext/arm/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_bitreversal2.c'])
File "/tmp/modm-multiple-ways-same-target-repro/modm/scons/site_tools/build_target.py", line 16, in build_target

I pushed my simple demo repo here, and have included a transcript demonstrating the issue below.

kaelin@LAPTOP-2617BE5S:/tmp$ git clone --recursive https://github.com/WasabiFan/modm-multiple-ways-same-target-repro.git                                                                                                 Cloning into 'modm-multiple-ways-same-target-repro'...
<cut for brevity...>
Submodule path 'modm-lib/ext/adamgreen/crashcatcher': checked out 'e7f48c080b2efb49d21aed63f706fe08c0426796'
Submodule path 'modm-lib/ext/arm/cmsis': checked out '22d8ddb7cf63b5a5ced301c6dd56ed83eb910001'
Submodule path 'modm-lib/ext/aws/freertos': checked out 'ac05c153fffce3f074a8cd54724fc3dc1d75b69f'
Submodule path 'modm-lib/ext/dlr/scons-build-tools': checked out '8277a9e170e79849903580ce6cd609bd26e7117e'
Submodule path 'modm-lib/ext/gcc/libstdc++': checked out '2030cc27f3238419f792ac4558877f9bf571af2a'
Submodule path 'modm-lib/ext/modm-devices': checked out '77400584010d8fccfc9107cb420a48a3f22ec2e0'
Submodule path 'modm-lib/ext/mpaland/printf': checked out '77e68ca71b360c489adb26dc4af0c852c70da0d8'
Submodule path 'modm-lib/ext/ros/ros-lib': checked out '486aed53bd2098a8aadb89996dfa8f0a52fd81fb'
Submodule path 'modm-lib/ext/st/stm32': checked out '5cc80e98634858221951dd9440234fab5c78da63'
kaelin@LAPTOP-2617BE5S:/tmp$
kaelin@LAPTOP-2617BE5S:/tmp$ cd modm-multiple-ways-same-target-repro/
kaelin@LAPTOP-2617BE5S:/tmp/modm-multiple-ways-same-target-repro$ ls
main.cpp  modm-lib  project.xml
kaelin@LAPTOP-2617BE5S:/tmp/modm-multiple-ways-same-target-repro$ lbuild build                                                                                                                                           >> modm: Recomputing device cache...

kaelin@LAPTOP-2617BE5S:/tmp/modm-multiple-ways-same-target-repro$ scons
scons: Reading SConscript files ...

scons: *** Multiple ways to build the same target were specified for: build/modm-multiple-ways-same-target-repro/release/modm-lib/ext/arm/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_bitreversal2.o  (from ['modm-lib/ext/arm/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_bitreversal2.S'] and from ['modm-lib/ext/arm/cmsis/CMSIS/DSP/Source/TransformFunctions/arm_bitreversal2.c'])
File "/tmp/modm-multiple-ways-same-target-repro/modm/scons/site_tools/build_target.py", line 16, in build_target
kaelin@LAPTOP-2617BE5S:/tmp/modm-multiple-ways-same-target-repro$ scons -v                                                                                                                                               SCons by Steven Knight et al.:
        script: v3.0.1.74b2c53bc42290e911b334a6b44f187da698a668, 2017/11/14 13:16:53, by bdbaddog on hpmicrodog
        engine: v3.0.1.74b2c53bc42290e911b334a6b44f187da698a668, 2017/11/14 13:16:53, by bdbaddog on hpmicrodog
        engine path: ['/usr/lib/scons/SCons']
Copyright (c) 2001 - 2017 The SCons Foundation

I can see that the CMSIS repo includes both an assembly file and a C file with the same name, but don't know which component of this build system is at fault for failing to handle it properly.

[salkinium]

lbuild is at fault, ie. there should not be two files generated. I thought I fixed that tho, in fact, the .c file is specifically excluded from being copied.

[salkinium]

But your example repo doesn't even include any modm:cmsis:dsp modules, so why would it even generate those files?

[WasabiFan]

To confirm -- You aren't asking for an answer to that from me, are you? I don't have good insight into what would be different in my test setup to cause this error so I probably can't provide much guidance.

[salkinium]

Sorry, I forgot about this!

This happens because the SConstruct file searches recursively for all application sources inside its parent folder and so it's trying to build all the source files inside modm-lib too.

The quickfix is to place your application inside a folder. The real fix is to add the modm-lib folder to the SCons ignore list and I'm preparing a PR for that right now.

[salkinium]

The real fix is to add the modm-lib folder to the SCons ignore list and I'm preparing a PR for that right now.

Nah, it's not possible to make this reliable, since the build script generator doesn't have enough information (in general). You need to place your application into a folder and I need to update the docs to make this clear.

[WasabiFan]

Thanks for the investigation!

What is your suggested project structure? The docs didn't seem to provide any examples that weren't in-tree examples within the modm repo.

In my case I'd like my project repo to contain a submodule pointing to the version of modm I'm using, so that everyone is working from the same library version. Does this mean I need the actual code to be 3 levels deep rather than 2?

[WasabiFan]

Actually, after reading the docs PR I think I get it; the problem wasn't about my submodule but about the project files being at the same level as the place I was putting modm. Sounds good to me.