Skip to content

Cannot resolve library for nested files #484

Closed
@khswong

Description

@khswong

Bug Report

Current behavior

I am trying to reproduce the build behavior of the Arduino IDE in arduino-cli s.t I can use them in a Makefile and virtualenv.

Currently, the command I run for the Arduino IDE is:

arduino=/Applications/Arduino.app/Contents/MacOS/Arduino
board=<custom board package>
$(arduino) --verify --board $(board) $(dir)/a.ino -v --pref build.path=$(dir)/build

I replaced it in my makefile as such:

arduino=arduino-cli
board=<custom board package>
$(arduino) compile --fqbn $(board) $(dir)/a.ino -v --build-path=$(dir)/build ```

When I run make,

Alternatives for src/common/CommonHeader.h []
ResolveLibrary(src/common/CommonHeader.h)
  -> candidates: []
/Users/kwong/Documents/GitHub/repository/a/a.ino:16:38: fatal error: src/common/CommonHeader.h: No such file or directory
 #include "src/common/CommonHeader.h"
                                      ^

The directory structure is like such:

repository:
| _ a/
|  | _ a.ino
|  | _ build/
|  | _ src/ 
|      | _ common/ (symbolic link to ./common)
|          | _ CommonHeader.h
| _ b/
|   | _ b.ino
|   | _ build/
|   | _ src/
|       | _ common/ (symbolic link to ./common)
|           | _ CommonHeader.h
| _ common/
    | _ CommonHeader.h

Expected behavior

Is the expected behavior to mirror the official Arduino IDE?
The builder should find local headers and not attempt to resolve them as libraries.

Environment

  • CLI version (output of arduino-cli version): Version: 0.6.0 Commit: 3a08b07
  • OS and platform: macOS Mojave 10.14.6, custom board package (based off Adafruit SAMD)

Additional context

My libraries are all managed by git submodules rather than the package manager, however, arduino-cli parses them fine.

#include <SPI.h>

#include <RF24.h>            
#include <Adafruit_GFX.h>   
#include <Adafruit_ST7735.h> 
#include <SPIMemory.h>       
#include <Adafruit_Sensor.h>
#include <Adafruit_BMP3XX.h>

#include "src/common/CommonHeader.h"

What's likely happening is that the library resolver just takes whatever includes list the gccpreproc generates in legacy/builder, no matter if it exists in subdirectories or not. I'm wondering if that's fixed in the new builder and if there is a way to invoke that.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions