运行sloeber（在cdt的托管构建系统上构建arduino eclipse插件）后执行命令并失败：
'Starting combiner'
"D:\eclipse\sloeber\eclipse\/arduinoPlugin/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-gcc" -mcpu=cortex-m4 -mthumb -Os -Wl,--gc-sections "-TD:\eclipse\sloeber\eclipse\/arduinoPlugin/packages/Maxim/hardware/arm/1.0.3/system/CMSIS/Device/Maxim/MAX32620/Source/GCC/max32620.ld" "-Wl,-Map,D:\workspaces\junit-workspace\363_max32620_fthr/Release/363_max32620_fthr.map" -o "D:\workspaces\junit-workspace\363_max32620_fthr/Release/363_max32620_fthr.elf" "-LD:\workspaces\junit-workspace\363_max32620_fthr/Release" -Wl,--cref -Wl,--check-sections -Wl,--gc-sections -Wl,--entry=Reset_Handler -Wl,--unresolved-symbols=report-all -Wl,--warn-common -Wl,--start-group .\sloeber.ino.cpp.o "D:\eclipse\sloeber\eclipse\/arduinoPlugin/packages/Maxim/hardware/arm/1.0.3/system/startup/Build_max32620/system_startup_max32620.a" "D:\eclipse\sloeber\eclipse\/arduinoPlugin/packages/Maxim/hardware/arm/1.0.3/system/MAX32620PeriphDriver/Build/PeriphDriver.a" "" D:\workspaces\junit-workspace\363_max32620_fthr/Release/arduino.ar -Wl,--end-group -lm -gcc --specs=nosys.specs
arm-none-eabi-gcc: error: : No such file or directory
问题是由命令中的“”引起的。据我所知，gcc将“”解释为文件输入，但未找到该文件。至于gcc，这是一个错误，他尽可能地报告。 当我删除“”一切都很好但是...... makefile中的实际命令是：
${A.RECIPE.C.COMBINE.PATTERN.1} $(LINK_OBJ) ${A.RECIPE.C.COMBINE.PATTERN.2} ${A.ARCHIVE_FILE_PATH} ${A.RECIPE.C.COMBINE.PATTERN.3} ${JANTJE.EXTRA.ALL} ${JANTJE.EXTRA.LINK}
为了能够删除“”我需要扩展命令。我曾经这样做，但我正在努力支持非扩展命令以获得其他工作。 所以我想知道我是否可以轻轻地请求gcc忽略这些“扩展剩余”。
注1：我正在处理来自多方的文件。如果供应商认为做“$ {A_VAR}”这样的事情是个好主意，那么A_VAR会扩展到零，那么我就无能为力。
注2：我可以在Linux和Windows中重现这个问题。从信息我看到cygwin将处理这种情况（我没有测试）
这不是问题的答案，而是避免问题的一种方法。
我将A_VAR定义为-DIDefinedThisHere
因此，该命令现在包含"-DIDefinedThisHere"而不是""
因为它是一个编译命令，gcc接受命令。由于我使用了一个非常特殊的定义名称，因此这不太可能导致下游问题。
在我的例子中，我选择了一个定义名称，指定定义的位置。在那里，我添加了一些关于为何定义它的评论。 这个想法是，当某人有一个错误，因为A_VAR不像“它应该是”那样，它们至少会被路由到根本原因并解释原因。 ：-s。
（为了记录，那个人可能是我。