Out of necessity I have over the years used symlinks to fool
platformio and other tools to believe source code was in a root project folder when it in fact was elsewhere.
I actually prefer to not do this and real relative pathing within config files, when possible.
In this particular instance, I have a folder structure:
test/arduino/unity which contains all the PIO usual suspects (
test/arduino/unity/test which contains the unity core main() entry file and a symlink
test/unity which contains the actual unity test files, shared across many different build systems
pio 6.0+ with the new unit test structure, neither symlinking or relative pathing seem to work in this instance. What happens instead is the main() gets compiled, but the
unity symlink is ignored.
What does seem to work is using
test_build_src = true and moving
test/arduino/unity/src. That doesn’t feel like the right way forward though.
I’ve tried fiddling with the
build_ parameters to motivate LDF to find
test/unity without success.
Please advise. Thank you!
I am now at a standstill and am generally unable to use
pio. I’d prefer not to give up on the tool.
Should be fixed in the latest PIO Core 6.1-dev. Could you re-test with
pio upgrade --dev?
Sadly the same results. I apologize for being so dramatic before, just frustrated. This is a somewhat complicated scenario, would it make sense to schedule a 20 minute session together to diagnose it? Let me know how I can help.
EDIT: The non-unit-test (regular project) does show improvement, symlinks work better. Though I am still 100% onboard for a technique which doesn’t use symlinks at all
Could you provide a simple project to reproduce this issue? Please pack at as tar.gz to keep symlinks and share somewhere( Googledrive, etc)
Sure I can do that. Alternatively, would a test project on bitbucket/github be OK?
Yes, any public location. Thanks.
I’ve created an example repo here:
malachib / playground.pio / src / PGPIO-2 — Bitbucket
However, it’s not quite at the stage where it demonstrates the issue. For unknown reasons the unit test compilation is unable to find system level “unity.h”
What does mean
srcFilter is already pointed to the
src folder as described in the docs. I don’t see the
Ah that is PGPIO-1, we want PGPIO-2. Don’t recall what PGPIO-1 was up to…
That said, PGPIO-2 gets up to something similar. In the past I remember metadata from CLion made LDF upset so I explicitly excluded the .idea folders as you can see
I’ve rounded out the rest of the project. And, it is fully functional, which was not expected. It seems more proper placement of unit test files made a difference.
That said, the symlinking to make this work still feels wrong. Could you please comment on:
PGPIO-2/test/arduino/unity/lib and observe what was necessary there
PGPIO-2/test/arduino/unity/test/test_embedded/unity - given the problem domain, do you think this is the “right” way?
Thank you for your time spent on this!
Bitbucket is an outlier for sure, and there is no doubt that Atlassian helms some of the clunkiest UIs in the industry. But even with github there’s trouble in paradise
PGPIO-2/test/arduino/unity does follow the Test Hierarchy,. To accomplish this requires some suspect symlinking, which is what I am asking about.
I’ve attempted to outline the folder structure in the root readme. By necessity my projects don’t perfectly conform to the Test Hierarchy defaults.
I see, in this case, it should work. I’ve just tried to compile a project you mentioned and didn’t find any issues:
pio test -d /tmp/piotest/playground.pio/src/PGPIO-2/test/arduino/unity -e m0
Yes, it does. My question has morphed from “how do I make it work?” to “Given this folder structure, is there something better than symlinks?” - especially the stunt required for
Sorry, I’m feeling like a fool. I don’t understand how to help.
@maxgerhardt, do you understand where is a bug in PlatformIO?
@ivankravets it’s just gotta be a communication breakdown between us. In fact, platformio is working pretty well. @maxgerhardt I look forward to your assistance.