libpipeline example needs to be reviewed
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Snapcraft |
Fix Released
|
Medium
|
Leo Arias | ||
Bug Description
<mterry> elopio, um, if I recall, it was to demonstrate that snapcraft could integrate with your locally built project too. Like you have your source tree. And then you had snapcraft grab all the dependencies and build them. And then you could run "snapcraft shell make" to build your local project pointing at the snapcraft built files. I don't know whether that concept meshes with the snapcraft of today anymore
<mterry> elopio, (i.e. to demonstrate that you could build that local test.c against snapcraft's copy of libpipeline)
This test is successfully using the remote lp:~mterry/libpipeline/printf, but it's also using the remote lp:~mterry/+junk/pipelinetest and totally ignoring the local files test.c and Makefile.
We should either change the libpipeline part to use the local files, or remove them.
In addition to this, the test uses ls to test the pipeline. Now that the snap's cwd is empty, ls doesn't make a lot of sense anymore. See https:/
| Leo Arias (elopio) wrote | #1 |
| Changed in snapcraft: | |
| milestone: | none → next |
| status: | New → In Progress |
| assignee: | nobody → Leo Arias (elopio) |
| importance: | Undecided → Medium |
| Changed in snapcraft: | |
| milestone: | next → 2.4 |
| status: | In Progress → Fix Committed |
| Changed in snapcraft: | |
| status: | Fix Committed → Fix Released |
ugh, in the end I'll have to fix this too in the same PR because grep fails when it returns nothing.
https:/