Adding libraries to project - local and public ones

[ZinggJM]

@ScruffR

BTW, there is no harm in uploading a private work-in-progress library just for testing - just one caveat: You can’t delete libraries once created, hence I’ve got one ScruffR_Testlib which I keep reusing for all upload and usage tests and once I’m satisfied, I rename the library and upload with its intended name.

Now I am in serious problems! I can't upload PxEPD2 to this account with Particle CLI, I get told that I am not the owner of that library. Most likely because I had created that library under my other account.
Does a private library in one account disable to create a library with the same name in an other account?

No remedy to this, as no remove or delete option available?

Ok, I just need to do this work on the other account.

[ninjatill]

@ZinggJM

Does a private library in one account disable to create a library with the same name in an other account?

From what I remember from reading other threads, the library name is system-global. It has to be unique from all other library names on the Particle system. So yes, you cannot create another library, under another account, using the same library name.

[ScruffR]

@ZinggJM

No remedy to this, as no remove or delete option available?

There is something that can be done, but that involves some background tweaking on Particle's side.
We have gone through the process to transfer ownership for libraries that were abandoned by their original contributor but were so widely used that the effort was justified.

The reason why a library name has to be globally unique is that at any time a user could decide to publish their private library and if the names were not unique that would either lead to collisions or render any other private library of that name un-publishable.

[ZinggJM]

Now I am slightly confused. Yesterday evening I couldn’t compile my test5 using Particle Desktop IDE, now this morning I can. Has anything been fixed in the meantime? I will add test5 to my repository.

[ScruffR]

@ZinggJM

Has anything been fixed in the meantime?

Most likely not. But with Desktop IDE it's just too easy to build the wrong project.
You may be working on one file but the build "pointer" is still pointing to a completely different project.

[ZinggJM]

I have logged in to my other Particle account in Desktop IDE this morning (the second account, I had created with Particle CLI).
Now I have logged in back to the first account, and I get the error again.
So this is dependent on the Particle account I use.
The second account has a valid private PxEPD2 library, that compiles with a copy of test5.ino in the Web-IDE.
I will check with a different project local library on both account, to see if it depends on the account or on the private library.

Yes, I had that issue with the build “pointer”, so I take care to have only one project in the projects folder.
The Particle Desktop IDE then reports some exceptions because it doesn’t find the previous project, but I can live with that.

[ZinggJM]

test6 fails to compile on both of my Particle accounts with Particle Desktop IDE.

So I would expect test5 and test6 example in PxEPD2 to fail to compile on any user’s Desktop IDE.

[ZinggJM]

I have just found out that the src of GxEPD2 can be used as is, just library.properties and the test program need be adapted to Particle Photon.
How can common source with Arduino be handled concerning different library.properties? I mean common source on GitHub? The difference is dependencies.Adafruit_GFX_RK=1.3.5.

[ScruffR]

Have you tried just adding that dependencie and build in Arduino IDE?
AFAIK Arduino IDE does ignore dependencies.xxxx entries but Particel cloud build honours them.
Inside your code you can use #if defined(PARTICLE) .... #elif to include the appropriate headers.

[ZinggJM]

@ScruffR

Inside your code you can use #if defined(PARTICLE) .... #elif to include the appropriate headers.

Thank you, that's the question I forgot to ask. This means I can have common examples. Not all may work, but the main example will. And I will have one with ParticlePhoton in its name, with all the other targets removed. The library code does (should) not need any #if defined(Particle).

Yes, I think dependencies is only used as information for Arduino; I will try.

For Arduino examples the example.ino needs to be in a directory with the same name, not in /src. Does Particle work with this, and if yes, where should the project.properties be?

[ScruffR]

@ZinggJM

And I will have one with ParticlePhoton in its name, with all the other targets removed. The library code does (should) not need any #if defined(Particle).

One caveat we still see with building examples with Particle cloud build.
Examples don't honour the project.properties file. So if an example requires additional libraries and you have declared these dependencies in project.properties of that example, they will be ignored.
I have moaned about that frequently, but this feature hasn't made it near the top of the priority list yet.
Also non-source files (e.g. images) won't be used even when stored inside the examples folder.

I may be stating the obvious, but for completeness:
If an example requires anything in addition you should put state that clearly in the comment header of the main source file for that example.
For images and other suplemental files, a link to the GitHub repo to download them separately is also advisable.

[ZinggJM]

Maybe I should use partial common source. The complete content of the GxEPD2 GitHub repository needs to be Arduino compatible, but I would only upload and later make public the common source and the examples compatible with Particle. Or does Particle synchronize public libraries like Arduino Library Manager?

[ScruffR]

@ZinggJM

Or does Particle synchronize public libraries like Arduino Library Manager?

How would that be?

The Particle library repository is not automatically synchronising with GitHub. If you want to publish a new version, you'd repeat the upload & publish process via CLI.

[ZinggJM]

What happens when the WEB-IDE opens a private library?

I had uploaded a new private library GxEPD2_PP, with the library.properties for Particle, and with an example GxEPD2_PP_Example specific to Particle Photon, that I wanted to test with the WEB-IDE.
But when I opened this new private library, the WEB-IDE seemed not ending loading it, said Loading… for more than half an hour.
Then I restarted Particle Build page and opened private library GxEPD2, which loaded quite fast.
Then I added the example to GxEPD2, increased the version and uploaded it.
I tried to open GxEPD2 with the restarted Particle Build Page, but now this also hangs on Loading…
With the behaviour of the Particle build tools I have no chance to ever make my e-paper library available for use with Particle.

[ZinggJM]

My last resort was to test-compile with Particle CLI. Now I can see the error that was unclear with Desktop IDE:

src/GxEPD2_PP_Example.o src/GxEPD2_PP_Example.cpp
src/GxEPD2_PP_Example.cpp:37:40: error: 'GFXfont' does not name a type
 void showFont(const char name[], const GFXfont* f);
                                        ^
src/GxEPD2_PP_Example.cpp:38:40: error: 'GFXfont' does not name a type
 void drawFont(const char name[], const GFXfont* f);
                                        ^
src/GxEPD2_PP_Example.ino: In function 'void setup()':
src/GxEPD2_PP_Example.ino:88:51: error: cannot convert 'const GFXfont*' to 'const int*' for argument '2' to 'void showFont(const char*, const int*)'
   showFont("FreeMonoBold9pt7b", &FreeMonoBold9pt7b);
                                                   ^
src/GxEPD2_PP_Example.ino: In function 'void showFont(const char*, const GFXfont*)':
src/GxEPD2_PP_Example.ino:260:21: error: cannot convert 'const GFXfont*' to 'const int*' for argument '2' to 'void drawFont(const char*, const int*)'
     drawFont(name, f);
                     ^
../build/module.mk:267: recipe for target '../build/target/user/platform-6-msrc/GxEPD2_PP_Example.o' failed

For me this looks like coming from autogenerated function declaration being included before the
#include <Adafruit_GFX.h>

help needed

ok, it works if I add
#include <Adafruit_GFX_RK.h>
on top

I think the Arduino IDE handles this better.

[ScruffR]

@ZinggJM

But when I opened this new private library, the WEB-IDE seemed not ending loading it, said Loading… for more than half an hour.

We have seen this behaviour with other libraries (e.g. Arduino_JSON) too, probably due to disallowed files in the structure.

See here

DynamicJsonBuffer jsonBuffer(bufferSize);

I was not aware of this problem, thank you very much for reporting it. I discovered that I uploaded build artifacts with the library. I published a new revision (5.13.4) without these files and it seems to work fine now. [image]

This shure is a glitch in Web IDE, but since a replacement is in the works, I doubt there will me much effort going into cleaning up Web IDE before ditching it

[ZinggJM]

Ok, I will try to check this again. And I will put GxEPD2_PP on GitHub, so you can then take a look at it, too.
Just need to merge my latest changes, that are dispersed on 3 computers now. Thank you.

[ZinggJM]

I found the reason. I have the same header file WaveTables.h in 2 subdirectories epd and epd3c.
If I remove one, the WEB-IDE Particle Build loads the library without any problem.
So I should write an issue for the WEB-IDE, but I am too tired and lazy.

[bko]

I would say that it is bad practice and a bug to have two different header files with the same name in two different directories. If the user needs to include both, how could they do that?

[ZinggJM]

I partly agree, but these are local files used only by .cpp files in the same directory. And they are even identical.
This was a shortcut I took when I created GxEPD2 starting from GxEPD2_32. The user doesn’t need to include any.
But this is completely legal, and the Arduino IDE has no problem with it!