mbed-cli build path exceeds Windows command line argument sting length

[dlfryar-zz]

Description

Building mbed-cloud-client-example and possibly other projects that have lots of source files overruns the Windows command line argument sting length of 32k. Targets like Nordic where the peripheral feature set is broken down to separate directories (e.g. mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_14_2/drivers_nrf/*) exacerbate this problem and make it more noticeable on smaller source projects.

maximum-length-of-command-line-string

Error Output

Source files to be passed to compiler are truncated on the command line in Windows.

[DEBUG] Return: 1
[DEBUG] Output: arm-none-eabi-g++: error: CreateProcess: No such file or directory
  File "C:\mbed-cloud-client-example\mbed-os\tools\toolchains\__init__.py", line 974, in compile_queue
    raise ToolException(err)
ToolException: arm-none-eabi-g++: error: CreateProcess: No such file or directory

[mbed] ERROR: "c:\python27\python.exe" returned error code 1.
[mbed] ERROR: Command "c:\mbed-cloud-client-example\mbed-os\tools\make.py -t GCC_ARM -m nRF52840_DK --source . --build .\BUILD\NRF52840_DK\GCC_ARM -v" in "C:\mbed-cloud-client-example"

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

[dlfryar-zz]

cc: @bridadan @theotherjimmy @surajdagar @bentcooke

[surajdagar]

After adding below in .mbedignore It compiled but break the UART.

source/platform/linux/
source/platform/freertos/
_K64F_FreeRTOS_mbedtls/
mbed-os/features/lorawan/
mbed-os/features/nanostack/mbed-mesh-api/
mbed-os/features/nanostack/sal-stack-nanostack/source/
mbed-os/features/nanostack/sal-stack-nanostack/docs/
mbed-os/features/nanostack/sal-stack-nanostack/doxygen/
mbed-os/features/nanostack/targets/
mbed-os/features/nanostack/nanostack-interface/
easy-connect/atmel-rf-driver/
easy-connect/mcr20a-rf-driver/
easy-connect/stm-spirit1-rf-driver/

[bridadan]

@marcuschangarm Flatenning parts of the nordic SDK port would help mediate this problem quite a bit. Specifically the mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_14_2/drivers_nrf/* folders as mentioned by @dlfryar. What do you think?

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-426

[0xc0170]

There are at least 2 issues reported and currently opened. Thus this should be closed as duplicate and add the initial report to the opened one.

[0xc0170]

Duplicate of:

#6335
#6861

[0xc0170]

@marcuschangarm Flatenning parts of the nordic SDK port would help mediate this problem quite a bit. Specifically the mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/TARGET_SDK_14_2/drivers_nrf/* folders as mentioned by @dlfryar. What do you think?

Flatenning just postpones the real issue. From experience, we get new features, targets hal folders - all these will extend the command length and will exceed the limit eventually.

[bridadan]

Agreed that it postpones the problem, but seems like the real solution is to fundamentally change how our code is built, which will take some planning

[dlfryar-zz]

@0xc0170 the other two linked are exporter and/or makefile type issues not core compilation using Windows command interpreter.

[dlfryar-zz]

cc: @bulislaw

[0xc0170]

#6861 - this is not exporter but build - all of them however are about the same - if it is exporter or a build - it is related to the command line length - one fix should resolve all of them.

I reopened #6861 (this one is duplicate, same report) - to keep 2 issues - exporters and cli building problem

[theotherjimmy]

one fix should resolve all of them.

I strongly disagree with this statement: exporters have there own limitations that I can't fix.